-----Original Message-----
Hello,
- The WMICHK utility is a redistributable tool that can assist in gathering
WMI troubleshooting data. This utility performs a basic check of the WMI
service and configuration. This utility currently enumerates and verifies
the WMI Build Version, WMI Settings, Operating System, Products, Services,
Processes, Namespaces, Providers, and Event Filters.
This program can be used to test the local WMI service or the WMI service on
a remote system. Credentials can be provided on the command line when
accessing remote systems. This utility is updated often.
- The first step in troubleshooting most WMI issues is to gather the logs
and WMICHK output using the following steps.
1. Set the WMI logging level to "verbose".
- Start, Run, Open "wmimgmt.msc"
- Right Click on "WMI Control (Local)" and select "properties"
- Select the "Logging" tab
- Change the "Logging Level" to "Verbose"
- Click "OK" and close MMC
2. Grab the output from WMICHK (see above).
- wmichk > wmichk.txt
3. When the problem occurs again, grab all of the WMI log files from
"%systemroot%\system32\WBEM\Logs".
4. [optional] Export the following registry key.
HKLM\SOFTWARE\Microsoft\WBEM
- You should not leave the WMI logging level at verbose (2). The logging
overhead can cause additional problems. Verbose logging is great to catch
data for a
specific repro of a problem. When you're done gathering the data you should
set the logging level back to errors only (1).
- Rebuilding the repository should be considered a LAST step. If you suspect
repository corruption on Windows 2000 try Q320373 first. If you must rebuild
the
repository you can use the following steps.
1. Stop WMI (net stop winmgmt)
2. MOVE the contents of "%systemroot%\system32 \WBEM\Repository" to a
new/different folder
3. Restart WMI (net start winmgmt)
- The build version of WMI can be found in the registry under the following
key.
HKLM\SOFTWARE\Microsoft\WBEM\Build
- The Win32_WMISetting class was added in build 1085 (v1.5). Starting with
this version the following script can be used to gather the WMI settings
data including the build version. This script will not work on build 698
(distributed with SMS for NT4 and 9x clients). This script can also be used
as quick test of the WMI service on Windows 2000 and above.
set WMI = GetObject("WinMgmts:")
set obj = WMI.Get("Win32_WMISetting=@")
WScript.Echo obj.GetObjectText_(0)
- WSH (Windows Scripting Host) for Windows NT 4 does not include WMI. To
install
WMI v1.5 on NT4 use WMINT4.EXE
(
http://www.microsoft.com/downloads/release.asp? ReleaseID=18491).
- Win2K SP3 contains several audit fixes in the OS (not WMI). The net result
was a substantial increase in audit activity which can affect
consumers/clients that use the WMI NT Event Log Provider. The resultant
issues are typically NOT bugs. They are usually just CPU/resource loading
problems caused by trying to audit all object accesses. These problems are
usually eliminated by not auditing successes.
PS. I sent wmichk to the email address listed below.
Thank You.
Diana.
jxxx said:
Hi
We are running w2k adv.server cluster(2nodes) in production system
with sp3 installed. Problem is that WInMgmt leaks constantly about
2000 handles per 24hours. Leak seems to occure in idle node of the
cluster. There is no memory leak.
System is running Oracle 8.1.7 paraller server(also active in idle
node), IBM MQSeries server, terminal services plus our control system
which is running only in active node. We have an another quite similar
production system except it does not have MQseries and it has sp2
installed. This system does not have problem with Winmgmt ?
So far we have not been able to pinpoint cause of handle leak. I could
not find any similar problems when tried to search with Google. So, i
would need some advice where to look for cause of the problem. How i
could debug winmgmt etc. ?
jm
.
