The WMI Repository "%windir%System32\Wbem\Repository" is the database that stores meta-information and definitions for WMI classes; in some cases the repository also stores static class data as well. If the Repository becomes corrupted, then the WMI service will not be able to function correctly.
If you suspect WMI or repository corruption, rebuilding repository is the last thing you should do. Deleting and rebuilding the repository can cause damage to the system or to installed applications. Other steps should be taken first to eliminate other possibilities or to confirm we have repository corruption. An extremely large Repository also creates problems and 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 the repository size.
It's a good idea to always capture a WMIDiag report for any WMI related issues:
If WMI is corrupted, you can receive various errors depending on what activity was being accomplished at the time. Also Core console may show agent's disks as empty.
Also issues related to: Unable to protect agent due to issue getting agent metadata.
Trying to protect an agent you may see the following error in the agent logs.
ERROR 2023-10-26T21:57:16 Replay.ServiceHost.Implementation.Hosting.ServiceHost (RequestUri=https://AgentName:8006/apprecovery/api/agent/metadata/summaryMetadata ClientAddress=xxx.xxx.xxx.xxx:55248)
Service Host Error: Service error while handling request [PUT https://AgentName:8006/apprecovery/api/agent/metadata/summaryMetadata]: Not found
Request Uri: https://AgentName:8006/apprecovery/api/agent/metadata/summaryMetadata
Client Address: xxx.xxx.xxx.xxx:55248
System.Management.ManagementException depth 0: Not found (0x80131501)
Below are a few scenarios/errors that indicate repository corruption:
How to test WMI:
You can use wbemtest or a powershell command to test WMI.
Knowledge Article 4033088 Describe step by step how to test WMI from a remote computer and also locally.
Actions to try:
First try the following actions to see if they resolve your issue:
a. Re-register all of the dlls and recompile the .mofs in the wbem folder and re-registering WMI Service and Provider. You can use the following script by saving to txt file then renaming to .bat and running from command prompt with admin right and changing focus to following directory: C:\Windows\System32\Wbem.
:: Start of WMI reset
sc config winmgmt start= disabled
net stop winmgmt /y
for /f %%s in ('dir /b *.dll') do regsvr32 /s %%s
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
b. Reboot the machine and test WMI
Next, check the repository for consistencies:
Open command prompt as Adminstrator and run the next command:
If repository is found to be inconsistent:
a. Run from elevated command prompt:
Note this command will take the content of the inconsistent repository and merge it into the rebuilt repository if it is readable.
If the above doesn’t work, then run:
Note this will reset repository to the initial state when the OS was first installed.
If /salvagerepository or /resetrepository does not resolve the issue, then proceed to rebuild the WMI repository or ask Microsoft Support to troubleshoot WMI.
Warning: Rebuilding the WMI repository has resulted in some 3rd party products not working until their setup is re-run & their MOF re-added back to the repository.
Finally, install latest hotfixes for WMI as they can help prevent issue from recurring. If you continue to have recurring WMI repository corruption issues on same machine, please engage a Microsoft Support Engineer for further troubleshooting and assistance.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Nutzungsbedingungen Datenschutz Cookie Preference Center