! 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