New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


What are the most common errors when monitoring WMI?

Votes:

1

Your Vote:

Up

Down

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

Votes:

4

Your Vote:

Up

Down

The most common WMI errors

This is only a small overview and we cannot guarantee to offer the solution to your specific problem here, but it's a start and we will expand this article constantly.


WMI Overload

Probe Health sensor showing a WMI delay

The delay value shows how many WMI requests had to be postponed globally from their intended scanning times. This is indicating 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 over one or more additional remote probes.

Note: On Windows 7 you can run about 10,000 WMI sensors with one minute interval under optimal conditions (such as running the core and the target systems exclusively under Windows 2008 R2 and being located within the same LAN segment). Actual performance can be significantly less depending on network topology and WMI health of the target systems - we have seen configurations that could not go beyond 500 sensors (and even less).

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

  • WmiPrvSE.exe
  • lsass.exe

which don't support the usage of multiple processors. So if you encounter WMI delays and one or both of these services are running with maximal load (100% / number of processors) on the PRTG probe and/or one of the target computers, you might get a hint at where to decrease the amount of WMI Monitoring requests.


WMI Timeouts

WMI Timeouts are caused by several reasons. You can find an overview under PRTG WMI error messages


Errors in the 800xxxxx range

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


WMI Connection based errors - "Connection could not be established"

Very often, PRTG is being obstructed from monitoring WMI counters. As these errors are on a very low communication level, no WMI sensor in the device will run and all of them will 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 very likely is the case because the RPC server on the monitored machine is:

  • blocked by a local firewall
  • blocked by domain policies
  • not running
  • running on a different port than specified in PRTG's setting for this computer

A possible solution to this could be 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, among which are:

  • The RPC service is not running on the monitored machine.
  • Sometimes, this error occurs when using an IP address to connect to a device. Try using the hostname or FQDN (Fully Qualified Domain Name) instead. In PRTG, please enter this information in the device's settings (section "Credentials for Windows Systems").
  • If the server on which PRTG is installed is part of a domain, whereas you are trying to monitor a target machine that is not part of the domain, please see How can I monitor WMI sensors if the target machine is not part of a domain? for more information.
  • The monitored machine is not able to connect to the Primary Domain Controller and is thus unable to verify the Windows credits provided for the WMI sensor. Check your Domain Controller settings.
  • Either the computer running the PRTG probe or the monitored machine are provided with wrong DNS entries. This might be the case when the machine has opened one or more VPN connections in addition to the normal network connection. You can test this with a simple ping to the machine in question. Do you see the correct IP?
  • Allow Remote Administration Exception - to enable this is a fix that helps in some cases (even if the Windows Firewall is turned off). However, the WMI connection is working with the target's name only, not with its IP address. Read Microsoft's technet article and MS's KB article how to do it.
  • Time difference: One customer reported that this error vanished when they synchronized the time on the target device, which differed for some hours, to the official time of the domain.
  • ISA Server is blocking all RPC traffic by default, so you have to configure the server explicitly in order to use WMI sensors. Please read the following articles on external sites:
  • UAC blocks root access to disk drives, as one of our customers found out in this discussion. 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 here: http://support.microsoft.com/kb/951016
  • A couple of customers have found 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 could get their WMI sensors running again on their machine 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 for example -even when set to Allow All- do NOT allow X11 traffic 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 / local Windows could not verify the credentials for the target computer.
    • Perhaps wrong credentials were provided, so you might want to check your entries in the “Credentials for Windows Systems” section of your device, group, probe, or even root group.
    • DCOM needs to be enabled on probe and target computer. Check the respective registry entry.
    • If the server on which PRTG is installed is part of a domain, whereas you are trying to monitor a target machine that is not part of the domain, please 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, directing the host name to the wrong IP address, resulting in this error - try using the explicit IP address as host setting when possible.
    • If the target host(s) are accessible with our WMI Tester tool, but PRTG still insists on showing the 80070005 error, try using "localhost" as "domain or computer name" in the Windows credentials 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 another group, make sure that this group is part of "Administrators".
    • If this error shows up and vanishes again sporadically then we have no explanation at the moment, as PRTG only reports the error the Windows System has encountered.
  • 80041003 means that the user has no sufficient rights to use WMI, so you might want to check your access rights or the respective policies.

80041002: The object could not be found

This means the probe is able to connect to the host's WMI system, but for some reason it isn't able to see the objects that are needed for the sensor's functionality. Most likely it's due to configuration problems 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 PRTG's attempts to monitor remote Windows computers failed due to the inability of asserting the credentials.

80070553: Cannot start a new logon session with an ID that is already in use.

Perhaps this Microsoft article might help in this case: http://support.microsoft.com/kb/2283089

80040155: Interface not registered

Perhaps this Microsoft article might help in this case: http://support.microsoft.com/kb/318956

Note:

If any one of these errors occurs, please make sure 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, among which are:

  • 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. Follow the steps below to fix this. For more details, please see this article (deprecated, but available via archive.org and the information is still valid).
    • Open a command console.
    • 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. In order to check and fix this you have to edit the registry. For more details, please see this article (deprecated, but still available via archive.org and the information is still valid).
    Caution: Please 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 changes, restart the Windows computer.

Nonsensical or wrong results

Although the WMI counters and their results are well defined this doesn't necessarily mean that Windows always adheres to this fact.

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

This manifests itself in wrong results: e.g. the system memory and/or 64-bit processes never show more than 4 GB in PRTG. Or you see strange errors as referred to here in the "WMI counter value related errors" section.

Process sensor

We have found the reason for the 4 GB limitation with 64-bit systems/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 have to run the PRTG Probe on a 32-bit machine... until Microsoft fixes that bug in the WoW64 layer.

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

Network card (traffic) sensor

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

Shorter scanning intervals may solve this problem.

Note:

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


0% Free Disk Space

Windows 2008

One customer of ours found the following solution for this problem on W2k8 servers:

"A while back I started closely monitoring the WMI service on the various servers that often false alarm during WMI overload. Most often, the free space check would fail returning a null or zero value instead of the correct value for free disk space. To troubleshoot, I added the PRTG WMI service monitor for the WMI Service itself with a 60-second interval. I also monitored the system and application event logs with 15 minute intervals. It helped to get more specific errors about what was going on with WMI. Most often I'd get one of these errors in succession:

  1. WMI Free Disk Space [Multi Drive]: 0 % (Free Space C:) is below the error limit of 10 %
  2. Windows Management Instrumentation (WMI Service) Warning: 80041006: There was not enough memory for the operation.
  3. Event Log (Windows API) Value changed: Faulting application wmiprvse.exe, version 6.1.7600.16385, faulting module 4a5bc794, version ole32.dll, fault address 0x6.1.7600.16624

Armed with this new information, I was able to find two Microsoft KB articles that seemed to match the symptoms:

  • 958124 A wmiprvse.exe process may leak memory when a WMI notification query is used heavily on a Windows Server 2008-based or Windows Vista-based computer
  • 954563 Memory corruption may occur with the Windows Management Instrumentation (WMI) service on a computer that is running Windows Server 2008 or Windows Vista Service Pack 1

Applying these two hotfixes stopped the false alarms on my Windows 2008 and 2008 R2 servers. "

ESXi 5 and Windows 2012

Another 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 at VMware's knowledgebase for further instructions:

VMware's KB about hot plugging

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 information about WMI and PRTG

General introduction to WMI and PRTG

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

Last change on Oct 10, 2018 3:50:28 AM by  Sebastian Kniege [Paessler Support]



Votes:

8

Your Vote:

Up

Down

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 by  jkulsh (80)

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



Votes:

9

Your Vote:

Up

Down

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 by  pmeilleur (90)

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



Votes:

0

Your Vote:

Up

Down

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]



Votes:

0

Your Vote:

Up

Down

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 by  ukalcsupport (0)



Votes:

0

Your Vote:

Up

Down

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 by  Tom Stone (0) 1



Votes:

0

Your Vote:

Up

Down

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,

Erhard

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



Please log in or register to enter your reply.


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.