The WMI Performance Counter Provider

Perhaps, the most significant performance implication of using the Performance Monitoring provider is the necessity to marshal fairly large amounts of data. The Performance Monitoring provider is a conventional, old-fashioned WMI provider that is always loaded out-of-process respective to the client application, hence the need for marshalling the performance data across the process boundaries.

High-Performance Providers
To alleviate the performance problem often associated with conventional providers, Microsoft introduced a so-called high-performance provider API— a set of interfaces designed to increase the efficiency of communication between a client WMI application and a data provider. The basic idea behind the high-performance provider API is simple. As opposed to conventional providers, high-performance providers, if located on the same machine as the client application, are loaded in-process to the client, thus eliminating the need for cross-process data marshalling. Even when a client and a provider are located on different computers, the high-performance API is still a superior communication vehicle because it allows for caching the data on the remote machine and transmits only the minimal required data back to the client.

Because performance data providers need to handle vast amounts of frequently changing statistical data, choosing them to be implemented as high-performance providers is a good idea. Thus, starting with Windows 2000, the WMI distribution includes a high-performance alternative to the Performance Monitoring provider: the Performance Counter provider, also referred to as the Raw Performance Counter provider.

The Performance Counter Provider and the ADAP Process
Besides addressing performance issues, the Performance Counter provider eliminates the need to manually define the WMI classes that represent various performance objects. More precisely, it is not the provider itself, but rather the WMI AutoDiscovery/AutoPurge (ADAP) process that allows you to automatically import the definitions for Windows performance objects into the CIM Repository. The sole purpose of ADAP is to monitor the state of performance objects on a given computer and ensure that the definitions for these objects remain synchronized with their respective WMI performance class definitions.

On Windows 2000 and XP platforms, the ADAP process is launched automatically as soon as the WinMgmt service starts; unfortunately, neither the ADAP functionality nor the Performance Counter provider are available on any other Windows platforms. Upon startup, ADAP examines all currently installed performance DLLs and generates a list of all currently available performance objects. This list is then compared to a list of WMI performance classes and necessary adjustments are made.

Under Windows 2000 and XP, you can add custom performance objects and counters by implementing a performance DLL and registering it using lodctr.exe utility. Obviously, installing a new performance library is likely to render the WMI performance class definitions outdated or incomplete. That is why lodctr.exe and its counterpart unlodctr.exe, which is used to de-register the performance libraries, both invoke the ADAP process, thus making sure that WMI's CIM Repository remains synchronized with the actual performance objects.

ADAP can also be invoked manually via the /resyncperf command-line switch of winmgmt.exe:

winmgmt.exe /resyncperf

On Windows 2000, ADAP is implemented as part of winmgmt.exe; however, under Windows XP, it is a separate executable called wmiadap.exe.

wmiadap.exe Command-Line Options
/f Instructs wmiadap.exe to parse all performance DLLs on a given system and synchronize the WMI performance class definitions

/c Causes wmiadap.exe to clear the status of all currently available performance libraries

/r Instructs wmiadap.exe to parse all the Windows Driver Model (WDM) drives on a given system and synchronize the WMI performance class definitions

/t Throttles the ADAP process as soon as the user operates a keyboard or mouse

It is, therefore, possible to invoke the ADAP process manually as follows:

wmiadap.exe /f

The ADAP process maintains an error log, which can be found in %SystemRoot%\System32\Wbem\Logs\Wmiadap.log. The log is used to record various events triggered during the execution of the ADAP process, such as indications of the process's startup and shutdown as well as certain error conditions. In addition to the log file, all errors related to loading and parsing the performance DLLs are recorded in the Windows event log and can be viewed with the Event Viewer (eventvwr.exe). ADAP error messages can be found in the application log—you can filter errors based on the value of the Source column, which should be set to WinMgmt for ADAP messages. The application log messages are worth looking at because, on occasion, they may explain why certain performance counters are not being correctly transferred to the CIM Repository.

Finally, WMI system class, __ADAPStatus, located in the root\DEFAULT namespace, offers a way to programmatically determine the status of the ADAP process. This class has the following definition:

class __ADAPStatus : __SystemClass {
uint32 Status;
datetime LastStartTime;
datetime LastStopTime;

Its LastStartTime and LastStopTime properties are self-explanatory and reflect the last time the ADAP process was started and shut down respectively. The Status property is a bit more interesting—it is an integer value that defines the current state of the ADAP process.

__ADAPStatus.Status Constants
0 - The ADAP process has never been run on the computer.
1 - The ADAP process is currently running.
2 - The ADAP process is currently processing a performance library.
3 - The ADAP process is currently updating the CIM Repository.
4 - The ADAP process has finished.

To programmatically determine the status of the ADAP process, you can write code similar to the following:

using System;
using System.Management;

class ADAPStatus {
public static void Main(string[] args) {
ManagementObject mo =
new ManagementObject(@"\\.\root\DEFAULT:__ADAPStatus=@");
Console.WriteLine("Status: {0}", mo["Status"]);
Console.WriteLine("Last started: {0}", mo["LastStartTime"]);
Console.WriteLine("Last stopped: {0}", mo["LastStopTime"]);
The only thing to notice here is that the __ADAPStatus object is singleton and, therefore, has to be accessed using the @ symbol.

When the ADAP process successfully finishes, the WMI CIM Repository will be updated with the definitions of WMI classes that represent the performance objects. All such WMI classes will be derived from either Win32_PerfRawData or Win32_PerfFormattedData—preinstalled abstract classes that are used as superclasses for raw and "cooked" performance objects. The majority of the performance classes will be imported into the root\CIMV2 namespace; however, those classes that represent the performance objects for WDM drivers will be loaded into the root\WMI namespace, instead.

The remainder of this section will concentrate on non-WDM performance objects that are backed by the Raw Performance Counter provider and derived from the Win32_PerfRawData class. The following section will cover the Cooked Counter provider, which supports the classes, derived from Win32_PerfFormattedData.

Source of Information :
Dot NET System Management Services - Apress


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner