The most common WMI errors

WMI Overload

Probe Health sensor shows WMI delay

The delay value shows how many WMI requests had to be globally postponed from their intended scanning intervals. This indicates an overload problem. A delay of 0% is the most favorable value.

If you keep seeing a higher number over a significant amount of time, you should reduce the total amount of WMI requests on this probe by increasing the scanning intervals of the sensors. Alternatively, you can distribute the sensors among one or more additional remote probes.

Tip: The bottlenecks for WMI monitoring are these two services:

• WmiPrvSE.exe
• lsass.exe

These services do not support the usage of multiple processors. So, if you encounter WMI delays and one or both of these services are running at maximum load (100% per number of processors) on the probe system and/or one of the target systems, you might know where to decrease the amount of WMI monitoring requests.

WMI timeouts

WMI timeouts are caused by several reasons. For an overview, see My WMI sensors show errors with a PE code. What does that mean?

Errors in the 800xxxxx range

The underlying DCOM or WMI system of Windows often throws an error code that starts with 800. As there are lots of different error codes in this context, we recommend that you extend your search to the internet with the specific code you encounter.

WMI connection-based errors - Connection could not be established

Very often, PRTG is blocked from monitoring WMI counters. As these errors are on a very low communication level, no WMI sensor on the device will run and they will all show one of the following errors:

Port error 135: RPC server not accessible

If you see this precise error message, the port that all DCOM communication protocols are routed over is blocked. This is very likely the case because the RPC server on the target system is:

• blocked by a local firewall
• blocked by domain policies
• not running
• running on a different port than specified in the PRTG settings for this system

A possible solution is to add the device name and IP address in the probe host file and to use the IP address in the settings.

800706BA - RPC server is unavailable

This is quite an ambiguous message, as there can be different causes for it, including:

• The RPC service is not running on the target system.
• Sometimes, this error occurs when using an IP address to connect to a device. Try to use the hostname or fully qualified domain name (FQDN) instead. In PRTG, enter this information in the device's settings, section Credentials for Windows Systems.
• If the PRTG core server system is part of a domain, whereas you are trying to monitor a target system that is not part of the domain, see How can I monitor WMI sensors if the target machine is not part of a domain? for more information.
• The target system is unable to connect to the primary domain controller and is thus unable to verify the Windows credits provided for the WMI sensor. Check the domain controller settings.
• Either the probe system or the target system are provided with incorrect DNS entries. This might be the case when the system has opened one or more VPN connections in addition to the normal network connection. You can test this with a ping to the system in question. Do you see the correct IP address?
• Allow Remote Administration Exception: Enabling this option is a fix that helps in some cases (even if the Windows firewall is turned off). However, the WMI connection only works with the target's name, not with its IP address. Read the Microsoft Technet article Help: Enable or disable the remote administration exception and the Microsoft article https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior for how to do this.
• Time difference: One customer reported that this error vanished when they synchronized the time on the target system, which differed for some hours, with the official time of the domain.
• The ISA server is blocking all RPC traffic by default, so you must explicitly configure the server to use WMI sensors. Read the following article:
  • Ed McKinzie's Technical Repository: ISA 2006 WMI Monitoring: FWX_E_FWE_SPOOFING_PACKET_DROPPED errors
• UAC blocks root access to disk drives, as one of our customers found out (see What can I do about "Connection could not be established" errors on my WMI sensors?) You can add the following registry key to disable this feature of UAC.
  
  Path:
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  Add a new DWORD value:
  Name: LocalAccountTokenFilterPolicy
  Value: 1
  
  Note: This disables some of the protection provided by UAC. Specifically, any remote access to the server using an administrator security token is automatically elevated with full administrator rights, including access to the root folder. More information can be found in the Microsoft article https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction.
• A couple of customers found out that opening TCP port 1091 helped them.
• One customer reported that they had two NICs running in teaming mode for a long time without any problems when suddenly this error came up. The only solution found here was to disable one of the adapters.
• Another customer was able to get their WMI sensors running again with two network adapters after they enabled the Windows Management Instrumentation (WMI-In) rule in the Windows firewall.
• Another customer reported that opening the X11 port range (6001-6032) fixed this issue.
  Background: RPC is categorized as the X11 protocol and is in the 6001 to 6032 port range. Commonly 6007 is what is being blocked in this case.
  Certain firewalls like Checkpoint do NOT allow X11 traffic even when set to Allow All, and require an explicit allow rule.
  Source: Troubleshooting ‘RPC server unavailable’ 0x800706BA

• Check the inherited user credentials for the Sensors and confirm that the Active Directory (AD) user is not locked out. Similar incidents have been reported by customers. Please be aware that the Active Directory (AD) credentials you're using for testing may still yield a successful result, even if the inherited account on the Sensor is locked out.

80070005 - Access is denied and 80041003 - access denied

There is a fine distinction between these two errors.

• 80070005 means that the domain controller or the local Windows system could not verify the credentials for the target system.
  • Possibly, incorrect credentials were provided, so you might want to check the entries in the Credentials for Windows Systems section of the device, group, probe, or even root group settings.
  • DCOM must be enabled on probe and target system. Check the respective registry entry.
  • If the PRTG core server system is part of a domain, whereas you are trying to monitor a target system that is not part of the domain, see How can I monitor WMI sensors if the target machine is not part of a domain? for more information.
  • We have also seen trouble with DNS/DHCP entries that directed the host name to the incorrect IP address, resulting in this error. Try to use the explicit IP address as host setting if possible.
  • If the target hosts are accessible with WMI Tester, but PRTG still insists on showing the 80070005 error, try to use "localhost" as Domain or Computer Name in the Credentials for Windows Systems section of the device's settings.
  • Check the access rights of the user account under which PRTG runs. We recommend that this user account is part of the local Administrators group. If the user account is part of a different group, make sure that this group is part of Administrators.
  • If this error sporadically shows up and vanishes again, we have no explanation at the moment because PRTG only reports the error the Windows system has encountered.

• 80041003 means that the user does not have sufficient rights to use WMI, so you might want to check the access rights or the respective policies.

80041002: The object could not be found

This means that the probe is able to connect to the host's WMI system, but for some reason, it is not able to see the objects that are needed for the sensor's functionality. Most likely, this is because of configuration issues regarding the access rights. One of our customers was able to avoid this error by moving the erroneous device to a different probe.

80004002: No such interface supported

This is unfortunately a very vague error. One customer reported that it appeared when the primary domain controller was offline and the attempts of PRTG to monitor remote Windows computers failed because PRTG was not able to assert the respective credentials.

80040155: Interface not registered

Perhaps this Microsoft article might help in this case.

Note: If any one of these errors occur, make sure that your systems meet all of the basic requirements as listed in the respective section of our main WMI article.

Sensor-based errors

The following errors might not affect all sensors in a device but are widespread nonetheless:

80041010 – The specified class is not valid

This is quite an ambiguous message as there can be different causes for it, inlcuding:

• If certain services (for example, Exchange) are not started when the WMI AutoDiscovery/AutoPurge (ADAP) process is started, the performance counters are not transferred to WMI because WMI uses ADAP to build its internal performance counter table.

Open a command prompt. Execute wmiadap.exe /f. Start WMI.

• Performance counters are disabled for a specific service. There’s a registry entry for WMI counters for each service. To check and fix this, you must edit the registry.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Service-name\Performance Data type: REG_DWORD Range: 0|1 Default value: 0 According to Microsoft: "If the value of this entry is 1, then the Performance Library (Perflib) does not retrieve performance data about these counters from the registry. As a result, System Monitor and other tools that use the data cannot display it. Instead, the tools display a value of 0 or 100 percent, depending on the counter." To activate any changes, restart the Windows system.

Nonsensical or incorrect results

Although the WMI counters and their results are well defined, this does not necessarily mean that Windows always adheres to this fact.

Depending on the Windows version and the current patch level, it can happen that Windows limits 64-bit counters to 32-bit values.

This causes incorrect results, for example, in the system memory, or 64-bit processes never show more than 4 GB in PRTG. Or you see strange errors as described in My WMI sensors show errors with a PE code. What does that mean?, section WMI counter value-related errors.

Windows Process sensor

We have found the reason for the limitation to 4 GB with 64-bit systems or processes. It seems that Windows' own WoW64 emulation layer for 32-bit applications (which PRTG is) somehow caps off these values at 4 GB.

Yes, you read that right: for the correct monitoring of 64-bit processes, you must run the probe on a 32-bit system until Microsoft fixes that bug in the WoW64 layer.

The only solution we can recommend at the moment is that you use a (remote) probe that runs on a 32-bit Windows for these sensors.

Windows Network Card sensor

If your graphs and live data tables show large gaps and/or the results are too low, decrease the scanning interval for this sensor. As WMI only features 32-bit counters for Traffic In/Out, it is very likely that overflows happen during scanning intervals that are too long, especially on fast (GBit) interfaces.

Shorter scanning intervals may solve this problem.

Note: Unfortunately, for all other cases there is nothing we can do to fix these errors as they are caused by Windows. You can try to use the alternative query of a sensor if applicable.

0% Free Disk Space

ESXi 5 and Windows 2012

A customer found a correlation between this error and the hot plug capability of drives under ESXi. After disabling the hot plug capability, WMI was able to report the correct values of the drives again. See this article in VMware's knowledge base for further instructions.

Here is an excerpt of what the customer told us: "The circumstances appear to only be with Server 2012 and ESXi 5.x. Hard disks and other devices are viewed as hot swappable, these devices are actually not picked up by a bunch of windows services. [...] IF you are unable to see the drives via the WMI Test and/or by browsing to the administrative IPC share of the disk this should fix the problems."

More

• What are the most common errors when monitoring WMI?