WMI Corruption/Reports Wrong Information

vScope uses WMI to query computers running Microsoft Windows.

Sometimes there are problems when scanning specific machines with WMI. The problems can manifest themselves as WMI queries timing out and machine scans completing with “PARTIAL_OK” status. PARTIAL_OK means that the vScope WMI probe did not complete successfully on all queries performed towards the target computer.

vScope uses high level calls available in WMI so the root cause to the problems is most likely located in the WMI repository.

Let’s define some actors in the vScope discovery process:

  • vScope – The machine running vScope and performing the discovery
  • Target – The machine that vScope is scanning using the vScope WMI Probe

Reading on you will find proposed repair options for WMI and ways to detect if there is something wrong with the WMI repository on the target machine.

Before we do anything, the first step is to reboot the target computer and attempt to scan the target again. If this does not help and the problem did not appear to be a temporary one, continue below.

Detecting WMI repository problems

Using WMI Diagnosis Utility

WMIDiag is a tool from Microsoft and can be downloaded here.

The tool is actually a VB Script and supports Windows 7, Windows 8, Windows 8.1, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Vista and requires Windows Script Host.

How to run the tool

  1. Download and execute the tool on the target computer. Choose a folder to decompress the files to.
  2. Open a command prompt with administrator rights. Browse to the folder where the files were extracted.
  3. Run the script: cscript WMIDiag.vbs

The script will analyze various parts of the WMI system and create log files. They are located in %TEMP% and named:

  • %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_NAME_2017.01.25_09.32.46.LOG
  • %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_NAME_2017.01.25_09.32.46-REPORT.TXT
  • %TEMP%/WMIDIAG-V2.2_WIN8.1_.CLI.RTM.64_MACHINE_NAME_2017.01.25_09.32.46-STATISTICS.CSV

Optionally the script will zip these files. If you need help analyzing the results of a WMIDiag run you can send us the files and we will help you try analyze any problems found by the tool.

The TXT file usually contains boiled down information about any problems found. If the script fails to execute due to WMI corruption the LOG file will contain information up to the point of failure.

Using winmgnt

For Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 and later, you can run winmgmt /verifyrepository from a command prompt.

If the repository is consistent you should see “WMI repository is consistent” returned by the call. If the repository as reported back as inconsistent, go to the “Solving WMI repository problems” heading.

Manually inspecting the WMI repository

The WMI repository is located at %WINDIR%\System32\wbem\Repository and the sum of all the files in that folder constitute the repository size. A normal repository should be not be several hundred megabytes in size.

A very large repository can cause slow WMI queries and even cause problems with Active Directory GPOs never being applied if they rely on WMI filters.

If the WMI repository seems to be very large and even grow in size every day, proceed to “Possible reasons for a growing WMI repository” section.

Solving WMI repository problems

Using winmgnt

If the repository is inconsistent you may try to rebuild the repository by either salvaging or resetting the repository. On Vista and newer you can use the following command from an elevated command prompt to salvage the repository:

  • winmgmt /salvagerepository

The command will attempt to salvage the content of the inconsistent repository and merge it into a rebuilt repository. If that fails you may try to reset the repository.

Warning This will result is third party products not working until you re-run their setup which will re-add their MOF-files to the WMI repository.

  • winmgmt /resetrepository

This will reset the repository to the initial state of the OS from when it was first installed. Note the warning before you do this.
Rebuilding repository MOF files and re-registering DLLs

If salvaging using winmgmt does not help or you do not wish to reset the repository you can try to recompile all MOF files found in the WMI repository folder and re-register all DLL files, WMI service and provider. Copy the following lines to a BAT file:

@echo off
sc config winmgmt start= disabled
net stop winmgmt /y
%systemdrive%
cd %windir%\system32\wbem
for /f %%s in (‘dir /b *.dll’) do regsvr32 /s %%s
wmiprvse /regserver
winmgmt /regserver
sc config winmgmt start= auto
net start winmgmt
for /f %%s in (‘dir /s /b *.mof *.mfl’) do mofcomp %%s

Execute the BAT in an elevated command prompt and when it has completed, reboot the machine. After the reboot, attempt to scan the machine with vScope.

Updating WMI performance counters

To make sure performance information in the WMI is consistent you may attempt to use the following techniques to refresh, resync or reload the performance counters.

Refresh

WMIADAPT (http://msdn.microsoft.com/en-us/library/aa394528(VS.85).aspx) command to refresh the performance counters. To use wmiadapt, open an elevated command prompt.

  • wmiadapt /f

Parses all the performance libraries on the system and refreshes the classes derived from Win32_PerfRawData and Win32_PerfFormattedData.

  • wmiadapt /r

Parses all the Windows Driver Model drivers on the system to create performance objects.

Resync

Using winmgmt you can attempt to correct corrupted performance counters. Using an elevated command prompt:

  1. winmgmt /clearadap (not needed on systems newer than Windows Server 2003)
  2. winmgmt /resyncperf

Reload

Using lodctr you can attempt to reload the performance counters. In an elevated command prompt, type:

  • lodctr /r

Possible reasons for a growing WMI repository

This is a list of possible causes for growing and very large WMI repositories and proposed solutions.

RSOP logging

It has been observed that on Windows 2008 machines where a lot of users constantly log in and out (for example XenApp) the RSOP (Resultant Set of Policy) logging can result in the WMI repository growing uncontrollably and even become corrupted.

The repository can be rebuilt and repaired with the methods described previously but it will not fix the original problem.

If you suspect that RSOP logging can be a cause for a growing or corrupt WMI repository you can try to disable RSOP logging. Note: This will not fix an already large or corrupt WMI repository.

  • Windows 2003: Computer Configuration > Administrative Templates > System > Group Policy -> Turn off Resultant Set of Policy logging
  • Windows 2008: Computer Configuration > Policies > Administrative Templates > System > Group Policy -> Turn off Resultant Set of Policy logging

After disabling the logging, rebuild or repair the repository using the methods described previously.

Further reading

Leave a Reply