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

My WMI sensors don't work. What can I do?



What can I do when my WMI sensors in PRTG are showing errors? Can you provide trouble shooting steps?

important pe-code prtg troubleshooting wmi

Created on Feb 19, 2010 9:28:24 AM by  Volker Uffelmann [Paessler Support]

Last change on Dec 14, 2010 9:52:14 AM by  Daniel Zobel [Product Manager]

32 Replies

Accepted Answer



This article applies as of PRTG 22

My WMI sensors do not work. What can I do?

Users sometimes report problems when they try to monitor their systems with WMI (Windows Management Instrumentation) sensors. In most cases, the reason is a malfunctioning WMI configuration or installation, in which important WMI components are missing or were not properly implemented.

Going through the list below can help fix the problem. We also recommend that you read the following article for general information about WMI:

Troubleshooting list for WMI sensors

Make sure that:

  • DCOM is enabled on the probe system and the target system. Check the respective registry entry.
  • The user whose credentials are specified for monitoring WMI is a member of the Domain Administrators group in the same Active Directory as the target system. If a target system is outside of a domain, the user must be a member of the local Administrators group and of the DCOM group and of the Performance Monitoring group on this system.
  • The monitoring user’s access rights on COM and WMI include remote access rights for the target system. Read about Securing a Remote WMI Connection.
  • The target system's Windows Firewall is set to allow WMI. Windows XP and Windows Server 2003 users should read this article: Connecting to WMI remotely with VBScript. For systems with Windows Vista and later Windows versions, read this article: Connecting to WMI on a Remote Computer.
  • If the firewall is enabled by group policies, you also enable the "Allow Remote Administration Exception" as outlined in this article: Group Policy: Windows Firewall setting to allow your WMI scripts to run.
  • The RPC server that is used for WMI on the target system is running on the port that is specified in PRTG (135 by default).
  • DCOM and RPC have open high ports in the 49152-65535 range on Windows Vista and Windows Server 2008 or later. In previous Windows versions, ports in the 1024-5000 range are required. Some users have found that opening TCP port 1091 helped them to get a connection. For more information, read this article Service overview and network port requirements for Windows.
    To define a more specific port range for DCOM, follow these steps:
    1. Run dcomcnfg to open the DCOM console.
    2. Open Component Services | Computers | My Computer.
    3. Right-click My Computer and choose Properties from the context menu.
    4. Open the Default Protocols tab.
    5. Open the Properties... of Connection-oriented TCP/IP.
    6. Define the port range you want DCOM to listen on. Set a minimum of 100 ports in the 49152-65535 or 1024-5000 range, depending on the Windows versions in your environment.
  • Security software: It is always a good idea to double-check that no local security software (anti-spy, antivirus, and others) on either side is blocking WMI connections.
  • If you do not get a WMI connection, try to restart the WMI service manually or change the IP address of the target system to its DNS name in the device settings in PRTG. This establishes a completely new WMI connection, which might help.

Troubleshooting in detail

Refer to the following articles for further information:

Here is another good article about troubleshooting WMI:

Tips against slowness on Vista and Windows 2008:

If you are monitoring a massive number of hosts with one probe, the following article might help. Keep in mind, however, that it is always a good idea to distribute WMI queries over one or more remote probes.

If you are experiencing high handle count in WMI service (Winmgmt) or WMI provider (wmiprvse.exe), read this article:

PRTG settings for WMI

PRTG offers a few settings for dealing with WMI issues:

Tips and tricks

The following articles provide guidelines for special scenarios:

How to repair WMI

If none of the proposed solutions work, we have gathered some procedures that might fix the WMI system on affected computers:


Another good article about all issues regarding WMI can be found under:

  • WMI Reference This reference provides a list of WMI providers, information on the COM API for WMI, WMI queries, WMI log files, WMI security, WMI tools, and WMI infrastructure objects and values.

Further articles of interest, which provide more detail than the troubleshooting articles above, and which relate to particular aspects of WMI configuration can be found under:

Created on Feb 19, 2010 9:37:49 AM by  Volker Uffelmann [Paessler Support]

Last change on Dec 29, 2022 3:14:49 PM by  Brandy Greger [Paessler Support]



Maybe a little addition.

If you query your WMI from within a powershell on Windows 2008R2, you maybe get a Class not Found error. Remember that PRTG uses the 32-bit powershell as default.

Execute your powershell script in powershell 32-bit, receive the same error? Execute your powershell script in powershell 64-bit, error resolved? Than execute your script in a 64-bit powershell by calling it from a commandline in your 32-bit script.

start.ps1 <- the 32-bit, notice the sysnative folder.... c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -file "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE\<script>.ps1"

main.ps1 your working 64-bit WMI script.....

Nice thing to know is that you still can use arguments...

Bye, Peter

Created on May 25, 2011 11:13:08 AM

Last change on May 25, 2011 3:00:54 PM by  Torsten Lindner [Paessler Support]



People, hello.

I can't really understand what prevented you from developing something like "WMI proxy" which will run as a service on remote machine and execute all the WMI queries - there won't be any overloads, permission issues, flickering issues and so on...

Created on Jul 19, 2011 8:04:13 AM



we want to avoid the need to install and maintain extra software on the hosts you monitor.

Created on Jul 19, 2011 6:53:52 PM by  Aurelio Lombardi [Paessler Support]



@Vadim Doroginin: Actually we did develop such a service. It's called "Remote Probe" and can be installed on one, or a few, or all your machines in your network. But it's a lot of work to install a software on all machines in a network and in most cases it is not necessary.

A huge majority of PRTG users is using WMI just fine to monitor their networks with hundreds or even thousands of Windows PCs.

And for those who do have problems with WMI there is the option to install Remote Probes.

Created on Jul 21, 2011 10:18:48 AM by  Dirk Paessler [Founder Paessler AG] (11,025) 3 6



Windows Server 2008 & 2008 R2 WMI Defects

Paessler: please consider making the relevant information below part of the body of your KB article. I hope it helps someone else.

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.

Created on Sep 19, 2011 2:17:48 PM



Dear Ismael,

great finding, thanks a lot for this!

I've added your solution to our Most common WMI errors article.

Best regards,

- Volker

Created on Sep 19, 2011 4:28:25 PM by  Volker Uffelmann [Paessler Support]



To have WMI to work on 2k3 with firewall, I've opened port 1091 TCP.

Here's the DEBUG solution we've used to see this :

- start windows firewall logging and check the logs for dropped connections Go to the Windows Firewall, Advanced settings Security Log group-box -> Click on Parameters button Select "Log dropped packets" Look at the log file location (if not present define one) Click OK

You can now press 'Windows + R' and then type '%WINDIR%\pfirewall.log' to see what's wrong.


Created on Aug 20, 2012 8:08:51 AM



If WMITest shows Error 800706BA: In Windows Firewall enable port TCP 1091 and TCP 56301

Created on Jun 6, 2013 3:23:07 PM



If WMITest show Error 8007005 for Windows Pro with firewall off : Disable simpe file sharing. Method 1: Explorer -> Tools -> Folder options -> Display -> Simple file sharing

Method 2 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Set 'forceguest' to 0

Created on Jun 13, 2013 8:37:33 PM




a great thanks to ERIC Drezet from CNRS who give me a simple working solution.

It works for Windows XP : Netsh firewall set service remoteadmin enable

For Windows 7, we must have a closer look because netsh firewall [...] has been replaced by netsh advfirewall [...]

it should be something like (don't work for me): NETSH advfirewall firewall SET rule group="remote administration" new enable=yes

but this command seems to works (even if depreciated) : netsh firewall set service type=remoteadmin mode=enable

CAUTION : it seems that UAC will block these commands to work.

Created on Jun 25, 2013 9:18:09 AM



80070005: Access is denied SOLVED


Just delete the device and "add" it again to your prtg monitor Group. Do an automatic discovering and it will work fine again. Try it.


Created on Dec 6, 2013 9:07:21 PM



Hey everyone.. I had been struggling for ages with a server that just suddenly stopped responding to WMI. Throwing a mixture of PE015, 80041002 (Object Not Found).

I tried everything across all the WMI threads on here and had no luck.

I found a guy online talking about general WMI errors, and I followed through some of the steps he had posted and boom! Working WMI sensors.

It boiled down to rebuilding WMI on the target server.

I've written up my process here: http://craigerrington.com/blog/prtg-wmi-repair-80041002/

Created on Jul 2, 2014 6:59:27 AM



@CraigE: Thanks for sharing your findings!

Created on Jul 2, 2014 9:29:19 AM by  Konstantin Wolff [Paessler Support]



The prtg kb has been a godsend and so far solved any issues I encountered, namely WMI sensor issues that may relate back to the probe dependencies not being met. Thank you.

Created on Mar 19, 2015 3:26:07 PM



Please, update this article to not recommend adding the PRTG service account to the DOMAIN ADMINS. It's 2016, such blatant insecurity is not an acceptable solution to this problem!

Created on Aug 16, 2016 6:30:21 PM



We have the same doubts as you have about using domain admin credentials for WMI Montioring. However, it's the most reliable option for all WMI / Performance Counters that the sensors monitor. Bear in mind, we do not define the necessary permissions / privileges to access those counters. That's done by Microsoft and potentially the Windows Admins in an organization. PRTG can only adapt to it.

Created on Aug 17, 2016 10:53:44 AM by  Torsten Lindner [Paessler Support]



@PRTG, is it true, that WMI does not work over a NATed network?

Created on Feb 17, 2017 10:31:58 AM

Last change on Feb 17, 2017 1:32:13 PM by  Torsten Lindner [Paessler Support]



We recommend actually to use Remote Probes in a NAT-scenario. Place a Probe into the subnet and configure it to connect back to the PRTG Core Server. That usually also resolves any administrational struggles then when alerts happen, to see in which actual subnet they happen.

Created on Feb 17, 2017 1:33:25 PM by  Torsten Lindner [Paessler Support]



I have been breaking my head on this one, WMI is working on my servers, but on some servers, the Free Disk Space (Multi Drive) sensor can't seem to get out of an error state (unexpected result). SNMP free disk space works in these cases. I tried to use Free Disk Space (Multi Drive) sensor per drive, and it appeared that only some drives fail.

Solution: be sure the account you use for logging in with WMI has some read rights to the drive. For security, root-only Read-only is enough.

Created on Dec 4, 2017 12:08:19 PM



I'm having a nightmare getting the WMI sensors to work on Windows Server 2016.

I've meticulously followed the guides and troubleshooting steps, set permissions in DCOM, WMI, ensured the services are running, allowed WMI through the Windows Firewall (even though the firewalls are set to off) and ensured PRTG is using the right credentials.

I was getting an error PE015 but now they just show as Down. I've run the WMI Tester utility from my PRTG server and directed it at my target system with the same credentials configured in the PRTG sensor, and the WMI Tester successfully pulls WMI data. The sensor stubbornly does not.

I've rebooted both host and PRTG server, checked and double-checked but no dice.

Is there any additional checks I can do, logs I can review or steps I can attempt?

Any help at all would be greatly appreciated!

Created on Dec 14, 2017 10:31:20 PM



Hey scuk07,
Thanks for your KB-posting.

Please open a new support ticket, using the ticket number PAE969863, and forward us a complete support bundle for analysis.

Also, please create and forward us Probe State Files from the affected probe device (local probe or remote probe).

Thank you very much in advance.

Best regards,

Created on Dec 15, 2017 9:29:07 AM by  Sven Roggenhofer [Paessler Technical Support]



Created on Sep 11, 2019 10:34:17 AM



I had trouble with Remote-WMI on Windows 10/1903. I got an Access denied from the Win10-machine. Creating a local administration-user did not work. I found a solution here:


Windows PowerShell

PS C:\Windows\system32> get-service winrm

Status   Name               DisplayName
------   ----               -----------
Stopped  winrm              Windows-Remoteverwaltung (WS-Verwal...

PS C:\Windows\system32> enable-PSRemoting -force
WinRM wurde aktualisiert, um Anforderungen zu empfangen.
Der WinRM-Diensttyp wurde erfolgreich geändert.
Der WinRM-Dienst wurde gestartet.

WinRM wurde für die Remoteverwaltung aktualisiert.
Die WinRM-Firewallausnahme ist aktiviert.
"LocalAccountTokenFilterPolicy" wurde so konfiguriert, dass lokalen Benutzern remote Administratorrechte gewährt werden.

Created on Nov 1, 2019 7:17:05 PM



if i recall correctly, in a situation where you have older windows installs on a lan with no CD or name service, you will need to either disable UAC on clients or alternatively setup specific trust relations in WMI by way of scripting

Created on Nov 24, 2020 11:58:42 PM



WMI Service Sensor (for Windows Service Monitoring via WMI) will only work on some of our servers. On the rest, the "80041003: The current users does not have permission to perform the action" message appears, when the PRTG WMI Service Sensor attempts to activate via the PRTG web interface. Does anyone know which "permission" this error may be referring to and/or have any additional guidance for what to check? We have multiple servers that are configured the same and WMI Service Sensor DOES work. Curiously enough, WMI Disk, WMI CPU and WMI Memory all work. That suggests that our WMI is functional. What are the additional requirements of WMI Service Sensor beyond what WMI CPU, WMI Memory and WMY Disk require? Thanks!

Created on May 27, 2021 2:02:22 PM

Last change on May 28, 2021 5:27:48 AM by  Felix Wiesneth [Paessler Support]



To add to this, the Windows built-in "administrator" account does allow WMI Service Sensor to activate and function. We of course cannot use this account for PRTG purposes. How can a a local Windows account that 100% mirrors "administrator" be created? Manually creating a local account that has all of the required group memberships and WMI settings associated with it did not work.

Created on May 28, 2021 2:20:59 PM




as the necessary rights are not well documented by Microsoft, we can only recommend to use an administrator user here.

As alternative, you could enable the SNMP service and allow remote SNMP access, and then use the SNMP Windows Service sensor.

Created on May 31, 2021 4:33:24 PM by  Arne Seifert [Paessler Support]



Arne - Please elaborate. The local Windows built-in "administrator" account will enable PRTG WMI Service Sensor to function but if I create a local Windows account that is a member of "administrators" group, PRTG WMI Service Sensor fails to function. How do I create a Windows local administrator account that will work? Thanks in advance for your guidance!

Created on Jun 2, 2021 2:50:42 PM



Hello TheWMIMaverick,

this would be a question for Microsoft. PRTG creates a WMI connection using the credentials provided to PRTG, Windows then determines if those are accepted or not.

Details about what exactly does work and what does not work seem to change with different Windows versions, or with Windows settings. If we had more details, we would share those.

Created on Jun 2, 2021 4:20:11 PM by  Arne Seifert [Paessler Support]



This worked for me:

Start > Run > wmimgmt.msc ENTER Right Click on WMI Control (Local) Under General Tap you might see issues as follow:

"Failed to initialize all required WMI classes."
Win32_Processor: WMI: Invalid class
Win32_WMISetting: WMI: Invalid class
Security information: Successful
Win32_OperatingSystem: WMI Invalid class

Navigate to C:\Windows\System32\wbem\ to rename folder Repository. The system will recreate it.

This should fix most WMI issues.

Let me know how it goes!!

Created on Mar 31, 2022 8:27:22 PM

Last change on Apr 1, 2022 10:28:03 AM by  Felix Wiesneth [Paessler Support]



I find it absolutely irresponsible to give the PRTG probe user local-admin privileges or even domain-admin privileges. In time of Zero Trust you should give the users as few rights as possible (#leastprivilege).

What I did and what worked:

  • wmimgmt.msc
  • WMI Control (local) -> - Properties ->- Security
  • Select "Root" and click on "Security" at the bottom.
  • Give the PRTG user the following right: Remote Enable
  • Apply the permissions to this namespace and subnamespaces.

Of course the other rights like "Remote Management Users", "Distributed COM User" and "Performance Monitor Users" must be set as well.

Created on Nov 14, 2022 1:16:05 PM

Last change on Nov 14, 2022 3:51:23 PM by  Felix Wiesneth [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.