N-central Troubleshooting
Resynch WMI on Server 2012
Last Modified
Wed Nov 30 21:41 GMT 2016
Description
The following steps are to be used when resynching WMI repository is required for troubleshooting WMI related monitoring issues on a device.
Environment
- All N-able N-central versions
- Windows 2012 servers
Solution
If WMI is corrupted, you can receive various errors and symptoms, depending on what activity was being done at the time. Below are 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 you open Computer Management and Right Click on Computer Management (Local) and select Properties, you get the following error: "WMI: Not Found" or it hangs trying connect
- 0x80041010 WBEM_E_INVALID_CLASS
- Trying to use wbemtest, it hangs
- Schemas/Objects missing
- 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.
At line:1 char:1
+ get-cimclass -Namespace rootcimv2TerminalServices
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-CimClass], CimException
+ FullyQualifiedErrorId : HRESULT 0x8007054e,Microsoft.Management.Infrastructure.CimCmdlets.GetCimClassCommand
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 "winmgmt /verifyrepository". 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:
WMI: Missing or Failing WMI Providers or Invalid WMI Class
WMI: High Memory Usage by WMI Service or Wmiprvse.exe
How to troubleshoot High CPU Usage by WMI Components
WMI Self-Recover
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)
- EVT: 65 (start restore) / 66 (succeed recovered with VSS Path)
- 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 C:\WINDOWSsystem32wbem folder, and list the MOF files, you see find MOFs named (some provider name)_uninstall.mof. 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 (winmgmt /verifyrepository) comes back as inconsistent, your first action is to run "winmmgmt /salvagerepository" followed by running "winmgmt /verifyrepository"again to see if it now comes back as consistent.
If it is still comes back inconsistent, then you need to run "winmgmt /resetrepository." Before running this, please read the important note below for Server 2012.
Force-recovery process- rebuild based on the registry list of AutoRecover Mofs
- Check regkey value is empty or not @ 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: "Winmgmt /resetrepositoy"
- If you get the error noted below, stop all dependency services on the WMI service by running following command:
net stop winmgmt /y
then run
Winmgmt /resetrepositoy
WMI repository reset failed
Error code: 0x8007041B
Facility: Win32
Description: A stop control has been sent to a service that other running services are dependent on
NOTE: Applies to Server 2012