How can I resolve a "Provider load failure" for WMI requests?

I'm using WMI to collect system informat开发者_JS百科ion. It works fine on every system I've tested it on, but I have one or two users that are reporting problems. The debug logs show the WMI code is throwing a "Provider load failure" exception. I haven't been able to replicate the issue.

The users have verified that the WMI service is running in Automatic mode.

Here's the exception:

System.Management.ManagementException: Provider load failure 
   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()

Any thoughts on how to troubleshoot and resolve this issue?

One way to possibly track down the root cause of the issue is to use WBEMTest a tool that the MS Scripting Guys say is one of the easiest ways

"To find the provider of a WMI class..."

The Scripting Guys: Use PowerShell to Troubleshoot “Provider Load Failure”

The high level steps specific to the Win32_NetworkAdapter are described in this Win32_network adapter "provider load failure" post by Mark Wolzak at infoSupport.

• Click start >> run >> wbemtest
• click 'Connect…' to connect to a namespace
• execute the query 'Select * From MSFT_WmiSelfEvent'
• scroll down to the bottom and trace the following WMI events
• Look at the details of any Msft_WmiProvider_InitializationOperationFailureEvent or Msft_WmiProvider_LoadOperationFailureEvent for the dll that is causing the issue

Thanks to the WMI–Provider Load Failure post at Richard Siddaway's Blog for pointing me to this tool and specific methodology.

On operating systems with User Account Control turn off UAC.

In my case: Ross's answer about did not resolve. I could load some WMI providers (logicaldisk) but not others (IIS). WMI explorer tools (such as PowerGui) would show the provider. This suggested that security policy can prevent loading WMI providers. Once UAC was turned off all WMI providers loaded without error.

Of course, you might want to leave UAC on. I'll update this answer if I find the specific policies required.

So, I know this is old, but I was having the exact problem described above. It was really tough for me to figure out, so I thought I would respond in hopes it helps someone else out.

I was attempting to load the IIS WMI Provider and getting the "Provider Load Failure" error. I could reproduce the problem by running my WMI query using the wbemtest.exe program.

I fired up procmon.exe to show what was being loaded (or failing to load in my case) and sure enough, wmiprvse.exe was loading a registry key was saying that inetsrv was located in the C:\windows directory - which did not exist on my machine (C:\windows had been replaced by c:\winnt)

Updating the key resolved my issue, but the bigger point here is that I had one hell of a time trying to figure out why I was getting this error, and running procmon while executing my WMI query pointed me right to the problem. Hopefully it will for you too.

You might want to confirm all the dlls are properly registered (see http://msdn.microsoft.com/en-us/library/bb961987.aspx).

WMI registration is all held in WMI (static classes.

WMI CIM Studio (part of WMI Tools from MS, IIRC) is useful for exploring these classes (and certainly easier than writing lots of queries).