Hi, Tom.
Well, I have seen a lot of different WinMgmt / perfctrs / WMI ADAP errors in the Event Viewer Applications Logs on different machines. I haven't had an opportunity to do thorough research on the matter, but many of those errors that do show up in Windows 2000 appear to me to be due to incompatibilities between extensible performance counters which have been installed (by driver and / or software installation procedures). The incompatibilities aren't necessarily absolute. By that I mean that I've eliminated the error messages in some cases by increasing the timeout values for those counters in their respective keys in the registry. So it may be that the default timeout values for the performance counters for many devices may simply be too stringent.
An interesting commonality among most of the machines, especially portables, has been the appearance of Event ID 37 messages in the apps of the following wording:
WMI ADAP was unable to load the perfproc.dll performance library due to an unknown problem in the library: 0x0
My early research on Technet revealed only that Microsoft considered this to be related to Release Candidate 2 systems which had been upgraded to Windows 2000 gold. (The problem was supposed to be with the Performance Library Dredger thinking the library was invalid, even though the counter was functioning correctly. The problem was also supposed to have been solved in RC3.)
The manual fix on affected systems was to issue two commands from a command prompt:
winmgmt /clearadap
and
winmgmt /resyncperf -p (where "p" is the Process ID number for the WinMgmt process as listed in Task Manager)
However, the machines I was seeing this issue on were original clean installations of the commercial product, not upgrades from earlier releases of W2K. And issuing the above commands only provided temporary, if any, change in the behavior. Basically, you'd see some type of Event ID 37 error (though not necessarily the one mentioned above, some of them being related to the spooler or NIC adaptors or whatever, but always involving the performance counter / monitor system) occuring at the terminus of each boot. Often, issuing the "fix" commands would result in the next reported errors referring to performance counters not functioning due to timeouts. (That's why I tried increasing the timeout values in the registry.)
To the rescue comes a tool included in the Windows 2000 Resource Kits, exctrlst.exe (the Extensible Counter Listing tool). This tool provides a convenient means of listing the extensible counters on the system, and of disabling the ones that issue non-useful error messages. On my personal notebook I've only had to disable the perfproc and perfnet counters to eliminate all of these error messages. My system suffers no functional problems as a result. And I deliberately disabled the perfdisk counter to speed things up. (Notebook disk drives ain't exactly blessed with blazing speed, and killing of the collection of performance data on the drive gave me a noticeable performance boost.) Unfortunately, the tool is NOT freeware. (Some of the ResKit tools are downloadable for free.) Frankly, considering what appear to be inherent problems with the performance counter system, I think Microsoft might reconsider that policy.
It's cool that these monitors are provided to enable us to optimize and troubleshoot our systems, but I don't think MS got the kinks out yet. If they're going to enable the things by default, even on standalone W2K Pro installations, they should have them sorted out so that they don't pester the user with meaningless error messages. It appears that you have to really delve into the resource kit to make appropriate use of the performance monitoring capabilities of the system, so why turn on all of this stuff by default for every user? (I'm relatively new to Windows of any kind, being a retiree who doesn't have much use for an AIX system at home.) At present it doesn't seem to matter a whole lot what we do about the error messages. Ignoring them has no apparent adverse effect on the system, though the recurrent messages in the Event Viewer may give some users a Clint Eastwood twitch. Going into the registry and increasing the timeout values for troublesome counters seems to get rid of some messages. I presume you could disable them from the registry manually, but I'm wary of editing keys with which I'm not thoroughly familiar without some assurance of the precise nature my editing is to take. It's easy to figure that increasing a timeout will make the counter "relax" a little. Being certain of the proper value(s) to use (or delete) in the registry in order to disable a counter is something I'm not prepared to do on a work computer. When I have time, I'll use the Extensible Counter Listing tool to switch between enabled and disabled conditions for some counters to see what happens in the registry and make some notes on the matter. I'm beginning to see some registry fixes here and there online, so I expect that the "tweaks" sites will have the info up soon, and perhaps they already have posted such information.
The real point is that, if you're not suffering any actual performance or functional problems with the devices that are producing performance counter errors, then there really can't be anything wrong with silencing the little buggers -- as long as we don't bash our registries while we're at it.
Just in case you hadn't seen the feature, there's an icon on the properties dialog for each event reported that will copy the contents of that event message to the clipboard so that you can paste it into a text file for later reference or to a message thread for communicating with others about it. Might come in handy if you want to provide the information for future discussion.
Hope this is helpful.
Regards,
Jim
Dang, I can read over a message a hundred times in the editing window, but I don't see the errors until I post the danged message! Old eyes, old hands, cranky old brain!
Facebook
Twitter