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

Question

I'm using WMI to collect system information. 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?

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.