WMI Invalid class but "WMI repository is consistent"

Question

On my Windows 10 Pro 64-bit PC, when I go to WMI Control in Computer Management under "Services and Applications" and select "More Actions" -> Properties, it displays the following:-

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

However, when I run command "winmgmt /verifyrepository" in an elevated command prompt (as advised in many web-pages) it reports: "WMI repository is consistent" which, I'm led to believe means the WMI Repository is NOT corrupt. How do I fix this?

Gossamer

Answer 1

I had the same problem and the solution was ran winmgmt /resetrepository in the cmd with administrator privilege. About the cause of the problem according to this information source is because Antivirus scanning cause corruption in WMI https://techcommunity.microsoft.com/t5/ask-the-performance-team/wmi-missing-or-failing-wmi-providers-or-invalid-wmi-class/ba-p/375485

Dropping

Answer 2

Had the same issue creep up on a few of our corporate devices:

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 ***

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

Leporine

WARNING: HERE BE DRAGONS! There is microsoft article where they warn against this method of recompiling all the MOFs:techcommunity.microsoft.com/t5/ask-the-performance-team/… – Distiller

Answer 3

I try in several ways.

First way
I ran the commands given below from the Admin command prompt to reset WMI components
From the command prompt navigate to C:\>windows\system32\wbem

regsvr32 /s %systemroot%\system32\scecli.dll

regsvr32 /s %systemroot%\system32\userenv.dll

regsvr32 cimwin32.dll

mofcomp cimwin32.mof

mofcomp cimwin32.mfl

mofcomp rsop.mof

mofcomp rsop.mfl

for /f %s in ('dir /b /s *.dll') do regsvr32 /s %s

for /f %s in ('dir /b *.mof') do mofcomp %s

for /f %s in ('dir /b *.mfl') do mofcomp %s

regsvr32 wmisvc.dll

wmiprvse /regserver

Second way
From the command prompt navigate to C:\>windows\system32\wbem

I ran the below command and it worked.

WinMgmt /?

Hooknose

Answer 4

Recompiling the MOFs are a commonly suggested solution all around the internet. Then I found this article that states:

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:

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

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

We can guard against the uninstall MOFs by excluding them, but this doesn't address the concern about order of operations. This will compile them alphabetically. If a MOF is compiled before it's dependencies, you will end up with an incomplete namespace model.

So while this is a bit safer, it is still not a perfect solution:

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

Distiller