En kolega hade problem med ett gäng servrar som sprutade ut WMI-felmeddelanden… han hittade ett inlägg som Ivan Brugiolo skrev i newsgroup’en microsoft.public.win32.programmer.wmi:
—————8<---------------
From a very old post of mine in this same forum, how to check why WinMmgt became un-usable and how to repair it.
Try to remove, if they are there
HKLM\Software\Microsoft\OLE
"EnableRemoteConnect"="Y"
"LegacyAuthenticationLevel"=dword:00000001
"LegacyImpersonationLevel"=dword:00000001
Some legacy application from the Win9x era are known to create those key that impair many DCOM functionality on the machine.
check the following registry key HKLM\System\Software\Microsoft\WBEM\CIMOM\AutoRecover MOFs it is supposed to have a list of *.MOF and *.MFL files, and it MUST begin with cimwin32.mof
There are ISP connection kits and .NET Framework setups known to corrupt this key.
Please delete it content if it appears to have few files or if it appears corrupt.
check if in %windir%\system32\wbem there are about 40 MOF files.
There are certain applications known to delete them.
If you don’t have them, please recover them from the CD of WinXP.
The complete list is found in %windir%\IFM\wbemoc.inf
Please check the following:
-1- that you system path has still %windir%\system32\wbem in it.
-2- that there are no wmiutils.dll and wbemcomn.dll in the system path that comes before the one in system32\wbem.
c:\>for
%i in ("wbemcomn.dll"
) do (echo %~$PATH:i
)
c:\>for
%i in ("wmiutils.dll"
) do (echo %~$PATH:i
)
check if the wbemutils.dll registered as a COM component comes from the OS or from Visual Studio and/or other development tools. Make sure the OS Supplied one is used.
enable versbose logging
HKLM\Software\Microsoft\WBEM\CIMOM:Logging(REG_SZ) = "2"
HKLM\Software\Microsoft\WBEM\CIMOM:Logging File Max Size (REG_SZ) = "4000000"
find the PID of the svchost.exe process running WinMgmt
HKLM\Software\Microsoft\WBEM\CIMOM:ProcessID (REG_DWORD) = XXX
crosss check the pid
c:\>tlist -s | findstr /i winmgmt
it must be the same as above, if not, trust tlist.exe more than the registry for the steps below.
you can get “tlist .exe” and “kill.exe” (needed later) from http://www.microsoft.com/ddk/debugging/installx86.asp
c:\>sc config winmgmt start= disabled
c:\>kill -f XXX — pid obtained before
c:\>cd /D
%windir%\system32\wbem
c:\WIN\system32\wbem>rmdir /s /q repository
c:\WIN\system32\wbem>rmdir /s /q Logs
c:\WIN\system32\wbem>mkdir Logs
c:\WIN\system32\wbem>for /R
%i in (*.dll
) do (regsvr32 /s
%i)
c:\WIN\system32\wbem>regsvr32 /s fastprox.dll
c:\WIN\system32\wbem>for /R
%i in (*.exe
) do (%i -regserver
) — this will open wbemtest and/or wmic.exe. Just close it
c:\WIN\system32\wbem>sc config winmgmt start= auto
c:\WIN\system32\wbem>regsvr32 wbemupgd.dll — this can take
30 seconds to
2 minutes
c:\WIN\system32\wbem>net start server && net start workstation && net start AudioSrv && net start termservice
after this, please start %windir%\system32\wbem\wbemtest.exe, and connect to the root\cimv2 namespace.
If something goes wrong, please read the logs under %windir%\system32\wbem\Logs, just to see if there is something obviousely wrong there.
After all of this is done, there might be misconfiguration problems that have changed access permission to registry key and files for the NetworkService account.
The NetworkService account is the one running one of the Provider Host.
To test if this can be the problem, you ca add NetworkService to the administrators group
c:\>net localgroup administrators NetworkService /ADD
Please remember to remove it as soon as the misconfiguration problem have been identified
—————8<—————
