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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.