Blog Post

Ask The Performance Team

7 MIN READ

WMI: Missing or Failing WMI Providers or Invalid WMI Class

Microsoft

Mar 16, 2019

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.

Go to start-run and type in wmimgmt.msc
Right click on Local Wmi Control (Local)and select properties
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.
Click on the Security tab and expand Root folder. This is where you will see all of the namespace listed for WMI
Find the namespace referenced in the error message you are getting
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

Updated Mar 16, 2019

Version 2.0

wmiseries

CraigMarcho

Microsoft

Joined March 15, 2019

View Profile

Ask The Performance Team

Follow this blog board to get notified when there's new activity

10 Comments

A9G-Data-Droid
Copper Contributor
Oct 03, 2024
! WARNING: HERE BE DRAGONS !
The methods in these comments that recompile all the MOFs are dangerous for at least two reasons documented in this related article: https://techcommunity.microsoft.com/t5/ask-the-performance-team/wmi-repository-corruption-or-not/ba-p/375484

"Note: Under almost no circumstance should you use the script that rebuilds the WMI repository from the MOF files
The script is inherently flawed, for 2 reasons:
If you navigate to the %systemroot%system32wbem folder, and list the MOF files, you see find MOFs named (some provider name)_ uninstall.mof . When you mofcomp those, they remove the classes in the MOF. The script mofcomps everything, so it can very easily install then immediately uninstall the classes, resulting in the class not being accessible. Replaying mofs is often sequence dependent. Example: classes in mof1 can depend on or have associations with classes in mof2. If they aren't present, MOFCOMP will not insert the classes. It's extremely difficult to know what is / is not the right sequence, so any script that simply MOFCOMPs everything is not going to be fully successful.
In addition to causing damage to your system that's almost impossible to fix correctly, if you take that approach you will blow away all information that could be used to determine the root-cause."

You can mitigate the first concern by exluding MOFs with "Uninstall" in their names. However I do not have a way to know which order to compile the MOFs in to ensure dependent MOFs are compiled before they are cited as a dependency. So even with this *safer* script you will end up with a WMI namespace that is incomplete!

Push-Location "$Env:WinDir\System32\Wbem"
Get-ChildItem -Path * -Exclude "*uninstall*" -Force -File | Where-Object extension -match '\.(mof|mfl)' | ForEach-Object {mofcomp "$($_.Name)"}
Get-ChildItem -force -file | Where-Object extension -match '\.dll' | ForEach-Object {regSvr32 /s "$($_.FullName)"}
Restart-Service winmgmt -force
gpupdate /force
NishantBhardwaj
Copper Contributor
Sep 25, 2024
Can someone help me fix this Invalid class issue on my machine .
BlendLog
Copper Contributor
Aug 29, 2024
Eric_Darling Thanks you alot
Mojambo
Copper Contributor
Jun 18, 2024
I also created an account to thank Eric_Darling and SecondBreakfast - Was battling a very strange WMI error when attempting to upgrade Exchange and this solved a months long headache in minutes! Thank you!!
Sland12S
Copper Contributor
May 31, 2024
I have created an account here purely to thank Eric_Darling for his simple and quick fix to a problem that Microsoft wanted my neighbour to reset her whole PC to fix. Eric's fix took about 3 minutes. Microsoft's approach would have meant she would still be reinstalling packages and trying to find licence codes many months down the line.

Thank you Eric

SecondBreakfast

Copper Contributor

Dec 15, 2023

Echoing Jason_Schaefer and rvtprimo, thanks a lot Eric_Darling! This has been an easy fix on several computers. The PowerShell version works, too.

Push-Location 'C:\Windows\System32\Wbem'
Get-ChildItem -force -file | Where-Object extension -match '\.(mof|mfl)' | ForEach-Object {mofcomp "$($_.Name)"}
Get-ChildItem -force -file | Where-Object extension -match '\.dll' | ForEach-Object {regSvr32 /s "$($_.FullName)"}
Restart-Service winmgmt -force
gpupdate /force

rvtprimo
Copper Contributor
Dec 14, 2023
Echoing Jason_Schaefer, thanks a lot for this Eric_Darling . This was really helpful and easy and repaired our WMI problems in a few seconds. I've been beating my head against the wall for a while now trying to rectify this, and I owe you the credit. Cheers!
Jason_Schaefer
Copper Contributor
Oct 01, 2023
Eric, I can't thank you enough for your post. For the past two weeks, we had an issue with our Dell server and Dell's Pro Support was of no help. The issue started after we patched the server and their Dell Openmanage stopped working, DSM SA Data Manager service wouldn't start and we couldn't install BIOS or any firmware update. Your script resolved each issue and if it wasn't for you, we'd still be trying to figure out the issue. Thank you again Eric!
Eric_Darling
Copper Contributor
Sep 01, 2023
We recently had this issue creep up on a few of our corporate devices after patching:

winmgmt /verifyrepository - responds repository is consistent

but in wmimgmt.msc WMI Control Properties we can see the errors:
Failed to initialize all required WMI classes.
Win32_Processor: WMI: Invalid class
Win32 WMISettmg WMI Invalid class
Security information Successful
Win32_OperatingSystem WMI Invalid class

Solution was discovered we needed to restore WMI Namespace class data, and found we diddnt need to research any needed .mof files by using the mofcomp and regSvr32 commands below. Note the commands are listed along with a restart of the Windows Management Instrumentation (WMI) service and gpupdate to test for any errors. Also note in several cases we had to run through the commands a few times until WMI and RSOP errors resolve.

*** Recompile Mof files for WMI errors ***
-run from elevated cmd prompt:
cd C:\Windows\System32\Wbem
for /f %s in ('dir /b *.mof *.mfl') do mofcomp %s
for %i in (*.dll) do regSvr32 -s %i
net stop winmgmt /y
net start winmgmt
gpupdate /force
rejohnson
Iron Contributor
Jul 06, 2023
Thanks so much for the assistance, especially the guidance to register the related dlls. I used WMI Explorer to find the related MOF and DLL files for the classes that became invalid. The www.msdn.com now redirects to learn.microsoft.com and searching for wmi providers didn't provide any clear answers.

Push-Location 'C:\\Windows\\System32\\Wbem'\nGet-ChildItem -force -file | Where-Object extension -match '\\.(mof|mfl)' | ForEach-Object {mofcomp \"$($_.Name)\"}\nGet-ChildItem -force -file | Where-Object extension -match '\\.dll' | ForEach-Object {regSvr32 /s \"$($_.FullName)\"}\nRestart-Service winmgmt -force\ngpupdate /force