Repairing WMI on Windows endpoints without reimaging

WMI is the plumbing under most Windows management. Inventory, software deployment, compliance checks, Group Policy WMI filters, monitoring agents, and a good part of PowerShell all read from it. When the repository on a device gets damaged, none of those things fail loudly. The device just stops reporting, and it looks like a network problem or an agent problem for a while before anyone looks at WMI.

In a fleet of any size you will always have some of these. The useful question is not how to fix one machine by hand. It is how to tell real corruption from something simpler, and then repair the real ones without touching each device individually.

First, confirm it is actually WMI

Do not start with repairs. Start by asking WMI a question that any healthy device can answer.

Get-CimInstance -ClassName Win32_OperatingSystem -ErrorAction Stop |
    Select-Object CSName, Caption, LastBootUpTime

If that returns data, WMI itself is answering and your problem is somewhere else, usually the agent or the specific namespace that agent uses. If it throws, note the error. A timeout, an access denied, and a class-not-registered are three different problems with three different fixes.

Then check whether the service is even running:

Get-Service Winmgmt | Select-Object Name, Status, StartType

Verify the repository before you touch it

Windows has a built-in consistency check. Run it from an elevated prompt:

winmgmt /verifyrepository

It tells you either that the repository is consistent or that verification failed. This is the line that decides what you do next. If verification passes and the device still will not answer queries, the repository is not your problem and rebuilding it will cost you time and risk for nothing.

Salvage before you reset

If verification fails, try the least destructive repair first:

winmgmt /salvagerepository

Salvage attempts to rebuild the repository while keeping what is still readable inside it. On a good number of devices this is where the problem ends. Re-run winmgmt /verifyrepository afterwards and re-test with a real query, not just the return message.

Reset is the last resort, and it has a cost

winmgmt /resetrepository

Reset takes the repository back to its initial state and re-registers the WMI classes that ship with Windows. That is the important limitation: it restores what Windows put there. Classes and namespaces added afterwards by other software are not part of that initial state.

Recompiling MOF files

You will find plenty of guides that tell you to recompile every MOF and MFL file in the wbem folder as a matter of course:

Get-ChildItem C:\Windows\System32\wbem\*.mof, C:\Windows\System32\wbem\*.mfl |
    ForEach-Object { mofcomp $_.FullName }

This does work, and after a reset it can be the thing that brings a specific class back. But it is a shotgun. It recompiles hundreds of files whether they needed it or not, and it takes minutes per device. Reach for it when you know which class is missing and the targeted mofcomp of that one file did not do it, not as step one of a routine.

The rebuild-by-rename approach

The older method still works and is sometimes the only thing that clears a repository Windows will not open at all:

Stop-Service Winmgmt -Force
Rename-Item 'C:\Windows\System32\wbem\Repository' 'Repository.old'
Start-Service Winmgmt

Windows rebuilds the repository on the next start. Two things to know before you run it. -Force is required because other services depend on Winmgmt, and it stops those too, so this is not a no-impact operation on a device someone is using. And keeping the renamed folder means you can put it back if the rebuild makes things worse, which is a courtesy the built-in reset does not give you.

Doing this across a fleet

The single-device version of this is a twenty minute job. The version that scales is a script that makes the decisions for you and reports what it did. The shape that has worked for me:

1. Test with a real query first, and exit early if WMI answers. Most devices in a suspected group are fine, and you want them out of the way quickly.
2. Run the consistency check and record the result. Never repair a repository that verified clean.
3. Try salvage. Verify again. If it passes and the query works, stop there and report success.
4. Only escalate to a reset when salvage did not fix it, and record which devices got one so you know where to check agents afterwards.
5. Report a clear result back to your management platform: healthy, repaired by salvage, repaired by reset, or still broken. The last group is your real work.

The reporting step is the part people skip and the part that matters most. Without it you cannot tell whether the repair worked, and you end up running the same fix against the same devices every month. With it, the number of devices in the "still broken" bucket is your actual queue, and it should shrink.

What not to do

• Do not reset the repository as a first step because it is the fix that appears most often in search results. It is the most destructive option on the list.
• Do not run repairs against devices that verified clean. You will create the problem you were looking for.
• Do not treat reimaging as the default. It is expensive, it moves the cost onto the user, and it usually was not necessary.

Every command here is a built-in Windows tool. Test the process on a small group before running it broadly, and keep the results.

Back to the decoder