WMI: Missing or Failing WMI Providers or Invalid WMI Class

This post has been republished via RSS; it originally appeared at: Ask The Performance Team articles.

First published on TECHNET on Aug 11, 2014
Scenario

Windows Management Instrumentation fails due to receiving an event or error concerning missing or failure to load WMI Provider, or Invalid WMI class, or WMI Invalid Namespace .

Below are some common errors indicating issues with a WMI Provider or Class:

• Failed to initialize all required WMI classes
• Win32_processor: WMI : Invalid namespace
• Win32_WMISetting: WMI : Invalid namespace
• Win32_OperatingSystem: WMI : Invalid namespace
• WBEM_E_NOT_FOUND 0x80041002
• WBEM_E_PROVIDER_FAILURE 0x80041004
• WBEM_E_INVALID_NAMESPACE 0x8004100E
• WBEM_E_INVALID_CLASS 0x80041010
• WBEM_E_PROVIDER_NOT_FOUND 0x80041011
• WBEM_E_INVALID_PROVIDER_REGISTRATION 0x80041012
• WBEM_E_PROVIDER_LOAD_FAILURE    0x80041013

The common urge by many is to simply take a hammer to WMI and either rebuild the repository or recompile all of the .mof files in the C:WindowsSystem32Wbem folder. While the hammer may seem a good approach to solve your problem in some cases or what seems like a quick fix, it can actually cause more problems and issues that are not immediately visible or felt. These newly created problems as a result of the hammer approach are not always immediately obvious and tend to surface later, and usually when the last thing you need is another problem to have to deal with on your plate, especially if it created a critical business situation.

Rebuilding the repository or recompiling all of the .mof files as a first action when other steps should be taken first can cause damage to the system and/or to installed applications.

First we want to just check right up front if our repository is corrupted or not to save time, then continue from there with appropriate actions.

Check the Windows Application log, look for events in the past week where Source = Microsoft-Windows-WMI, check if any of the following WMI event IDs exist: 28, 65, 5600, 5601, 5614. Any of these could indicate a WMI repository or core infrastructure problem.

Check if the repository is corrupted or not by running following command from command prompt with admin rights: winmgmt /verifyrepository . If it is corrupted the returned result will be “ Repository is inconsistent .” If it comes back as consistent, then repository is not corrupted so do not rebuild repository at this point.

Note: if results came back as “inconsistent”, then skip to bottom of the page and reference the section titled “Wmi Repository Corrupted”, otherwise continue with the methods below.

If issue is with a 3 ^rd party provider or namespace, the vendor should be engaged as they are responsible for their own namespaces and providers.

For the 3 scenarios listed below for WMI Invalid Namespace, WMI Invalid Class, and WMI Provider Load failure, if a class is present and operation still errors out with invalid class, then the most likely reason is that service/wmiprvse is hitting memory quota limit or issues.

When a quota issue is hit in wmiprvse, new memory allocations fail and based on where the failure happen client gets different errors “invalid query”/Invalid class/Provider load failure/quota check”
When a quota issue is hit when a new operation is for a provider which is not loaded already in wmiprvse and thus requiring it to be loaded in a new instance of wmiprvse, then the provider loading would fail with “provider load failure”.

Scenario 1: WMI Invalid Namespace

First we want to take any scripts or programs out of the equation by using local built in tools. The two most common tools used to check wmi functionality is the WMI console ( winmgmt.msc ) and Wbemtest (Windows Management Instrumentation Tester).

Ensure the Namespace in question actually exist and functional.

1. Go to start-run and type in wmimgmt.msc
2. Right click on Local Wmi Control (Local)and select properties
3. On the general tab, if there is any failures noted on that box, that indicates a core WMI issue and most likely with the Cimv2 namespace.
4. Click on the Security tab and expand Root folder. This is where you will see all of the namespace listed for WMI
5. Find the namespace referenced in the error message you are getting
6. If you find the namespace is missing, do the following, otherwise skip to step 6 if the namespace is listed

a. Open up a command prompt with administrative rights or elevated privileges

b. Go to www.msdn.com and search for the provider of the missing namespace. We are looking for the associated .mof file. In the below example, we will use MSCluster as our missing namespace.

e.g. search words: wmi mscluster provider or wmi mscluster namespace. In this case you should find ClusWmi.mof as the WMI provider

In case the CimV2 namespace is missing, the provider is CimWin32.mof

If it also lists the associated .dll file, you will want to re-register it also as this would be the registration for the DCOM side as WMI and DCOM work hand in hand.

c. From the command prompt with administrative rights or elevated privileges change directory to C:WindowsSystem32Wbem and run the following command: mofcomp.exe <provider.mof>

Note: Replace <provider.mof> with actual .mof name you found searching MSDN. In our example above that command would be: mofcomp.exe ClusWmi.mof

For re-registering associated .dll if one exists use following command: regsvr32 <provider.dll> and again replacing <provider.dl> with actual dll name

d. Restart the Windows Management Instrumentation Service

e. Use wmimgmt.msc console again to now check if the missing namespace is now listed. First close the console and reopen if it was still open from previous action

7. Go to start-run and type in wbemtest

8. Click on the “ Connect Button ”

9. In the Namespace Box type in the path to the namespace for which getting invalid namespace error for. This path would have the same look and feel of a Windows Directory, so just as you see the structure in wmimgmt.msc console on the Security tab, so is how you will type in path

Examples:

RootCimv2
RootMscluster
RootRSOPComputer

10. Click on the “Connect” button

11. Now all of the buttons should no longer be greyed out on the main wbemtest console page. Click on the “ Enum Classes ” button

12. Leave “Enter Superclass Name” blank and select “ Recursive ” then click OK. If you don’t get any error messages then you can access the name successfully without issue using built in Windows Management Instrumentation Tester

13. To test further, let’s see if we can access some classes.

a. Pick any class and double click on it to bring up the Object Editor for that class

b. Next click on the “ Instances ” button on the right

c. If it doesn’t sit there hung at “ Operation in progress ” or doesn’t return any error, then access to that class would appear to be okay.

NOTE: Not every class you click in the “ Instances ” button will actually return results. Some classes will and some won’t depending on the class. Don’t sweat it if it doesn’t as long as the box above says “Done”

Repeat this on several classes in the namespace for sanity check just to see if any produce an error message or Operation in progress hangs.

If you did not get any errors connecting to the namespace or accessing some of the classes in that namespace, then your issue may be with the application or whatever method being used outside of Wbemtest that is the problem and would advise opening case with Microsoft if it is a Microsoft application or process, otherwise first contact the vendor of the application for assistance in troubleshooting.

Reference this blog when you open the Support Incident Case with Microsoft as it will help the engineer understand what actions have been taken or followed and will help us track the effectiveness of the blog.

Scenario 2: WMI Invalid Class

To troubleshoot an Invalid WMI Class, you basically would follow the same procedure as above that you would for WMI Invalid Namespace.

Here is a good link that you could probably also click your way thru various links to find the provider .mof for Microsoft classes.

WMI Classes

Scenario 3: WMI Provider Load Failure

Again, you will follow the same procedures as above for testing, and also locating the provider .mof file and associated .dll if one is listed and recompiling and re-registering of that particular provider.

Wmi Repository Corrupted

There are some exceptions where you have accomplished all of the above and from Wbemtest (note I said Wbemtest , not some method outside of Wbemtest ) and you are still getting failures with a namespace, class, or provider. In these scenarios you may have to revert to using the proverbial hammer as a last ditch effort even though the repository check came back as consistent when your ran winmgmt /verifyrepository .

Before doing such, it would be a good idea to open a Support Incident Case with Microsoft for assistance before reverting to rebuilding of the repository if the winmgmt /verifyrepository had come back as Consistent .

IMPORTANT

If this becomes the case, please refer to my Ask the Performance Team Blog article, WMI: Rebuilding the WMI Repository before rebuilding the repository as there are some important gotchas that you need to be aware of.

As a final note, if you are running into a reoccurring WMI corruption issue in your environment, try to exclude the WBEM folder and all subfolders under it from AV scanning. AV scanning is known to cause corruption in WMI.

At this point you may also want to open a Support Incident with Microsoft for further assistance if needed.

Please reference this blog and the following TAG when you open the Support Incident Case with Microsoft, as it will help the engineer understand what actions have been taken or followed and well help us track the effectiveness of the blog.

TAG = WMITBLOG

Next up: WMI: High Memory Usage by WMI Service or Wmiprvse.exe

-Jeffrey Worline