First published on TECHNET on Aug 08, 2014
Windows Management Instrumentation failing due to repository being corrupted
) is the database that stores meta-information and definitions for
classes; in some cases the repository also stores static class data as well. If Repository becomes corrupted, then the
service will not be able to function correctly.
Before grabbing that preverbal hammer approach and just rebuilding your repository, ask yourself,
“Is the WMI repository OK?”
Common symptoms that lead to this question are: provider load failure, access denied, class not found, invalid namespace, and namespace not found to mention a few.
If you suspect
or repository corruption,
rebuilding repository is the last thing you should do without verifying this is truly the case
. Deleting and rebuilding the repository can cause damage to Windows or to installed applications. Other steps should be taken first to eliminate other possibilities or to confirm we have repository corruption. Noting here that having a repository too large also creates problems; an issue that can sometimes be interpreted as a corrupt repository, which is not always the case. If issues are due to a large repository, rebuilding the repository is currently the only method available to reduce it back to a working size.
Since I mentioned “large repository”, let me set some guidelines up front. There is no hard fast number per say as to when you will start feeling performance problems with a large repository. As a guideline, if the
file, located in
is 1 GB or larger, then I would recommend rebuilding your repository to reduce it back down to a working and manageable size. If the size is between 600-900 MB, and you are not feeling any noticeable performance issues, then I would recommend against rebuilding the repository.
is corrupted, you can receive various errors and symptoms, depending on what activity was being done at the time. Below is a few errors and symptoms that could indicate that the repository is corrupted:
Unable to connect to rootdefault or rootcimv2 namespaces. Fails returning error code 0x80041002 pointing to WBEM_E_NOT_FOUND.
When we open Computer Management and Right Click on Computer Management (Local) and select Properties, you get the following error: "
: Not Found" or it hangs trying connect
Trying to use wbemtest, it hangs
Strange connection/operation errors (0x8007054e):
get-cimclass : Unable to complete the requested operation because of either a catastrophic media failure or a data structure corruption on the disk.
Check the Windows Application log for events in the past week where Source = Microsoft-Windows-WMI. Look for any of the following WMI event IDs: 28, 65, 5600, 5601, 5614. Any of these could indicate a WMI repository issue or core infrastructure problem.
If you do not find any of these events logged, your next action is to use the built in repository checker. From an elevated command prompt run
". If the repository has an issue, it will respond "repository is not consistent".
If repository check comes back as “consistent”, then look at my other Ask Perf blogs for applicability:
When the WMI service restarts or detects Repository corruption, the self-recovery procedure will trigger automatically in two approaches (one or the other):
AutoRestore: if the VSS backup mechanism enable snapshot the timestamp backup images In the system (ex. Win7 feature: previous fileversion), WMI will apply the AutoRestore approach to restore backup valid images in version queue. (if possible)
AutoRecovery: the rebuild process to generate fresh images of Repository based on registered mofs( listed @ HKLMSoftwareMicrosoftWBEMCIMOM: AutoRecover Mofs).
EVT: 5616 (complete recovery), eventually, there are lots of EVT:63 for mof warning about Localsystem registration of providers.
Note: Under almost no circumstance should you use the script that rebuilds the WMI repository from the MOF files
The script is inherently flawed, for 2 reasons:
If you navigate to the %systemroot%system32wbem folder, and list the MOF files, you see find MOFs named (some provider name)_
. When you mofcomp those, they remove the classes in the MOF. The script mofcomps everything, so it can very easily install then immediately uninstall the classes, resulting in the class not being accessible.
Replaying mofs is often sequence dependent. Example: classes in mof1 can depend on or have associations with classes in mof2. If they aren't present, MOFCOMP will not insert the classes. It's extremely difficult to know what is / is not the right sequence, so any script that simply MOFCOMPs everything is not going to be fully successful.
In addition to causing damage to your system that's almost impossible to fix correctly, if you take that approach you will blow away all information that could be used to determine the root-cause.
If the repository check (
comes back as inconsistent, your first action is to run “
followed by running “
again to see if it now comes back as consistent.
If it is still comes back inconsistent, then you need to run “
.” Before running this,
please read the important note below for Server 2012
-- rebuild based on the registry list of AutoRecover Mofs
Check regkey value is
@ HKLMSoftwareMicrosoftWBEMCIMOM: 'Autorecover Mofs' (**
first line on some OSs is empty, review it in opening the regkey value
If above regkey is empty, copy/paste the regkey value from another machine of equal System/OS to the suspect machine
Run the following command from command prompt with admin rights: “
If you get the error noted below, stop all dependency services on the WMI service by running following command:
net stop winmgmt /y
WMI repository reset failed
Error code: 0x8007041B
Description: A stop control has been sent to a service that other running services are dependent on
NOTE: Applies to Server 2012
We have encountered some issues when running the mofcomp command on
Windows Server 2012
which has caused the Cluster namespace to be removed due to the
contained in the c:windowssystem32wbem folder. It has also caused unregistering class names for Cluster Aware Updating (CAU) because of its cauwmiv2.mof also in the wbem folder. Those could also affect other namespace that have an uninstall type .mof in the wbem folder beyond the two mentioned above.
Furthermore, the uninstall .mof files for servers running Microsoft Cluster are also part of the
folder that is used when you run the
command which will end up having the same effect of first installing the Cluster namespace, then uninstalling it just as if you had run a script to rebuild the repository that contained the “for” command to recompile all of the MOFs in the WBEM folder.
Take the following actions to confirm if the uninstall problem for this scenario exists on your server.
If it doesn’t, then you can run the
winmgmt /reset repository
, otherwise follow my directions below for manually accomplishing rebuild.
Open regedit, and navigate to
, and open “
Copy the data from that string value, and paste it into notepad
Do a search for
. If the cluster provider uninstall has autorecover, it will be listed here
If found, then continue to manual rebuild below, if not found then go ahead and use the
How to manually rebuild repository on Server 2012 Cluster machine when cluster provider uninstall has an autorecover
First ensure you have run
to ensure that it is “
” and that you have tried
to see if it resolves your issue.
Change the startup type for the Window Management Instrumentation (
) Service to disabled.
Service, you may need to stop services dependent on the WMI service first before it allow you to successfully stop
Rename the repository folder: C:WINDOWSsystem32wbemRepository to
Open a CMD Prompt with elevated privileges
Run following command to re-register all the dlls:
for /f %s in ('dir /b /s *.dll') do regsvr32 /s %s
Service type back to Automatic and restart
cd /d c:
((go to the root of the c drive, this is important))
Run following command specifically adopted for 2012 Clustered servers to recompile the MOFs:
“dir /b *.mof *.mfl | findstr /v /i uninstall > moflist.txt & for /F %s in (moflist.txt) do mofcomp %s”
Restart WMI service
As a final note, if you run into a reoccurring corruption issue in your environment with WMI, try to exclude the WBEM folder and all subfolders under it from AV scanning. AV scanning is known to cause corruption and other issues in WMI.
Other repository recovery solutions:
Note: in following solutions (1 & 2), if the backup images (repository) are in large size (>100MB), restoring the repository will take some time.
Apply WMI AutoRestore story in the system to recover the repository image quickly and keep it in sync with previous state.
Enable VSS backup-related features for storing image snapshots
ex. Volume Shadow Copy (VSS), or check any valid copies listed Local Disk(C:) Properties >> Shadow copies
Make sure registry key has following setting:
Frequently snapshot the restore-points of the system (if needed, refer to the following PowerShell scripts)
Replace all of the files in
folder with the files from the backup path found in step 1
The WMI Service has auto start setting, and if it comes back alive, you will not be able to replace the files. The service needs to be in a stopped state (if WMI service is alive at the time, repeat step: 2~3)
If the issue persists or keeps returning, then
at this point you will now need to open a Support Incident Case with Microsoft for further assistance.
Please reference this blog and the following TAG when you open the Support Incident Case with Microsoft, as it will help the engineer understand what actions have been taken or followed and well help us track the effectiveness of the blog.