WMI: Stop hurting yourself by using “for /f %%s in (‘dir /s /b *.mof *.mfl’) do mofcomp %%s”


 

Applies to:

Windows Server 2016

Windows 10

Windows Server 2012 R2

Windows 8.1

Windows Server 2012

Windows 8

Windows Server 2008 R2

Windows 7

Windows Server 2008

Windows Vista

 

In a newer O.S. (Vista/2008 and newer), to try fixing a corrupt repository, you will run the following commands:

 

Before you begin, you might want to make a backup:

Start, CMD (Run As Admin)

winmgmt /backup %computername%_MM_DD_YEAR.WMI_backup

Note:  Where MM is the month, DD is the date, and YEAR is the year.

 

winmgmt /verifyrepository
winmgmt /salvagerepository
winmgmt /resetrepository


And in those off chances, this doesn’t help you because one of the 3rd party developers instead of appending in “Autorecover MOFs”, they might have end-up overwriting the list.

 

In the old days (Windows XP / Windows Server 2003), if WMI got corrupt, you would run a command similar to this:

 

:: Start of WMI reset that you shouldn’t be using

@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

:: End of WMI reset that you shouldn’t be using

 

Why shouldn’t you use?  Look at the following syntax:

for /f %%s in ('dir /s /b *.mof *.mfl') do mofcomp %%s

 

The script is looping and mofcomp’ing everything in c:\windows\system32\wbem and it’s subdirectory.

But starting with Windows Vista and Windows Server 2008, there are these .mof files:

 

image

 

So the script will register and then uninstall the mof files.  Now when WMI breaks for good, you will be scratching your head.  And perhaps rebuilding the Windows client or Windows Server.

 

 

Note:  The command below won’t register the non-core O.S. apps (Microsoft or 3rd party) since the mof/mfl’s for the non-core OS ones are not in c:\windows\system32\wbem.

So what’s one way of finding out the non-O.S. applications? 

Check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wbem\CIMOM

Autorecover MOFs (Multi-String)

And copy it to Notepad to see the pathing for the .mof and .mfl that were registered.

 

What command should you run instead?

:: Start of WMI reset that you should be using

@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
dir /b *.mof *.mfl | findstr /v /i uninstall > moflist.txt & for /F %%s in (moflist.txt) do mofcomp %%s

:: End of WMI reset that you should be using

 

What’s the secret sauce here?

The modified command is making a list of the mof’s, and then doing a find string, the portion that is important is the /V.

“/V         Prints only lines that do not contain a match.”


 

For details, please visit Jeff Worline’s blog post:

WMI: Repository Corruption, or Not?
https://blogs.technet.microsoft.com/askperf/2014/08/08/wmi-repository-corruption-or-not/

Thanks,

Yong


Comments (1)

  1. John says:

    Hi Yong,
    This powershell command will get all of the non-core MOFS from the registry:

    (Get-ItemProperty -path HKLM:\Software\Microsoft\wbem\Cimom).”Autorecover MOFs”

    You could pipe it to the command or to a text file to re-register as necessary

Skip to main content