Tutorial: How To Fix WMI Corruption

You might not know what WMI is, and you probably don’t care. This article is for those of you who have applications that aren’t working properly or programs or updates that won’t install because of WMI problems.

What is WMI?

WMI stands for Windows Management Instrumentation, and is primarily responsible for monitoring the performance of various aspects of your system. When you click Control Panel -> Administrative Tools -> Performance, the graphs you see are generated by WMI events.

Windows comes with a default set of performance counters measuring your processor, network, filesystem performance and so on. Applications can install or modify their own counters, or use existing ones if they so wish. All the data managed by WMI is stored in the so-called WMI Repository.

My Scenario

I had upgraded the hardware in a server running Windows Server 2003 from an AMD Athlon-based machine to an Intel Core2Duo. In Windows 2000, XP and Windows Server 2003, one of the first files to load is the HAL (Hardware Abstraction Layer), which bridges the chipset to the rest of the OS. There are several HAL files on the Windows CD and one is chosen at the time Windows is installed depending on the chipset in the machine at the time. If you subsequently change the chipset, the installed HAL no longer works and Windows will not boot. The standard solution to this is to do a repair install from a Windows CD (boot from CD, choose your existing Windows partition and press R to repair install). This replaces the HAL with one compatible with the current chipset in use, but also removes all security updates and Service Packs (unless you’ve made a slipstream CD including all the updates). Therefore, one has to re-apply all the updates after the repair install. In my case, Service Pack 1 would not install, and I traced the problem to WMI corruption. However, this article is equally applicable to any update or application that won’t install because of WMI issues.

What kind of applications are affected by WMI issues?

Anything that monitors your system or makes dramatic changes during installation may be using WMI, for example:

• Service Packs and some critical updates
• Large development tools (Visual Studio, Microsoft SQL Server, IIS, ASP.NET)
• .NET Framework
• System temperature/fan monitoring tools (eg. motherboard vendor-provided monitoring utilities)
• Some device drivers

There are of course other applications which use WMI, but if you’re having a problem installing or using one of the above, WMI issues may be the cause.

How can I tell if I have a WMI problem?

Event viewer

If you see events like this in Event Viewer (Control Panel -> Administrative Tools -> Event Viewer -> Application):

Source: WinMgmt
Type: Error
Category: None
Event ID: 10

Event filter with query “select * from MSMCAEvent_MemoryError where (type = 2147811404) and (LogToEventlog <> 0)” could not be (re) activated in namespace “//./root/subscription” because of error 0x8004100e. Events may not be delivered through this filter until the problem is corrected.

then one or more items in the WMI repository may be corrupted. The quoted part may be different – some examples are MSMCAEvent_PCIBusError, MSMCAEvent_PlatformSpecificError, MSMCAEvent_InvalidError, MSMCAEvent_PCIComponentError, MSMCAEvent_MemoryPageRemoved, MSMCAEvent_CPUError and so on – there are many others, and some may be dependent on the applications you have installed.

WMI Control

Go to Control Panel -> Administrative Tools -> Computer Management. In the left-hand pane, click Services & Applications -> WMI Control, right-click and select Properties. If you see a window like this:

then the WMI repository is corrupted (if you see your processor and version of Windows listed, the WMI repository may still be corrupted but is at least partially working).

Failed installations

If you have tried to install something and it failed (including an update from Windows Update), find the install log (see my article on MSI installation failures to learn how to find the logs). Search for lines with the phrase mofcomp and look at the return code which follows. The return code should always be zero (0); if it is any other value, there is most likely a problem with the WMI repository.

Here’s an example from a failed installation of Windows Server 2003 Service Pack 1:

3726.984: Starting process:  C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
\aspnet_regiis.exe -update
3820.890:  Return Code = 0 
3820.890: Starting process:  C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
\SetRegNI.exe v1.1.4322
3821.156:  Return Code = 0 
3821.156: Starting process:  rundll32 apphelp,ShimFlushCache
3822.031:  Return Code = 0 
3822.031: Starting process:  C:\WINDOWS\system32\wbem\mofcomp.exe
C:\WINDOWS\system32\wbem\wlbsprov.mof
4155.359:  Return Code = 0 
4155.359: Starting process:  C:\WINDOWS\system32\wbem\mofcomp.exe
C:\WINDOWS\system32\wbem\cimwin32.mof
4169.359:  Return Code = 3 
4169.359: DoInstallation:RunInfProcesses for ProcessesToRun Failed
4169.359: Service Pack 1 Setup encountered an error:
An error in updating your system has occurred.
4226.562: Unregistration of sprecovr successful
4227.828: An error in updating your system has occurred.

In the snippet above, various actions (including the first of two mofcomps) complete successfully (Return Code = 0), but the command C:\WINDOWS\system32\wbem\mofcomp.exe C:\WINDOWS\system32\wbem\cimwin32.mof fails with error 3. The install log then shows that installation of the Service Pack has failed, and is rolled back (rollback omitted from snippet above).

Repairing WMI problems

Now we’ll turn to how to fix the WMI repository. After each step below, try running or installing your broken application or update again and re-checking the logs, WMI Control and event viewer if necessary to see whether the problem has been resolved.

Most of the steps below require you to type commands at the command prompt. To open up a command prompt, press START + R to open the Run.. window, type cmd and press Enter.

Security permissions

One of the first and easiest things you should try is resetting the security permissions on the registry and system drive, which will also make sure that WMI is setup with the right permissions. You can do this by grabbing the SubInACL tool from Microsoft and running the following commands from the directory in which you installed it:

cd \path\to\folder\where\you\installed\subinacl
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f 
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f 
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f 
subinacl /subdirectories %SystemDrive% /grant=administrators=f 
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f 
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f 
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f 
subinacl /subdirectories %SystemDrive% /grant=system=f

Naturally, you must be an Administrator to run these commands, and they will ensure that the Administrators group and SYSTEM user have Full Control permissions on the listed registry keys and across all files and folders on the system drive.

Partial repository corruption

Objects are inserted into the WMI repository using a tool that comes with Windows called MOFComp. MOF stands for Managed Object Format, and is a human-readable way of describing items to be added to the WMI repository. These definitions are stored in .mof and .mfl files – the first contains a generalised description, while an .mfl file with the same name as a corresponding .mof file contains localised versions of the same objects. Although applications can place these files wherever they like, they are usually found at:

C:\WINDOWS\system32\wbem

MOFComp compiles .mof and .mfl files into WMI repository objects (items). You can repair a partly corrupted repository by recompiling the MOFs which describe the objects that are corrupted. For example, if object SomeObject is corrupted and the object is defined in SomeFile.mof, you can repair the object by typing:

c:
cd \windows\system32\wbem
mofcomp SomeFile.mof

The problem is, one MOF or MFL file can describe many objects, so how do we know which ones to recompile? The solution is a three-step process:

1. Find out which objects are corrupted
2. Find out which MOF and MFL files define these objects
3. Recompile just those files with MOFComp

1. Find out which objects are corrupted

If you’re getting an error in event viewer, the corrupted object names will be given there; in the event viewer example error earlier in this article, the corrupted object was MSMCAEvent_MemoryError.

If you see a problem in the WMI Control window, the corrupted object name will be given there; in the WMI Control window example earlier, the corrupted object was Win32_Processor.

If you’re getting a mofcomp error in install logs, you don’t need to know which objects are corrupted because you already know the name of the .mof file which defines them, and you can skip forwards to step 3 – in the example install log above, the file defining the corrupted objects was cimwin32.mof.

2. Find out which MOF and MFL files define these objects

There are two ways. The files are human-readable so you can use any text editor that will search the contents of several files at once for the object name. One thing to be aware of is that the files are stored in Unicode format so your editor must be able to cope with that. In the example above where the corrupted object is Win32_Processor, we find by searching the text of each file that the object is defined in cimwin32.mof, and in the file you’ll see a line like this which starts the definition:

class Win32_Processor : CIM_Processor
{

The second way is to download and install WMIDiag – a tool from Microsoft that lets you examine and diagnose WMI from the command prompt. Before you run the tool for the first time on your system, type:

cscript //H:cscript

(this changes the default script host on your system from VBScript to CScript, allowing you to see the output of WMIDiag – you only need to do this once).

Then type (CorrelateClassAndProvider is case-sensitive):

cd \path\to\folder\where\you\installed\wmidiag
wmidiag CorrelateClassAndProvider

This will take a few minutes to run and may give some errors (which you can safely ignore). When it’s done a CSV file (a text file with information sorted by rows and columns, where the columns are separated by commas) will be created containing a list of all known WMI objects and the corresponding MOF files that define them. When the script finishes running the last few lines of output will look like this:

(0) ** WMIDiag executed in 15 minutes.
(0) ** WMIDiag v2.0 ended on Friday, February 02, 2007 at 17:24 (W:96 E:321 S:1).
(0) ** CSV file "C:\DOCUMENTS AND SETTINGS\KATY\LOCAL SETTINGS\TEMP\WMIDIAG-
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-PROVIDERS.CSV" clo
sed.
(0) ** TXT file "C:\DOCUMENTS AND SETTINGS\KATY\LOCAL SETTINGS\TEMP\WMIDIAG-
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-REPORT.TXT" closed
.
(0) ** CSV file "C:\DOCUMENTS AND SETTINGS\KATY\LOCAL SETTINGS\TEMP\WMIDIAG-
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-STATISTICS.CSV" cl
osed.
(0) ** LOG file "C:\DOCUMENTS AND SETTINGS\KATY\LOCAL SETTINGS\TEMP\WMIDIAG-
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38.LOG" closed.

It’s the file ending in -PROVIDERS.CSV that we’re interested in. You can open this in a text editor but it’s easier to read if you have a spreadsheet application like Excel available. Here’s an example snippet:

I’ve hidden some of the columns here so you can just see what’s relevant. I’ve searched through the spreadsheet to find the name of the corrupted object I’d like to fix – Win32_Processor in this example – and highlighted the row so we can easily see that the MOF file which defines it is C:\WINDOWS\SYSTEM32\WBEM\CIMWIN32.MOF.

3. Recompile just those files with MOFComp

All that remains now is the recompilation step. Repeat these commands for each file that needs to be recompiled. Always compile MOFs first, then their corresponding MFLs.

mofcomp \path\to\corrupted\file.mof
mofcomp \path\to\corrupted\file.mfl

In the Win32_Processor example above, we would type:

mofcomp C:\WINDOWS\SYSTEM32\WBEM\CIMWIN32.MOF
mofcomp C:\WINDOWS\SYSTEM32\WBEM\CIMWIN32.MFL

Don’t worry if you get an error saying the .mfl file could not be found – not all .mof files have corresponding .mfl files.

If you get an error while compiling one of the .mof files – especially if the error code is 0X80041002, skip the following paragraphs and start reading from the section entitled “Rebuilding the WMI repository from scratch.”

Recompiling the whole repository (all MOF and MFL files)

If you’re still getting errors you can try recompiling everything using some brute force at the command prompt:

c:
cd \windows\system32\wbem
for /f %s in ('dir /b *.mof *.mfl') do mofcomp %s

This may take a while depending on the complexity of your installation. The script will compile all the .mof files in the folder followed by all the .mfl files. Pay attention to any errors – there shouldn’t be any. If there are, continue on to the next section.

Rebuilding the WMI repository from scratch

If you get an error like this when compiling a MOF file:

C:\WINDOWS\system32\wbem>mofcomp cimwin32.mof
Microsoft (R) 32-bit MOF Compiler Version 5.2.3790.1830
Copyright (c) Microsoft Corp. 1997-2001. All rights reserved.
Parsing MOF file: cimwin32.mof
MOF file has been successfully parsed
Storing data in the repository...
An error occurred while processing item 65 defined on lines 661
- 674 in file cimwin32.mof:
0X80041002 Class, instance, or property 'CIMTYPE' was not found.
Compiler returned error 0x80041001

or an error like:

0X80041002 Class, instance, or property 'Name' was not found.

then you need to rebuild the WMI repository from scratch.

This procedure is almost guaranteed to fix any WMI repository issues as it basically deletes the existing repository and creates a new one. However, you may have to reinstall some applications that have added objects to the repository as they will be lost, which may cause the applications to malfunction.

If you are using Windows Server 2003 Service Pack 1 or later, you can repair the repository with minimal data loss by typing (case-sensitive):

rundll32 wbemupgd, CheckWMISetup
rundll32 wbemupgd, RepairWMISetup

Otherwise, you can type the following commands, which will:

• Stop the WMI service
• Backup the old repository
• Restart the WMI service

c:
cd \windows\system32\wbem
net stop winmgmt
rename Repository Repository.old
net start winmgmt

At this point there will be no repository at all. In order to create one, you’ll have to run a WMI-using application. The simplest way to do this is to go back to Computer Management and open Services & Applications -> WMI Control, then right-click and choose Properties. There will be a delay of some seconds while a new repository is created. You should then find that the WMI Control properties open properly – showing your processor and OS – and that any previously failed installation attempts due to WMI should now work.

When WMI rebuilds the repository automatically, it uses a pre-defined list of MOFs and MFLs to compile. You may have installed applications which added new MOF and MFL files but that aren’t automatically recompiled when the repository is rebuilt. To reinstall any missing objects, follow the steps in the section above to recompile everything.

I hope you found this tutorial useful, please leave your feedback below!

I’m a software developer with very limited work capacity due to having the debilitating illness M.E. – please read my article Dying with M.E. as a Software Developer and donate to the crowdfund to help me with my bucket list if you found this article useful. Thank you so much!

References

Access is denied message when installing Windows XP SP2 (SubInACL solution)
Microsoft .NET Framework 3.0 RC1 installation issues forum thread (WMIDiag suggestion)
Error in Event Logs: Citrix Monitoring Script Event 2 (MOF/MFL compilation script)
Microsoft TechNet: WMI Isn’t Working! (repository rebuilding)