The Importance of Troubleshooting WMI Part 2

  • Article

To continue my discussion regarding the importance of troubleshooting WMI, I want to move the focus to a devising a targeted approach when troubleshooting so you can optimize the time it takes for you to zero in on the issue.

WMI issues generally fall into the following areas:

Configuration Issues: These are issues relating to the configuration of WMI on the local (or mostly remote) machine including:

•    DCOM Security\Permissions or Configuration
•    Firewall Configuration
•    WMI namespace security

Infrastructure Issues: These are issues related to WMI components including:

•    WMI service setup
•    DCOM registration problems
•    Missing WMI classes
•    Improper WMI provider registration
•    Missing System files
•    WMI repository corruption (*GASP*)
•    Deleted WMI repository (*HEADDESK*)

WMI Managed Entity Issues: These may be issues related to the extensible WMI components including:

•    Security requirements
•    Not running (e.g service, application) or de-installed application
•    External dependencies

 
As I mention in my last article, you obviously want to verify your firewall rules (which are built into versions of Windows since Windows XP.)

WMI (ASync) Properties – In
Program: %SYSTEMROOT%\System32\WBEM\unsecapp.exe

WMI (DCOM) – In
Port: TCP 135
Program: %SYSTEMROOT%\System32\svchost.exe

WMI (WMI) In-Out
Program: %SYSTEMROOT%\System32\svchost.exe

Then you will want to zero in on the error itself.

 
0x800706BA – RPC Server Unavailable

When this error appears during connecting to a WMI namespace:

•    The machine does not exist.  
•    The machine cannot respond because the appropriate firewall exceptions have not been made. Check firewall settings.

When this error appears during operation it could be:

•    The client machine doesn’t have correct firewall settings for asynchronous call backs.  
•    Connecting to a machine which doesn’t exist.

0×80070005 – E_ACCESS_DENIED

When this error occurs during connecting to a WMI namespace –
•    The username/password does not exist.  
•    The user does not have the remote launch or remote activation options set.  
•    Check dcomcnfg.exe under the COM Security Tab.  

When this error occurs during operation –
•    The specific user does not have the DCOM permissions.  
•    Minimum authentication level needed for the namespace is more than what is used.  
•    Check the settings on the Default Properties tab of DCOMCNFG.EXE.
 
0×80041003 – WMI Access Denied

During connecting to a WMI namespace – The user does not have the appropriate WMI permissions on a namespace.  Check WMIMGMT.EXE and permissions for that namespace.

During operation – Specific user doesn’t have WMI access permissions.

0×80041001 – Unknown Error

Ah, the UNKNOWN ERROR. Often this is cause by a 3rd-party provider or non-OS software that extends the Repository has been either removed from the environment and left WMI subscriptions in the repository or is malfunctioning.
Enable WMI Verbose logging on the server and review the WMI logs in %SYSTEMROOT%\system32\wbem\logs.   The Wbemess log will show which WMI subscription was sending notifications when the criteria was met.  

You will need to follow the steps below to remove the WMI subscriptions once you isolate them:

1. Click Start, run, type Wbemtest then type root\cimv2\applications\ and click “Connect” button
2. Click on ‘Enum Classes’, click the Recursive radio button, click OK.
3. Scroll down until you see _FilterToConsumerBinding class.  Double-click on it.
4. Click the “Instances” button on the right hand side.
5. Choose those you isolated and click on the delete button.

When you retrieve a managed resource in a WMI script, the CIMOM (WMI service) looks for the managed resource’s blueprint (class definition) in the default namespace if no namespace is specified. If the CIMOM cannot find the managed-resource class definition in the default namespace, a WBEM_E_INVALID_CLASS (0×80041010) error is generated.

0x8007000E – Not enough Storage is available to complete this process

This usually indicates a problem with a provider, handle leak, memory leak, or other problem tied to WMI functionality.

Troubleshooting Checklist

1.    Use the WMI Control to ensure that the service is working on the local system.
2.    If the problem involves communicating with a remote system then use the WMI Control to test the ability to connect to the remote system
3.    If the service appears to be working, use verbose logging to see the activity (queries) that is being processed by the service and to identify any problems. You can also use WMICHK and WMIDIAG to check the health of the service and the hosted providers.
4.    For Access Denied type issues verify that the DCOM and WMI Service settings are at default values, and the Network Service account has been granted impersonation rights.
5.    Check the service settings if the WMI service fails to start or if client programs cannot communicate with the service. In some cases you may need to reregister all the modules to recover the service.
6.    If queries appear to be returning an incomplete results set, try increasing the buffer thresholds.
7.    If problems persist, make a backup copy of the existing WMI database (repository), and then try building a new one.