Windows Management Instrumentation

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Hardware White Paper

Abstract

This white paper provides an introduction to Windows Management Instrumentation (WMI), a kernel-level instrumentation technology for the Microsoft® Windows® platform. Close coupling of WMI with services developed to conform to the Web-Based Enterprise Management (WBEM) initiative will allow Microsoft to simplify instrumentation and provide consistent, open access to management data. WMI is integrated into both the Windows 98 and Windows NT® 5.0 kernel to provide driver data and events. WMI is an extensible design – original equipment manufacturers (OEMs) and independent hardware vendor (IHVs) can extend the instrumented data set to meet their needs.

Introduction

Effective management requires well-instrumented computer software and hardware components so that subsystem components can be monitored and controlled. Microsoft is committed to simplifying instrumentation of hardware and software for the Microsoft® Windows® environment. Microsoft is also committed to providing consistent access to this instrumentation for both Windows-based management systems and legacy management systems hosted in other environments.

Windows Management Instrumentation (WMI) provides the basis for hardware instrumentation in future Windows environments. WMI is a kernel-level instrumentation technology for the Windows platform. Close coupling of WMI with services developed to conform to the Web-Based Enterprise Management (WBEM) initiative will allow Microsoft to simplify instrumentation and provide consistent, open access to management data. (Both WMI and WBEM are key components in Microsoft's manageability and total cost of ownership containment efforts.) WMI is integrated into both the Windows 98 and Windows NT® 5.0 kernel to provide driver data and events. WMI is an extensible design, and an original equipment manufacturer (OEM) or independent hardware vendor (IHV) can extend the instrumented data set.

WMI Functional Overview

What Does WMI Do?

WMI publishes information, configures device settings, and supplies event notification from device drivers. WMI is part of the Win32® Driver Model (WDM) architecture; however, it has broad utility and can be used with other types of drivers as well (such as SCSI and NDIS). WMI distributes the following data:

Published data—A standard set of WMI data will be built into the Windows NT 5.0-supplied port/class drivers.
Custom data—Provided through OEM/IHV driver extensions.
Secure data—Provided through Windows NT security descriptors for a designated usage.
Expensive data (optional)—Some data collection activity can significantly affect the performance of the driver; this data should only be collected when the management application specifically requests it. By default, a driver will not collect the expensive data. When a management application using WBEM expresses interest in that expensive data, WMI signals the driver to start collecting the data. WMI also keeps a reference count and signals the driver to stop collecting the data when the last WBEM application interested in that data terminates. An important point to note is that the driver writer, not WMI, decides what data is expensive to collect. And the mechanism for indicating that data is expensive to collect is extremely simple.
Event Notifications—Event notification is a key feature of WMI, allowing drivers to detect hardware events and/or errors. An event can then be passed to WBEM for corrective action based on the specific event that occurred. For example, a disk driver has an abnormally high amount of disk write/read errors, and it sends an event notification to a disk management utility. As another example, a Network Interface Card (NIC) detects the loss of Ethernet signal, and sends notification to a consumer of management data that is watching for events that affect the network.

WMI also allows a management application to configure a device. A management application may need to reconfigure a device based upon some driver-raised event or because of the data collected by the management application.

Note that the two key features of WMI are its extensibility and its event notification mechanism. WMI allows an IHV to extend the instrumentation data set and add value to a hardware/software solution. In addition, WMI provides a means for the driver writer to provide adequate notification of driver events, thereby eliminating situations where the driver detects a potentially disastrous situation and can only write an entry to the event log.

How Does WMI Work with WBEM?

WMI provides WBEM with yet another means for collecting and setting data and events. WBEM is a unifying architecture that allows access to data from a variety of underlying technologies—including Win32, WMI, the Desktop Management Interface (DMI), and the Simple Network Management Protocol (SNMP). WBEM is based upon the Common Information Model (CIM) schema, which is an industry standard driven by the Desktop Management Task Force (DMTF). WBEM details can be obtained from https://www.wbem.freerange.com.

WBEM provides a three-tiered approach for collecting and providing management data. This approach consists of a standard mechanism for storing data (a CIM-compliant database), a standard protocol for obtaining and disseminating management data (COM/DCOM; other protocols are also possible and under investigation), and a Win32 dynamic-link library (DLL) known as a WBEM provider. A WBEM provider supplies instrumentation data for parts of the CIM schema. Microsoft has written a WBEM provider—the WMI provider—which interfaces with the kernel mode WMI component. The kernel mode WMI component provides services that allow WMI-enabled drivers to implement WMI, and also acts as an interface to the WMI provider.

The specifications for writing a WBEM provider are freely available, as are code examples. An IHV/OEM that manufactures hardware and software for end users (for example, still-image scanner manufacturers, printer manufacturers, and so forth) should consider writing a WBEM provider. For kernel components, the IHV/OEM should implement WMI.

Figure 1 provides an overview of the WBEM/WMI architecture.

Figure 1: . WMI and WBEM

How Does WMI Compare to DMI?

WMI was developed to provide a set of instrumentation capabilities that are tightly linked to the driver models found in the Windows family of operating systems. Additionally, because WMI uses the same schema as WBEM, it integrates extremely well into the three-tiered approach to instrumentation infrastructure. As WMI is focused on the task of instrumenting data, it uses WBEM both as the central management data repository and as the access point for management applications to this data. This fact makes it more appropriate to compare DMI to WBEM, rather than to WMI, as discussed in the following paragraphs.

Existing instrumentation technologies, such as DMI and SNMP, provide more of a two-tiered approach to instrumenting data and providing it to consumers of management data (these data consumers are typically management applications). The difficulty with this approach is that for a single consumer of management data to understand both DMI and SNMP data, the developer of the management application must do twice as much work—he or she must write an application that can understand two different systems of communicating and representing instrumented data. However, in the WBEM/CIM environment, the WBEM services provide an abstraction layer. Data from many sources can be provided to the CIM schema managed by WBEM (sources could include WMI, Win32, DMI, SNMP, and CMIP), and a management application can use WBEM to access all of this data.

Besides the lack of a common abstraction layer, DMI does not provide a set of programming interfaces that are tightly integrated with the Windows operating system and its driver models. DMI was not architected with Windows Plug and Play and Power Management in mind. However, Microsoft understands that smooth migration of existing instrumentation technologies and management applications is key to the success of WBEM. The WBEM infrastructure will provide a facility that maps DMI information into the CIM schema managed by WBEM. This capability is facilitated by WBEM's ability to support multiple instrumentation data providers—sample providers include those for WMI and Win32 data. Intel Corporation is developing the functionality to allow DMI data to be mapped into CIM, and conversely, to allow CIM data to be accessible to existing DMI- or WMI-based management applications.

Division of Labor and Call to Action

This section explains the division of labor for supporting WMI between Microsoft, independent software vendors (ISVs), IHVs, and OEMs.

Microsoft

Microsoft will ship core WMI support in the operating system kernel and in a WMI driver for Windows 98 and for Windows NT 5.0. These kernel and driver pieces will support WMI services for the benefit of other drivers. Microsoft will also instrument the bus, port, and class drivers, as well as other drivers shipping with Windows NT 5.0, and will instrument the NDIS class driver shipping with Windows 98. This instrumentation will allow these components to provide instrumentation data and will create a mapping mechanism for the class or port driver, if needed. The NDIS class driver uses a similar mapping mechanism to map I/O request packets (IRPs) to object identifiers (OIDs), and the SCSI port driver uses a mapping mechanism to map IRPs to stream request blocks (SRBs).

Microsoft's goal is to allow miniport driver writers to work with a familiar model—for example, NDIS miniport driver writers can continue to work with OIDs and SCSI miniport driver writers can continue to work with SRBs. The port/class driver maps these models to WMI as required.

Microsoft is also providing a WMI driver that maps Advanced Configuration and Power Interface (ACPI) data on Windows NT 5.0. In addition, Windows NT 5.0 will include a driver that exports SMBIOS 2.1 tables into WBEM in Windows NT 5.0.

Management Application Vendors and Other ISVs

Management application vendors need to adopt WBEM and the industry standard CIM schema that WBEM implements. These vendors should pay particular attention to the Win32 portion of the CIM schema—this is the part of the schema that WBEM data providers—including WMI—populate with instrumentation information.

Some ISVs may be interested in writing a WBEM provider that can extend the instrumentation data set. The WBEM architecture encourages the writing of new providers, and all required specifications and code samples are freely available.

IHVs and OEMs

IHVs and OEMs should see WMI as a technology that can add value to their hardware and differentiate it from that of a competitor. For example, NIC vendors can use WMI to send an event if a loosely plugged in cable falls free and the Ethernet signal is lost. The NIC vendor can accomplish this by merely adding code to the NDIS miniport driver—the vendor does not need to write any WMI code. Other examples include sending temperature alerts, or detecting when the number of bad blocks or sectors on a hard disk drive has crossed a critical limit and sending the appropriate notification. And an IHV/OEM can write a new class driver, for example, to report temperature, fan control data, and so on, and can populate WBEM with the appropriate instrumentation information.

Implementing WMI and WBEM

What Must a Driver Writer Do to Support WMI?

Any driver that receives IRPs—IRP_MJ_SYSTEM_CONTROL in particular—can be a WMI driver. Microsoft will add WMI support to the class or drivers so that miniports can effectively benefit from WMI with very little extra work on the part of the miniport driver writer. Thus, the following types of drivers can have WMI code:

A driver that receives IRPs
A minidriver whose class or port driver has been modified (either by Microsoft or an IHV, ISV, or OEM) to support WMI

Note that IRP_MJ_SYSTEM_CONTROL must be supported by all devices. If a device doesn't use WMI, it must forward the IRP. If it does use WMI, it should process the IRP.

In Windows 98, the core WMI functionality exists. However, WMI support has been integrated into the NDIS class driver only. If a driver receives IRPs, then an OEM/IHV device driver writer can integrate WMI code into his or her driver in Windows 98.

The Windows NT 5.0 Beta 1 Driver Development Kit (DDK) has all of the required files to build a WMI driver. Sample WMI drivers, such as the diskperf device driver, are also included in the DDK. The SCSI port driver in Windows NT 5.0 Beta 1 has WMI support. WMI functionality will be increased in Windows NT 5.0 Beta 2.

Where is WMI?

The core infrastructure for supporting WMI for a WDM driver will ship with Windows 98. Windows 98 will also include WMI support in the NDIS class driver. This means that NDIS miniport driver writers (such as NIC hardware vendors) can leverage WMI. An IHV or OEM writing a Windows 98 driver that receives IRPs can also leverage WMI.

Windows NT 5.0 Beta 1 shipped with core WMI support as well as WMI support in the NDIS class driver and the SCSI port driver. The Windows NT 5.0 Beta 1 DDK has the required header files to add WMI code to a driver. The DDK also includes WMI samples. For example, the diskperf driver (which shipped with the Windows NT 4.0 DDK) has been updated to report its data using WMI.

Later versions of Windows NT 5.0, including Windows NT 5.0 Beta 2, will include additional WMI instrumented drivers.

Where is WBEM?

WBEM is freely available and can be downloaded from https://wbem.freerange.com. Versions of WBEM exist for all Win32 platforms, including Windows 95, Windows 98, Windows NT 4.0, and Windows NT 5.0.

Microsoft has also implemented a program whereby an IHV, OEM, or ISV can freely distribute WBEM binaries with their offerings (without incurring a royalty). This means that a single management solution is possible for all Win32 platforms. It also means that vendors do not need to wait until Windows NT 5.0 becomes a significant contributor to their sales effort before they adopt WBEM and WMI. The WBEM Win32 provider (as mentioned in the DMI section earlier) provides significant instrumentation data by itself in the Windows 95 and Windows NT 4.0 environments. Later, OEMs and IHVs can add significantly to this data set by using WMI to provide custom instrumentation data for their customers who upgrade to Windows 98 and Windows NT 5.0.

WBEM is currently in an advanced Beta 2 stage and is expected to ship in the middle of the second quarter of calendar year 1998.

For More Information

You can address questions about WMI to wmiinfo@microsoft.com.

The Windows NT 5.0 Beta 1 DDK is now available. Additional documentation and code samples will be provided in a future Windows NT 5.0 Beta DDK.