What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

What are the most common errors when monitoring WMI?



What are the most common errors when monitoring WMI and what can I do about them?

common-errors prtg troubleshooting wmi

Created on Feb 19, 2010 11:43:54 AM by  Volker Uffelmann [Paessler Support]

7 Replies

Accepted Answer



The most common WMI errors

Important notice: This is only a small overview and we cannot guarantee that we offer the solution to your specific problem here.

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:
  • 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.

    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

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.
Important notice: Always back up your system before manipulating the Windows 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

Note: As of October 2023, PRTG no longer supports Windows Server 2012 R2. We recommend you use the most recent version of Windows Server.

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."


Created on Feb 19, 2010 11:58:52 AM by  Volker Uffelmann [Paessler Support]

Last change on Nov 22, 2023 1:10:44 PM by  Yasodhara Das [Paessler Support]



I was getting "800706BA: The RPC server is unavailable" message and WMI query was failing. However, when I disabled firewall on a PC, the error was gone. Eventually learned that I can enable the firewall but should make an exception for WMI-IN rule. This can also be done thru a GPO:

  • Computer Config > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security > Inbound Rules node.
  • Right-click in right pane and choose New Rule...
  • Choose the Predefined option, and select Windows Management Instrumentation (WMI) from the drop-down list, Next.
  • Just select WMI-In option with the Domain profile value.

Jay Kulsh

Created on Feb 7, 2015 1:06:02 AM

Last change on Feb 9, 2015 8:41:42 AM by  Felix Saure [Paessler Support]



After going through all steps above, I needed to do the following to make it work through firewalls (allow both ports 135 and 24158).

Even though the connection was tested ok for RPC port 135, our setup required to allow a second port (24158 by default) to get the results ok with the WMI test tool. Otherwise the connectivity was not sufficient, it acted weirdly as the credential where validated but I got the "server unavailable" message (got Denied message with invalid credentials) until I allowed connectivity to the wmi static port.

Setting Up a Fixed Port for WMI (taken from https://msdn.microsoft.com/en-us/library/windows/desktop/bb219447(v=vs.85).aspx):

"WMI runs as part of a shared service host with ports assigned through DCOM by default. However, you can set up the WMI service to run as the only process in a separate host and specify a fixed port. The following procedure is an automated setup to allow WMI to have a fixed port. The procedure uses the winmgmt command-line tool. To set up a fixed port for WMI:

  1. At the command prompt, type winmgmt -standalonehost
  2. Stop the WMI service by typing the command net stop "Windows Management Instrumentation" or use the short name of net stop winmgmt
  3. Restart the WMI service again in a new service host by typing net start "Windows Management Instrumentation" or net start winmgmt
  4. Establish a new port number for the WMI service by typing netsh firewall add portopening TCP 24158 WMIFixedPort

To undo any changes you make to WMI, type winmgmt /sharedhost then stop and start the winmgmt service again."

It is possible to confirm that the WMI service is running as a stand-alone process, and that it is using static port 24158 (by going to Component Services, DCOM Config, WMI properties, Endpoints, TCP/IP properties). The RPC service is also running. (taken from http://serverfault.com/questions/681710/why-is-wmi-not-actually-using-the-fixed-port)

Please note that port listening began after connecting to DCOM port 135 once, which seemed to "kick" winmgmt's wmi; It can be done manually with a TCP client tool, I personally love the wonderful, free tcp utility called Hercules from http://www.hw-group.com/products/hercules/index_en.html to test my tcp connectivity.

Kind Regards,

Philippe Meilleur

Created on Apr 26, 2016 1:37:17 PM

Last change on Apr 26, 2016 3:07:36 PM by  Erhard Mikulik [Paessler Support]



Hello Philippe,

Thank you very much for sharing your insights!

Kind regards.

Created on Apr 26, 2016 3:08:03 PM by  Erhard Mikulik [Paessler Support]



I was receiving error PE015 (Connection could not be established) on various counters for a Windows Server 2003 R2 VM. Restarting the local probe resolved this issue.

Created on Apr 19, 2017 9:22:38 AM



A recent Microsoft patch that was issued within the last 30 days (today is September 18, 2017) is causing our PRTG WMI sensors to have some type of connection problem. We cannot determine if it is a WMI cache issue or authentication but the only fix that appears to work is to reboot the probe.

Created on Sep 18, 2017 3:05:17 PM



Hi Tom,

Do you have the latest PRTG version running? There were quite a lot of improvements regarding WMI connection handling in the latest versions. If that's the case, please follow these steps:

  1. Within PRTG head to Setup | System Administration | Administrative Tools and press button Write Probe Status Files.
  2. Open PRTG Administration Tool on the PRTG server and press button Send Logs to Paessler... on tab Logs and Infos. Make sure to enter PAE926919 as ticket id before uploading. Note: In case the failing sensors are run by a remote probe, please perform step 2 on this remote probe.

Kind regards,


Created on Sep 19, 2017 3:12:30 PM by  Erhard Mikulik [Paessler Support]

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.