PDA

View Full Version : Fixing Corrupted WMI repositories



CJ Goldsmith
December 23 2009, 03:58 PM
Introduction:
WMI (Windows Management Instrumentation) has been observed by our team to become occasionally corrupted which results in an 'Unknown' status within Traverse for all tests associated with a single device. This forum posting is meant to be a short guide to diagnosing and repairing an actively corrupted database so that you can monitor it again through Traverse.

Diagnosing Corruption:
There are a number of possible errors that can cause 'Unknown' status on a WMI test (Firewall / Permissions / Link Failure).

Corrupted WMI repositories can generate a number of possible errors during a WMI Query operation (errors typically do not show up on connection). In order to retrieve a WMI error code the author suggests that you run an instance of a Microsoft provided application called 'Windows Management Instrumentation Tester' (wbemtest).

From a console or the windows run dialog (On the machine experiencing WMI issues) go ahead and type 'wbemtest' you should see an application come up that looks like the following:
http://forums.zyrion.com/images/posts/wmi_repo_corruption/wbemtest.jpg

From here you are going to want to go ahead and hit 'Connect', you will see another dialog window pop up which looks like the following:
http://forums.zyrion.com/images/posts/wmi_repo_corruption/connect_dialog.jpg

Since you are invoking the tool from the machine you are testing (you are connecting to the repository on the local machine), DO NOT use any credentials in the username / password fields. Make sure that you change the namespace field to 'root\cimv2'. Go ahead and hit 'Connect' and you will be brought back to the original screen (now connected to the repository).

From the original screen you will see a number of options no longer greyed out and available to you. Trying to access the repository from this point will generate an error if the repository has become corrupted. The simplest way to initiate an access in my opinion is to choose 'Enum Classes...' which will pop up a dialog that looks like this:
http://forums.zyrion.com/images/posts/wmi_repo_corruption/wbemtest_enum_classes.jpg

Go ahead and leave the superclass name field blank and choose 'Recursive' then choose 'OK'.

At this point you can receive any number of errors, the most common error indicating corruption of the repository in my experience is returned as the string: "Generic Failure". If you see any errors at this point relating to credentials or communication errors chances are you are experiencing an unrelated problem.

Fixing the Repository:
If you have reason to believe that you are suffering from a corrupted repository, you will need to follow the following set of steps to restore the repository. The good news here is that even if the repository is not the issue the operation is generally benign in nature (should not break anything further).

Open up a console and enter the following command:

net stop winmgmt

Then move the folder located at:
%windir%\System32\wbem\Repository
to:
%windir%\System32\wbem\Repository-OLD

now from the command line go ahead and enter the following command:

net start winmgmt

This is going to remove the repository information from underneath the WMI service and force it to rebuild all indexes on start up from scratch (which will create a brand new, non-corrupted, repository).

Conclusion:

At this point you will want to go ahead and go through the testing procedure again in order to verify that the issue has been resolved from the point of view of the WMI tester application (this limits the number of involved variables). If you can verify that the process has worked from the local machine let Traverse continue to poll the tests for at least 2 polling cycles (for rate tests) before continuing to troubleshoot the Unknown status icon.

CJ Goldsmith
April 16 2010, 03:24 PM
I wanted to add a couple of points to this thread:

Forcing a WMI to rebuild it's repository information by stopping the winmgmt service and removing the repository folder has been shown to help treat a number of problem conditions we have seen with WMI which can cause widespread 'unknown' results within Traverse on a single device.

Often though we have found that there can be a number of WMI classes that are missing from the repository once it is rebuilt. It can be safe to force WMI to reregister these classes before restarting the winmgmt service.

the 'mofcomp' command line utility is used to perform this action ( http://msdn.microsoft.com/en-us/library/aa392389(VS.85).aspx ).

To force the more generic classes to re-register you can perform the following set of steps:


cd %SystemRoot%\system32\wbem
for %i in (*.mof) do mofcomp %i

Other application specific mof files can be found throughout the file system, if there is an application that is still not showing up it can be worth searching the local file system for "*.mof" often the file naming convention will provide clues enough to which application it applies to. Search engines are a good alternative which can often help you determine which mof files apply to the application in question.

Registering any mof file within your local wmi repository is usually as simple as:

mofcomp [file path]