Thoughts from the EPS Windows Server Performance Team
Good morning AskPerf! Sanket Jagtap here from Platforms Team here to discuss an interesting issue I recently worked. My customer had a Windows 2008 R2 Server, and could not connect locally to WMI. When they ran “wmimgmt.msc” and tried to connect, the following error appeared:
Failed to connect to <local computer> because "Win32: The system cannot find the path specified."
When this failed, the following events were recorded to the Application log:
Log Name: Application Source: Microsoft-Windows-WMI Date: <Date/Time> Event ID: 28 Task Category: None Level: Error Keywords: Classic User: N/A Computer: <Computer Name> Description: Failed to Initialize WMI Core or Provider SubSystem or Event SubSystem with error number 0x80070003. This could be due to a badly installed version of WMI, WMI repository upgrade failure, insufficient disk space or insufficient memory.
Log Name: Application Source: Microsoft-Windows-WMI Date: <Date/Time> Event ID: 43 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: <Computer Name> Description: Windows Management Instrumentation ADAP failed to connect to namespace \\.\root\cimv2 with the following error 0x80070003
We checked the WMI Security tab, and the Root namespace was missing, as well as under the Advanced tab:
During the course of troubleshooting, we tried running “winmgmt /verifyrepository”, however it failed with a similar error:
C:\>winmgmt /verifyrepository WMI repository verification failed Error code: 0x80070003 Facility: Win32 Description: The system cannot find the path specified.
At this point, we decided to run the WMIDiag Tool (WMIDiag 2.1) to help troubleshoot this issue. The WMIDiag log reported the same error multiple times for most of the Root namespace:
1843 12:43:16 (0) ** - Root, 0x80070003 - The system cannot find the path specified. Error Result: 0x80070003 ( -2147024893 ) ID Defined as: ERROR_PATH_NOT_FOUND Message Text: The system cannot find the path specified.
We then popped open the Registry and browsed to the following key:
We compared a working to a non-working registry and made the following discover:
The registry “Type” was set to REG_SZ instead of REG_EXPAND_SZ. We took a backup of the CIMON folder, then deleted the old “Repository Directory” value and created a new one using the REG_EXPAND_SZ type. After a restart, WMI now successfully connected to the Repository/Default Namespace.
Unfortunately, we were unable to determine what changed this value, however it could have been a user change, some type of script, or caused by an application.
- Sanket Jagtap
Good catch. I'll have to remember this one in the future. I've run into too many failed WMI queries. Perhaps I will build this in as a preliminary check when I run Get-WmiObject as a sanity check.
Nice article!!! Did you also consider running a Procmon on a working and Non-working machine ?