Windows - Maintenance Tasks - Repair WMI Repository

What the WMI repository repair does

This Automox Worklet™ verifies the integrity of the Windows Management Instrumentation repository on every Windows endpoint in scope and rebuilds it when corruption is found. The evaluation phase calls winmgmt /verifyrepository and looks for the string WMI repository is consistent in the output. A consistent repository exits 0 and reports the endpoint compliant. Anything else exits 4211 and queues the endpoint for remediation.

The remediation phase first stages a backup of the live repository to %ProgramData%\amagent\WorkletCache\WSE-810 using winmgmt /backup with a timestamped .bak filename. The Worklet then runs winmgmt /salvagerepository to recover what it can in place. It re-registers every DLL under %SystemRoot%\System32\wbem (and %SystemRoot%\SysWOW64\wbem on 64-bit hosts) with regsvr32 /s, and re-registers the WMI Provider Host binaries (unsecapp.exe, WMIADAP.exe, WMIApSrv.exe, WmiPrvSE.exe, scrcons.exe) using wmiprvse /regserver.

Every .mof and .mfl file in the wbem directories is then recompiled with mofcomp so the class definitions are repopulated from source. The Worklet restarts the Winmgmt service and finishes by calling winmgmt /resetrepository to rebuild the repository to its post-install baseline. The script also handles 32-bit and 64-bit architectures by detecting Is64BitOperatingSystem and re-launching through sysnative when the agent process is 32-bit on a 64-bit host.

Why repair a corrupted WMI repository

WMI is the substrate every management tool on Windows reads from. Once the repository under %SystemRoot%\System32\wbem\Repository is corrupted, Get-WmiObject and Get-CimInstance hang or return 0x80041002, Group Policy stops applying, and Windows Update fails its WUA self-check. Antivirus inventory drops to empty, and Automox itself loses the hardware and software facts it relies on for policy targeting. Corruption is rarely loud. It tends to surface as an endpoint that silently disappears from compliance reports while patches stop landing.

A corrupted WMI repository breaks Group Policy refresh, Windows Update detection, monitoring agents, and any tool that queries Get-WmiObject or Get-CimInstance, and the standard repair sequence (verify, salvage, re-register the providers, recompile the MOFs, reset as a last resort) is exactly the kind of work that does not scale by hand. This Worklet runs the repair sequence on every host flagged by the evaluation phase, captures a backup of C:\Windows\System32\wbem\Repository before it touches the database, and surfaces winmgmt failures in the Automox Activity Log instead of leaving an endpoint half-rebuilt.

How WMI repository repair works

1. Evaluation phase: The Worklet wraps winmgmt /verifyrepository in a 64-bit shell and matches the output against WMI repository is consistent. A match exits 0 and reports compliant. Anything else writes the verifier output to the activity log and exits 4211, which marks the endpoint for remediation on the next policy run.

2. Remediation phase: The script creates %ProgramData%\amagent\WorkletCache\WSE-810, writes a timestamped backup with winmgmt /backup, and exits 2 if the backup file is missing. It then runs winmgmt /salvagerepository, re-registers every DLL under the wbem directories with regsvr32 /s, re-registers the WMI Provider Host binaries with wmiprvse /regserver, recompiles every .mof and .mfl file with mofcomp, restarts the Winmgmt service with Restart-Service -Name Winmgmt -Force, and finishes with winmgmt /resetrepository.

WMI repair requirements and exit codes

• Windows 10, Windows 11, or Windows Server 2016 and later endpoints with WMI installed (the script targets both WORKSTATION and SERVER device types)

• Local Administrator context for the Automox agent so it can restart the Winmgmt service and write to the wbem directories – the default agent account already meets this

• PowerShell 3.0 or later available at %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe (the script also handles sysnative redirection on 64-bit hosts running a 32-bit agent process)

• Write access to %ProgramData%\amagent\WorkletCache\WSE-810 for the timestamped .bak file the script generates with winmgmt /backup before touching the repository

• Exit codes: 0 (repository consistent, no action), 4211 (corruption detected, endpoint queued for remediation), 2 (backup step failed and remediation halted before any destructive change)

Expected WMI state after repair

After a successful remediation run, winmgmt /verifyrepository returns WMI repository is consistent, Get-WmiObject -Class Win32_OperatingSystem responds with the expected facts, and the Winmgmt service reports Running. Inventory-dependent tools – Automox device facts, Windows Update, antivirus management consoles, and any in-house monitoring that calls WMI – regain visibility on the next collection cycle. Validate by re-running the evaluation phase as a one-off policy and confirming exit code 0 in the activity log.

Be aware that winmgmt /resetrepository restores the repository to its post-install baseline, which clears custom WMI namespaces, classes, and provider instances that third-party agents registered after the OS was deployed. Plan for a follow-up reinstall or repair of monitoring agents, EDR clients, or System Center components that publish their own WMI providers. Automox recommends a reboot of the endpoint after the Worklet completes so all services re-bind cleanly. The timestamped .bak under %ProgramData%\amagent\WorkletCache\WSE-810 stays in place for manual rollback with winmgmt /restore if a downstream agent does not recover on its own.