Home > Windows > Tutorial: How To Fix WMI Corruption

Tutorial: How To Fix WMI Corruption

February 3, 2007 Leave a comment Go to comments

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
4155.359:  Return Code = 0 
4155.359: Starting process:  C:\WINDOWS\system32\wbem\mofcomp.exe
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:


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:

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).
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-PROVIDERS.CSV" clo
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-REPORT.TXT" closed
V2.0_XP___.CLI.SP2.32_MYMACHINE_2007.02.02_17.09.38-STATISTICS.CSV" cl
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:


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:

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
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!


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)

  1. Vincent G.
    July 14, 2012 at 00:07

    Wow, ça a fonctionné!! Merci! 😀

  2. JJM
    May 29, 2013 at 21:02

    Excellent! Thank you for the write up.

  3. Dan
    July 26, 2013 at 00:57

    awesome, thank you for this post – totally solved my problem. I skipped all the trying to figure out what was broke and just rebuilt the repository. Kudos!

  4. Jiri
    September 19, 2013 at 10:54

    Thanks Katy, perfectly manufactured tutorial ! It helped tremendeously in the process solving issues with SCCM agent reinstallation/upgrade. You are golden.

    • December 12, 2013 at 13:43

      Thanks Jiri! Much appreciated.

  5. Eric
    February 19, 2014 at 18:17

    Excellent post. Pointed me to the right direction. Thanks katy!

    In addition to the above post, you can also use winmgmt command to rebuild your repository.

    I used the syntax winmgmt /salvagerepository from the command prompt (with admin privilege). If this fails, you can use winmgmt /resetrepository and this will recreate the WMI repo from scratch. Both of these commands creates a backup of the old repository.

    Note that you still need to stop winmgmt as stated by Katy’s post 🙂


  6. Marcus
    July 18, 2014 at 23:21

    Our production SQL server was having some scary issues due to a failed install / uninstall.

    Thanks for posting to the solution to repair our WMI problem. We’re now nearly 100%.

  7. July 30, 2014 at 09:56

    This is a life saver. I can’t thank you enough!!! The post described the exact problem I was facing and provided the exact solution. Thank you so much for putting in the time and effort to write up this post.

  8. April 7, 2015 at 21:13

    Microsoft couldn’t help me, your post fixed the problem. Thanks!

  9. camoogoo
    May 31, 2015 at 11:46

    Well… Thanks. I have spent the last few months trying to sort this problem. Found your page, and 5 mins later it is all fixed. Im a bit lost for words. You are awesome.

    • camoogoo
      May 31, 2015 at 11:49

      Just saw you had a paypal so I threw $50 your way. Seriously. Thanks.

  10. vedant
    August 21, 2015 at 21:55

    it worked thanks a ton

  11. Willy2
    October 7, 2015 at 19:25

    @Katy: Did you ever try a program called “Windows Repair” ? It also can repair the WMI subsystem. The program has been around for a number of years.

    Website: http://www.Tweaking.com.

  12. Richard A. Schaefer
    February 2, 2016 at 03:54

    Hi Katy. I first came across your article about 2 or 3 years ago. It was instrumental in developing my initial understanding of WMI. I’ve developed a 128KB batch file that fixes the repository without having to delete it and I’ve modified WMIDiag.vbs to work with Windows 8 and 8.1 and will do the same for Windows 10 soon. Do you have any idea where to find .mof files on the web? I used to download them from a site on planetmps.com, but that shut down a year or two ago. Nobody ever writes about what to do if you are missing a .mof file.

  13. Alice
    January 18, 2017 at 12:21

    Awesome! Nothing else worked but the steps in this article did. Thank you!

  14. steph
    August 23, 2017 at 23:22

    thanks – great notes — didnt work for me but wanted you to know best notes & instructions on the entire error code out there !!

  15. Richard A. Schaefer
    August 24, 2017 at 15:07

    I’ve incorporated my work with Windows 10 into WMIDiag.vbs version 2.2 released by Microsoft in 2015. I’ve added Windows 10 support to the WMIDiag software. I now have batch files and .mof files that work with Windows 7, 8, 8.1 and 10 as well as WMIDiag.vbs that works in those environments. My batch files resolve the WMI problems by repairing the repository, but can do a total delete and rebuild if necessary. This is still one of the best tutorials on WMI on the internet, but there are a number of precautions that aren’t taken into consideration. For example, Windows 10 has about 34 uninstall .mof files and Windows 7 and 8.1 have about 32 each. If you mofcomp all .mof files in the WBEM folder, you uninstall more that 30 mof schemes and hundreds of classes. The uninstall .mof files should be renamed before recompiling and then named back. Also, the language specific files are stored in the WBEM\en-US folder, so .mfl files need to be compiled from that folder.

  16. Richard
    November 27, 2018 at 18:10

    I know this has been around while, but it fixed my issue! Thanks for giving such great details!

  17. Steve
    September 6, 2019 at 01:35

    Thank you so much for writing this! Had tried a million things to fix broken WMI on Server 2012 R2 no avail, but the commands you provided under “Recompiling the whole repository (all MOF and MFL files)” did the trick for me! WMI now working again. Thank you, thank you, thank you!

  1. May 20, 2012 at 06:39
  2. July 30, 2014 at 09:04
  3. January 22, 2022 at 00:25

Share your thoughts! Note: to post source code, enclose it in [code lang=...] [/code] tags. Valid values for 'lang' are cpp, csharp, xml, javascript, php etc. To post compiler errors or other text that is best read monospaced, use 'text' as the value for lang.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: