Restoring Windows Management Instrumentation (WMI) after a fatal crash

I ran into this situation the other day: my students were testing system function management and two machines in the domain (both running Windows 10) started returning errors when working with Windows Management Instrumentation. The main admin has not yet come out of vacation, I had to remember that I am a former head of the IT Department :)

I will immediately answer third question: without a working WMI, in my opinion, you can only leave a home gaming computer, on which, in addition to games and after watching the video, nothing else is done (except that children learn to program). In other cases, especially on corporate machines, especially in the domain, WMI should work like clockwork. This is my opinion, someone may disagree.

Now about the reasons for what happened: there can be a lot of them. Looking ahead, I will say that on one machine this happened due to the fact that the hard disk ran out of space, and then there was a power failure due to a broken UPS (alas, no one is insured; the servers, of course, are protected from this, and the usual working machine was not). The second one is worse: a non-fatal hard disk failure followed by a BSOD. In general, it is not so important to understand the reasons, the main thing is to find out that the cause is not a virus or an attempt to hack. However, intentional deletion or accidental corruption of system files should also be considered quite closely.

The recovery of the working capacity of the WMI should be carried out in stages, from gentle methods to destructive. You should be prepared for the fact that in the worst case, the system will have to be reinstalled. It is not necessary to remind you once again that most of the commands must be executed as an administrator.

1 stage. Checking the operation of the service.

We check whether the Windows Management Instrumentation (Winmgmt) service is available in the system and whether it is enabled. Calling Services (in Windows 10, the easiest way is through Start/Administration tools/Services, but I prefer in any version of Windows, except the oldest, print on the command line services.msc), search for Инструментарий управления Windows/Windows Management Instrumentation, check if it is running:

If it is not running, we try to start it, set the startup mode to "Automatically". If it is running, we try to restart it (Stop/start it). After that, we check the performance of the WMI. The easiest way to do this is by running any WMI query in powershell (I remind you that powershell in Windows 10 is launched via Start/Windows PowerShell/Windows Power Shell, but it's easier, in my opinion, run a command line with admin rights, and in it already type powershell), for example, this: (you can run another, your favorite :))

Get-WmiObject -List -ComputerName localhost

If you have a loose footcloth of objects, everything is fine. If there are errors, it means that the performance is not restored, we proceed to the second stage.

In the meantime, I will say a few words about the official utility Microsoft WMI Diagnosis. For some reason, everyone vies with her to recommend her as a good assistant when recovery. Alas, I have spent quite a lot of time analyzing the results of this utility: the script has created a bunch of log files, through which you can wade, if you are not in a hurry, you have a lot of time and half a kilo of pu-erh/coffee machine. I figured out the reasons for the failures faster without it. The probability that it can help directly in the immediate restoration of the work of WMI is very small.

2 stage. Non-destructive recovery

It's worth trying first perform library re-registration and recompilation of object property extension files (Managed Object Format, MOF) and the language component of these files (MFL). It is almost guaranteed to work if the attempt to make a WMI request caused an error like "Error in the WMI.MOF file" or any other MOF file. To do this, perform the following operations:

1. Stop the WMI service, be sure to prohibit its autostart
2. Re-register all the libraries in the folder Windows\system32\wbem
3. Reregister the WMI and WMI Provider Host services
4. Start the WMI service and allow it to autostart
5. Recompiling the MOF and MFL files

You can put it all together in a single BAT file and run:

# пункт 1
sc config winmgmt start= disabled
net stop winmgmt
# пункт 2
cd %windir%\system32\wbem
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
#пункт 3
wmiprvse /regserver
winmgmt /regserver
#пункт 4
sc config winmgmt start= auto
net start winmgmt
#пункт 5
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

I note that this way I restored the work of WMI on the first machine. With the second, alas, it did not work. If you don't succeed, it's time to move on to stage 3

3 stage. Destructive restore

In fact, at the 3rd stage, we are recreating the WMI storage, as such, which is located in the folder Windows\System32\Wbem\Repository and is a database that stores data and definitions of standard WMI classes and static information of additional WMI classes, if they were created on your machine.

Before operations, check the status of the hard disk and file system!!!

We check the integrity (On Windows XP and below does not work):

winmgmt /verifyrepository

If the response is different from "The WMI database is consistent", you can perform a "soft restore" with the command:

winmgmt /salvagerepository

With a subsequent restart of the service:

net stop Winmgmt
net start Winmgmt

If a soft recovery does not help, we try to return the storage to its initial state (consequences: all additional WMI classes that have ever been registered in your system will most likely have to be registered again):

winmgmt /resetrepository

With a subsequent restart the system. I note that the second car started working after this stage. The consequences were not very depressing, but serious: I had to reinstall Visual Studio and Delphi Starter, MS Office refused to work and had to be uninstalled manually, deleting folders, files and entries from the registry, followed by re-installation. All our own WMI classes have also been dropped.

But, if this does not help, you will have to delete and create the storage again. This can be done as follows BAT file:

# Остановим службу WMI, обязательно запретив её автостарт
sc config winmgmt start= disabled
net stop winmgmt
# проводим реинициализацию WMI
cd %windir%\system32\wbem
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf
# создаем на всякий случай резервную копию нашего хранилища в папку WMI_VicoNT_Backup
# у вас, разумеется, может быть другое имя папки
if exist WMI_VicoNT_Backup rd WMI_VicoNT_Backup /s /q
rename Repository Repos_bakup
# воссоздаем хранилище
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
# запускаем службу WMI, заново регистрируем WMI Provider Host
sc config winmgmt start= auto
net start winmgmt
wmiprvse /regserver

We overload the computer. If even after these actions, WMI does not work, the only way is to reinstall the system.