Microsoft Corporation

September 1998

Summary: This white paper provides an introduction to the Windows Management Instrumentation (WMI) Extensions to the Windows Driver Model (WDM). These extensions provide a kernel-level instrumentation technology for the Microsoft® Windows® platform. Close coupling of the WMI extensions to WDM 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. These extensions are integrated into both the Windows 98 and Windows 2000 kernel to provide driver data and events. The WMI extensions to WDM have an extensible design—original equipment manufacturers (OEMs) and independent hardware vendors (IHVs) can extend the instrumented data set to meet their needs.

Introduction

Effective management requires well-instrumented computer software and hardware components to work together so that subsystem components can be accurately and consistently 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.

Microsoft Windows Management Instrumentation (WMI), which is compatible with the Desktop Management Task Force's (DMTF) Web-Based Enterprise Management (WBEM) standards initiative, supports uniform system and applications management based on the DMTF Common Information Model (CIM). As a component of Microsoft Windows management services, WMI will help reduce the maintenance and cost of managing components in a Windows NT®-based enterprise network.

The WMI extensions to the Windows Driver Model (WDM) provide the basis for hardware instrumentation in Windows environments. The WMI extensions to WDM are kernel-level instrumentation technologies for the Windows platform. Close coupling of these extensions with services developed to conform to the WBEM initiative simplifies access to instrumentation data and provides consistent, open access to management data. The WMI extensions are integrated into both the Windows 98 and Windows 2000 kernel to provide driver data and events. The extensions are extensible, and an original equipment manufacturer (OEM) or independent hardware vendor (IHV) can extend the instrumented data set with tools provided in the Microsoft Platform Software Development Kit (SDK) and Device Driver Kit (DDK).

WMI Extensions to WDM: Functional Overview

What Do the WMI Extensions to WDM Do?

The WMI extensions to WDM publish information, configure device settings, and supply event notification from device drivers. The extensions are part of the Win32® Driver Model (WDM) architecture; however, they have broad utility and can be used with other types of drivers as well (such as SCSI and NDIS). The extensions distribute the following data:

• Published data—A standard set of WMI extension data has been built into the Windows 2000-supplied port/class drivers. On Windows 98, NDIS miniport drivers and WDM drivers receiving I/O request packets (IRPs) can use the WDM extensions also. NDIS miniports continue to use the existing paradigm of object identifiers, and the NDIS class driver translates between the WDM extension IRPs and the object identifier (paradigm).
• Custom data—Provided through OEM/IHV driver extensions.
• Secure data—Provided through Windows 2000 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 that uses the WMI CIM-compliant technology expresses interest in that expensive data, the WMI extensions will signal the driver to start collecting the data. The WMI extensions keep a reference count and signal the driver to stop collecting the data when the last WMI-enabled application interested in that data terminates. An important point to note is that the driver writer, not the WMI extensions, decides what data is expensive to collect. The mechanism for indicating that data is expensive to collect is extremely simple to implement.
• Event Notifications—Event notification is a key feature of the WMI extensions, allowing drivers to detect hardware events and/or errors. An event can then be passed to the WMI 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.

The WMI extensions to WDM also allow 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 the WMI extensions are extensibility and the event notification mechanism. The extensions allow an IHV to extend the instrumentation data set and add value to a hardware/software solution. In addition, WMI and the WMI extensions to WDM provide 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 Do the Extensions Work with WMI?

The WMI extensions to WDM provide WMI with yet another means for collecting and setting data and events. WBEM-compatible WMI is a unifying architecture that allows access to data from a variety of underlying technologies—including WMI extensions to WDM, the Desktop Management Interface (DMI), and the Simple Network Management Protocol (SNMP). WMI is based on the CIM schema, which is an industry standard specification driven by the DMTF. (Details on CIM and WBEM can be obtained from www.dmtf.org/.) Following the ideas of the WBEM initiative, WMI provides a three-tiered approach for collecting and providing management data. This approach consists of a standard mechanism for storing data (a CIM-compliant data repository), 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 WMI provider. A WMI provider supplies instrumentation data for parts of the CIM schema. Microsoft has written a set of WMI providers, one of which—the WDM provider—interfaces with the kernel-mode WMI component. The kernel mode WMI component provides services that allow WMI-enabled drivers to implement WMI; it also acts as an interface to the WDM provider.

The specifications for writing a WMI 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 WMI provider. For kernel components, the IHV/OEM should implement the WMI extensions to WDM.

Figure 1 provides an overview of the WMI/WMI extensions to WDM architecture.

Figure 1. WMI extensions to WDM – architectural overview

How Do the WMI Extensions to WDM Compare to DMI?

As part of Microsoft's WMI, the WMI extensions to WDM were 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, these extensions integrate extremely well into the three-tiered approach to instrumentation infrastructure. As the WMI extensions to WDM are focused on the task of instrumenting data, they use WMI 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 the WMI extensions to WDM, as discussed in the following paragraphs.

Existing instrumentation technologies, such as DMI and SNMP, provide 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-compliant services provide an abstraction layer. Data from many sources can be provided to the CIM schema (sources could include WMI, WDM, DMI, SNMP, and CMIP), and a management application can use CIM 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 the WBEM standards. The WBEM-compliant infrastructure will provide a facility that maps DMI information into the CIM schema. This capability is facilitated by CIM's ability to support multiple instrumentation data providers—sample providers include those for WDM 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.

Native WMI (that is, WMI without the WDM extensions) uses other paradigms (such as DMI) to surface instrumentation data that requires extra work to surface. Therefore, more instrumentation data is available to management applications with less effort from OEMs and IHVs. Because the WDM extensions are not used for surfacing this instrumentation data, Windows 95, Windows NT 4.0 and Windows 98 platforms also have this data available from the moment WMI is installed on these platforms

Division of Labor and Call to Action

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

Microsoft

Microsoft will ship core WMI extension to WDM support in the operating system kernel and in a driver for Windows 98 and for Windows 2000. 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 2000, 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 the WMI extensions as required.

Microsoft is also providing a driver that maps Advanced Configuration and Power Interface (ACPI) data on Windows 2000. In addition, Windows 2000 will include a driver that takes SMBIOS 2.1 tables and imports them into WMI.

SMBIOS support will also be provided for Windows 95, Windows 98, and Windows NT 4.0. This support is static; that is, the SMBIOS tables are scanned at boot time only.

Management Application Vendors and Other ISVs

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

Some ISVs may be interested in writing a WMI provider that can extend the instrumentation data set. The WMI 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 the WMI extensions to WDM as a technology that can add value to their hardware and differentiate it from that of a competitor. For example, NIC vendors can use the extensions 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 CIM with the appropriate instrumentation information.

Implementing WMI and the Extensions to WDM

What Must a Driver Writer Do to Support WMI?

Any driver that receives IRPs—IRP_MJ_SYSTEM_CONTROL in particular—can be a WMI-enabled driver. Microsoft will add WMI support to the class or drivers so that miniports can effectively benefit from the WMI extensions to WDM 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, support for the WMI extensions to WDM 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 2000 Beta Driver Development Kit (DDK) has all of the required files to build a WDM driver. Sample WDM drivers are also included in the DDK. The SCSI port driver in Windows 2000 Beta 2 has WMI support. WMI functionality will be increased in Windows 2000 Beta 3.

Where Are the WMI Extensions to WDM?

The core infrastructure for supporting WMI extensions for a WDM driver shipped with Windows 98. Windows 98 also included WMI support in the NDIS class driver. This means that NDIS miniport driver writers, such as NIC hardware vendors, can leverage the WMI extensions to WDM. An IHV or OEM writing a Windows 98 driver that receives IRPs can also leverage WMI.

Windows 2000 Beta 1 and Beta 2 shipped with core WMI support, as well as WMI support in the NDIS class driver and the SCSI port driver. The Windows 2000 Beta 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 the WMI extensions.

Windows 2000 Beta 2 includes additional WMI instrumented drivers.

Where is WMI?

WMI has shipped and is currently available. Newer versions are under development.

Versions of WMI exist for all Win32 platforms, including Windows 95, Windows 98, Windows NT 4.0, and Windows 2000. 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 2000 becomes a significant contributor to their sales effort before they adopt WMI. The WMI WDM provider (as mentioned in the DMI section earlier) is included with the Microsoft Platform SDK, and provides significant instrumentation data by itself in the Windows 95, Windows 98, 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 2000.

For More Information

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

For the latest information on Windows 2000 Server, check out our World Wide Web site at www.microsoft.com/ntserver/ or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).

-------------------------------------------------------------------------------------------------

© 1998 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.