The C# Column

Viewing processes using WMI

Microsoft had invented Web-Based Enterprise Management (WBEM), to develop a standardised technology for accessing management information. Management information includes details about the state of system memory, inventories of currently installed client applications, and other information about client status. WMI can handle many tasks, ranging from simple workstation configuration to full-scale enterprise management across multiple platforms. WMI uses Common Information Model (CIM) designed by the Distributed Management Task Force (DMTF) to represent systems, applications, networks, and other managed components. CIM can model anything in the managed environment regardless of data source location.

In addition to data modeling, WMI allows query-based information retrieval and event notification.

Let’s first study the architecture of WMI. The following figure describes the three-layer model of WMI comprising providers, the CIM Object Manager (CIMOM), and consumers of WMI information (applications).

The first tier in the WMI architecture is the prov-ider. A provider is a mediator between the system to be managed (for example, operating system, service, application, device driver, and so on) and the CIM object manager. The job of a provider is to extract management information from the underlying data source using whatever interfaces that software presents for management.

The management information and interfaces are then mapped by the provider into the object classes that WMI presents to WMI consumers. Moving forward, new and updated managed systems will use providers as a direct way to expose management APIs without significant intermediate conversions.

Next is CIMOM, the CIM Object Manager has its own storage repository. It acts as a broker for object requests. CIMOM and its repository are represented on the system by the system service called WinMgmt. Providers plug into CIMOM via a published set of COM interfaces. CIMOM keeps track of what classes are available and what provider is responsible for supplying instances of those classes. When an application requests for management information to CIMOM, it evaluates the request, identifies which provider has the information, and upon getting it, returns the data to the consumer.

Finally, there are consumers of WMI data. These are the applications requesting the management information. These consumers, as previously noted, only need to know about the classes of the objects about which they wish to get information.

Thus an application or script can call one WMI API function and get a wealth of information about the computer, operating system, applications, devices and even information available via other management protocols like SNMP and DMI.

A WMI class exposes properties, methods, events and associations. An application can make use of them for obtaining the management information. Properties supply descriptive information about a particular object of a class. For example, the object of Win32_Process class has a property called Caption that contains the name of the process. The WMI classes provide methods, that an application can call using the object of that class. The WMI object can throw events that are the notifications a consumer can request to receive for occurrences or failures in the system.

We will now see a program that uses the Win32_Process WMI class for enumerating the processes currently running on system.

Create a WinForm application. Place a list box and a button on the form. Name the button as m_browse and list box as m_list. Add the Click event handler for the button and write code in it as shown below.

ManagementClass mc = new ManagementClass ( @”root\cimv2:Win32_Process” ) ;
ManagementObjectCollection mobjects = mc.GetInstances( ) ;
foreach ( ManagementObject mo in mobjects )
m_list.Items.Add ( mo [ “Caption” ].ToString( ) ) ;

Here, firstly we have created a reference to the ManagementClass object passing to it the WMI class name. ‘root\cimv2’ is the default namespace for System.Management API. Most of the system instrumentation classes reside here.

We have retrieved the managed objects by calling the GetInstances( ) method of the ManagementClass class. This method would return the instances of the Win32_Process class, which is the class that represents a Windows process. The instances are returned in a collection, each instance would represent one process.

We have then run a foreach loop to access the objects in the collection. We have obtained the name of the process by using the Caption property of the Win32_Process class. Note that we can access the property of this class because an object of ManagementObject class represents the instance of the Win32_Process class.

Declare the System.Management namespace at the beginning of the program and add the reference to the ‘System.Management.dll’ to the project. Now run the program and click the ‘Browse’ button.

All the processes would get listed as shown in the snap shot here.

Yashavant Kanetkar, one of the first Express Computer columnists, is an established software expert, speaker and author with several best-sellers to his credit, including titles like “Let Us C” and the “Fundas” series. Contact him at kanetkar@dcubesoft.com