WMI Error 0x80004002

  • Article

WMI cases can be fun.  Here were the symptoms:

1.  Trying to "connect" to WMI (right click My Computer -> Manage -> Services and Applications -> WMI Control -> Properties) would give the following error:

"Failed to connect to <local computer>
because "<Null>: No such interface supported"

2.  The following errors were generated in the Application Log:

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1065
Date: 1/9/2006
Time: 6:56:52 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
Windows cannot perform filter check for Group Policy object CN={0D69F9F2-49EA-47AE-BA6A-66FEBC3115D2},CN=Policies,CN=System,DC=CONTOSO,DC=COM. Group Policy processing aborted. For more information, see Help and Support Center at <https://go.microsoft.com/fwlink/events.asp>.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Date: 1/9/2006
Time: 6:56:52 PM
User: NT AUTHORITY\SYSTEM
Computer: SERVER
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this. For more information, see Help and Support Center at <https://go.microsoft.com/fwlink/events.asp>.

Event Type: Error
Event Source: MSExchangeSA
Event Category: Monitoring
Event ID: 9097
Date: 1/9/2006
Time: 7:01:43 PM
User: N/A
Computer: SERVER
Description:
The MAD Monitoring thread was unable to connect to WMI, error '0x80004002'. For more information, click
<https://www.microsoft.com/contentredirect.asp>.

 

OK, so WMI is broken, now what...?? 

 

The first thing we did was backup the c:\windows\system32\wbem\repository folder.

 

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Autorecover MOFs" registry key was used to try to rebuild the WMI repository.  This key is used to rebuild the WMI Repository if it gets corrupt or damaged.  This failed as well (we used to have public articles on this process but they have been "pulled" - probably because it broke so many apps - see my BOLD statement above).  So back to the issue…using the Autorecover MOFs key failed.  It seemed like everything we tried (WMIChk.exe and MofComp.exe for example), we kept getting 0x80004002.  Using "ERR" told us the 0x80004002 error was "E_NOINTERFACE winerror.h".  Ok, we knew that!  We also noted that all the "stuff" we were trying to do with WMI failed very quickly.  So it looked and felt like WMI was not happy all around, not just from an Exchange perspective (per the events above) or from an Active Directory (per the events above).  With a "blank" Repository folder (of course it was BACKED UP, see the BOLD statement above) we re-registered the DLL's in the WBEM directory and restarted the Windows Management Instrumentation service and bingo…!!  We can now connect with WMI.  Then we stopped WMI, moved the contents of the Repository folder out and copied in the original contents (remember we BACKED THEM UP above) and started WMI.  Still able to connect.

Root cause:  WMI DLL's in the c:\windows\system32\wbem folder were unregistered. 

When troubleshooting the WMI, MAKE SURE TO BACKUP THE CONTENTS OF THE REPOSITORY FOLDER (c:\windows\system32\wbem\repository).  There are apps (Exchange and some SBS components for example) that register with WMI that may break if you start playing with the contents of the Repository directory).  If you "rebuild" the WMI Repository from "scratch", you will have to manually register the MOF files for individual components that don't use the Autorecover MOFs key.  For example, here is an Exchange article on how to register the Exchange stuff with WMI:  https://support.microsoft.com/default.aspx?scid=kb;en-us;288590.