Registry and Plug and Play Subsystem

At the end of Chapter 1, I provided a simple example allowing you to gain a general understanding of the process used by the system to install new devices and resolve hardware conflicts. However, that example was too simplistic, and what's more important, it presented the process of hardware installation from the user point of view. But what actually happens when the system installs new hardware? What components are required to accomplish this task? How should we configure hardware and resolve hardware conflicts? These certainly are topics of great interest for anyone who's going to start full-scale support for Windows XP. With the release of Windows 95, Microsoft introduced a new concept simplifying PC usage: Plug and Play (or PnP). What is Plug and Play? A standard, or a specification of a concept? Actually, Plug and Play is a combination of the general approach to designing PCs, and a set of specifications describing the hardware architecture. Strictly speaking, it is a combination of the system BIOS hardware devices, system resources, device drivers, and the operating system software.

Note 

In 64-bit computers, BIOS is known as Extensible Firmware Interface (EFI).

All Plug and Play components have the same purpose: to provide automatic functioning of the PC, peripheral devices, and their drivers, with minimum intervention from the user. Users working with systems that meet all Plug and Play requirements don't have to spend time wondering if a newly installed device will cause hardware conflicts with another device. The registry provides the basis for developing such a system.

The HKEY_LOCAL_MACHINE/HARDWARE registry key contains a description of the system hardware and the relationship between hardware devices and their drivers. Before we go any further, it should be noted that this key is volatile, and all information it contains is re-created every time the operating system boots.

The hardware recognizer (Ntdetect.com) collects information related to the system hardware, and Windows NT/2000/XP kernel stores the information under the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION registry key. As the drivers are loading, they pass their information to the system so that it can associate the hardware devices and appropriate drivers. Windows NT/2000/XP saves this information under the HKLM\HARDWARE\DEVICEMAP registry key. Finally, all the necessary information related to the resources for the hardware devices (including ports, DMA addresses, IRQs) is stored under HKLM\HARDWARE\RESOURCEMAP.

With the arrival of Windows 2000, two new Executive subsystems were introduced: Plug and Play Manager and Power Manager. Plug and Play Manager is integrated with the I/O Manager, and doesn't participate in the initialization process. However, the drivers are initialized in such a way that Plug and Play drivers recognize some hardware devices. Windows NT 4.0, on the other hand, recognizes hardware devices using only Ntdetect, because of limited Plug and Play support.

Though Windows XP is based on the Windows NT/2000 kernel, the Plug and Play support provided by this operating system was further enhanced, improved, and optimized. The general idea of this design was to combine the respective advantages of the two lines of Windows products—Windows NT/2000 and Windows Millennium Edition (Windows ME). This approach was a success, since it achieved greater stability of the OS and better device compatibility.

For the moment, Windows XP includes Plug and Play support for hundreds of devices not covered by Windows 2000, such as scanners, cameras, audio devices, storage devices, and media (CDs and DVDs). At the same time, it provides better support for Universal Serial Buses (USB), IEEE 1394, Peripheral Component Interconnects (PCI), and other buses. Improvements introduced to the Plug and Play subsystem resulted in better stability and performance. This is especially true for the device installation process, which was streamlined and automated, as was illustrated by the example presented in Chapter 1. Besides, power management support was also improved, which certainly will be beneficial to both desktop and mobile computer users.

Plug and Play Historical Overview

Plug and Play represents a technology that supports automatic configuration of the PC and all the devices installed in the system. It allows you to start using newly installed hardware (for example, a sound card or modem) immediately after installation and without having to configure the device manually. Plug and Play is implemented at the hardware level, the operating system level, and in the device drivers and BIOS.

Plug and Play is the result of co-operation between software and hardware vendors who created an industrial committee in order to unify their efforts. This committee was founded in May of 1993, and initially included three corporations: Microsoft, Intel, and Compaq. By the end of 1995, several vendors were already producing hundreds of hardware devices complying with this standard.

Microsoft® Windows® 95 was the first operating system that implemented Plug and Play support. However, since that time, PnP standards have undergone a significant evolution, mainly due to the unified efforts of the members of the OnNow industrial initiative. OnNow aims to identify a universal approach for controlling both the operating system and hardware device configuration. Its main achievement is the Advanced Configuration and Power Interface (ACPI) Version 1.0 specification, which defines the basic interface between the motherboard and the system BIOS. This interface expands Plug and Play capabilities, allowing the operating system to control power and provide other extended configuration capabilities.

Windows 2000 and Windows XP implement extended Plug and Play functionality. Windows 2000 was the first operating system from the Windows NT family that provided full-featured support for Plug and Play and power management. However, those of you who want all the advantages of Plug and Play and power management support need to ensure that both the system BIOS and the computer system as a whole meet ACPI specification requirements. More detailed information concerning this topic will be provided later in this chapter.

For the moment, Plug and Play technologies are defined for USB, IEEE 1394, PCI, ISA, SCSI, ATA, LPT, COM, and Card/CardBus. Each Plug and Play device must have the following capabilities:

• Be uniquely identified

• Provide a list of services it supports and resources it requests

• Identify the driver that supports this device

• Provide the software capabilities to configure this device

Plug and Play Support in Windows NT 4.0

One current opinion is that Windows NT 4.0 doesn't support Plug and Play. Actually, Windows NT 4.0 does support Plug and Play, but this support is very limited in comparison to Windows 9x/ME and Windows 2000/Windows XP. Except for PCI devices, the settings for all the other hardware must coincide with the settings specified in the registry. If this condition isn't satisfied, the device driver won't load, and the device won't function properly.

All PCI devices are configured automatically when Windows NT 4.0 starts booting. After the device has been configured, its settings normally won't change. Windows NT 4.0 changes device settings in the registry only if these settings aren't consistent with the number or type of PCI devices.

Windows NT 4.0 reads BIOS data and information obtained from physical devices only once—at the hardware detection stage at boot time. When the system is up and running, all device management operations are only performed by the device drivers and registry. After a successful boot, Windows NT 4.0 never reads BIOS data.

Plug and Play Implementation in Windows 2000 and Windows XP

Plug and Play systems require combined interaction between the PC BIOS, hardware components, device drivers, and operating system software. In contrast to all the previous versions of Windows NT, Windows 2000/XP provides improved reliability and decreased downtime. These improvements are due to an extended range of supported hardware and full-featured Plug and Play support. Implementation of all this new functionality is part of the Microsoft Zero Administration initiative, which is aimed at minimizing possible Windows downtime. For example, Plug and Play devices can often be plugged in or removed while Windows is running, and the system detects the action. Devices that can be removed while the system is running include, for example, all USB devices, some IEEE 1394 devices, etc.

Decreasing the frequency of required reboots is one of the most significant advantages, because it simplifies the procedure of installing both the operating system and hardware components. In most cases, new devices can be added dynamically; that is, without rebooting the system. The Hardware Compatibility List has also been significantly extended. Now HCL includes hundreds of new printers, modems, tape devices, floptical drives, and other devices. All this became possible thanks to full-featured Plug and Play support and Power Management features.

Removing a device from a computer without first notifying the operating system is known as a surprise removal. Typically, Windows XP can handle this situation correctly, because device drivers developed according to the Windows XP Logo Requirements specification must notify the operating system when the device is removed. For such devices, the removal of the device does not affect the system. However, surprise removal is not recommended for some devices, particularly some storage devices, modems, and network adapters. Surprise removal of such devices causes the operating system to display an Unsafe Removal of Device screen, which tells the user to use the Safe Removal application when unplugging the device the next time. The user can manually disable the message for devices that can withstand surprise removal. The Safe Removal application is used to notify the operating system that a device is going to be unplugged, and can be found in the notification area, if such a device is installed on the system.

Note 

However, some devices must be installed or removed only when the system is turned off. This is true if the device requires internal installation in the computer. Also, if data transfers are in progress when certain devices are removed, or if the operating system tries to access particular types of devices that have been removed, data loss, data corruption, or even a system failure might result. For example, surprise removal of a PC Card, a CardBus, or parallel or COM-port devices while the device driver is attempting to write to its ports can freeze the system or cause a STOP error, which requires that you reboot the system.

In contrast to Windows 95, Plug and Play implementation in Windows 2000 and Windows XP isn't based on Advanced Power Management (APM) BIOS or Plug and Play BIOS. These two BIOS implementations were developed for Windows 95. Windows 98 and Windows ME support both of these legacy Plug and Play implementations (this support is mainly provided for backward compatibility). Actual Plug and Play support both in Windows 2000 and Windows XP is based on the ACPI interface.

Some ACPI-compliant types of system BIOS may cause STOP errors in Windows 2000/XP. To minimize these situations, Microsoft developers have included a special functionality with a text-based Windows 2000/XP Setup phase. This functionality allows the disabling or activating of ACPI mode support based on the following lists:

• Good BIOS list. This list is used for activating ACPI mode for some types of BIOSes dated earlier than 01/01/1999. If the system BIOS ACPI tables match any entries in the Good BIOS List, ACPI mode will be enabled. Since the 01/01/1999 date is now past, Microsoft isn't adding any new entries to the Good BIOS List.

• Incompatible BIOS list. This list is used to disable ACPI mode for certain BIOSes dated 01/01/1999 or later. If the system BIOS ACPI tables match any entries in the Windows Non-compliant ACPI List, ACPI mode will be disabled. BIOSes are added to this list if they have been discovered to cause system stability problems by either Microsoft test teams or the BIOS developers. That is, if a system doesn't pass the ACPI Hardware Compatibility Test (HCT), fails to boot, or doesn't provide minimal functionality under Windows 2000, then Microsoft will place the machine's BIOS on the Windows Non-compliant ACPI list. The ACPI HCT is available on the Web at http://www.microsoft.com/hwdev/acpihct.htm.

If a system's BIOS isn't on either of these lists, the ACPI mode will be enabled if the BIOS presents itself as an ACPI BIOS that has a date later than 01/01/1999. The date that's used by the operating system is the standard PC-AT date, which is found at F000:FFF5.

Note 

If the ACPI BIOS is detected as non-compliant in the Windows 2000 or Windows XP pre-setup system check, then the BIOS must be updated to ensure complete Plug and Play and power management functionality. Complete information on this topic is available at http://www.Hardware-Update.com.

For x86-based systems, there is a significant difference in the way the system BIOS interacts with the Plug and Play devices. For some systems, the BIOS Setup program has the Enable Plug and Play operating system option, which influences this interaction. Strictly speaking, this option specifies whether the system BIOS or the operating system controls the hardware. If you have a non-compliant ACPI system or a non-ACPI system, it is recommended that you set this option to No/Disabled. Microsoft also recommends that you disable this option if you dual-boot Windows XP and Windows 9x/ME, especially if the system check for Plug and Play on a Windows 98/ME ACPI system passes, but the system check for Plug and Play on Windows XP fails. If you have a fully compliant ACPI system (which means that ACPI BIOS is present and ACPI HAL installed), the device resources are assigned by Windows XP rather than by BIOS settings. BIOS settings are ignored, including the Enable Plug and Play operating system option. Because of this, this BIOS setting can be left as it is. However, Microsoft states that the No/Disabled setting for this option is still preferred.

The main idea of Plug and Play implementation is the simplification of PC usage for end users. Plug and Play implementation in Windows 2000/XP also solves the following tasks:

• Extending the existing Windows NT I/O infrastructure in such a way as to support Plug and Play and power management while providing backward compatibility for existing Plug and Play hardware.

• Developing common driver interfaces that support Plug and Play and power management for multiple device classes under Windows 2000/XP and Windows 98/ME.

• Optimizing Plug and Play support for various types of computers, including portables, desktops, and servers equipped with ACPI-compliant motherboards. Additionally, support for Plug and Play drivers is provided by Microsoft Win32® Driver Model, WDM, which also supports power management and other new and extended functionalities that can be configured and managed by the operating system.

Plug and Play Support in Windows 2000 and Windows XP

To include Plug and Play support with Windows 2000, it was necessary to combine Plug and Play implementation with the basic Windows NT source code. The results of this integration are listed below.

• Bus drivers are now separated from the Hardware Abstraction Layer (HAL). Bus drivers manage the I/O bus, including slot functionality independent from specific devices. In the new architectural model, bus drivers are separated from the HAL in order to provide co-ordination with the changes and extensions introduced into the kernel-mode components, including Executive, device drivers, and the HAL. Usually, Microsoft supplies bus drivers.

• New functionality is available for installing and configuring hardware devices. The new architecture includes changes and extensions for existing user-mode components, including the spooler, class installers, Control Panel applets, and the Setup program. New user-mode and kernel-mode components have also been added. These new components are Plug and Play-aware.

• New Plug and Play APIs were developed for reading and writing registry information. The registry was modified in order to achieve this. Now it supports Plug and Play and allows further improvements and extensions of the registry structure while providing backward compatibility.

Windows 2000 supports legacy Windows NT drivers, but the drivers don't support power management or Plug and Play functionality. Software and hardware vendors need to provide complete Plug and Play support for the hardware devices and drivers they supply. New drivers should also be developed that integrate Plug and Play functionality with power management. If this were done, the same drivers could function in both Windows 2000/XP and Windows 98/ME.

You'll find a brief description of the Windows 2000/XP Plug and Play architecture later in the chapter. A complete description of all the modifications you need to introduce to provide full-featured Plug and Play for Windows 2000/XP is shown in the documentation supplied with Windows DDK.

ACPI Specification

The Plug and Play system requires combined interaction of the system BIOS, its hardware components, device drivers, and the operating system. The ACPI specification identifies all the necessary requirements to the motherboard and system BIOS for supporting Plug and Play in Windows 2000/XP. Both Windows 2000/XP and Windows 98/ME use this specification as a basis for Plug and Play architecture according to the requirements of the OnNow initiative.

The ACPI specification defines the new interface between the operating system and the hardware components that provide power management and Plug and Play support. Notice that all the methods defined in ACPI are independent both of the operating system and of the processor type. ACPI defines the interface on the registers level for basic Plug and Play and power management functions. It also defines a descriptive interface for additional hardware functionality. This allows the developers to implement a whole range of Plug and Play and power management functions for multiple hardware platforms while using the same driver. ACPI also provides a general mechanism for managing system events for Plug and Play and power management.

Besides ACPI, there are other industrial standards. For example, Universal Serial Bus, Version 1.0, PCI Local Bus Specification, Revision 2.1, and PCMCIA.

System Support for Plug and Play

Windows 2000/XP provides the following Plug and Play support:

• Automatic and dynamic detection of installed hardware. This includes initial installation of the operating system, detection of changes in Plug and Play hardware between reboots, and reaction at run-time hardware events, including installation and removal of devices and plugging/unplugging docking stations.

• Assigning and reassigning hardware resources. Plug and Play drivers don't set specific resources. All resources required by the device are identified when this device is enumerated by the operating system. Plug and Play Manager requests these resources when the system allocates resources to each device. Based on these requests, Plug and Play Manager allocates resources to each device, including I/O ports, IRQs, and DMA channels. When necessary, Plug and Play Manager may reconfigure the resource allocation. For example, this may be necessary when a new device is installed, and the device requests resources that are already in use by another device.

• Loading appropriate drivers. Plug and Play Manager determines which drivers are necessary to support a certain device, and then loads these drivers.

• Interface for interaction between drivers and Plug and Play subsystem. This interface includes input/output procedures, I/O Request Packets (IRP) and necessary entry points for the drivers, and registry information.

• Interaction with power management system. Dynamic handling of the events is the key feature of the Plug and Play implementation in Windows 2000/XP. Adding or removing a hardware device is an example of a dynamic event. Furthermore, the system can dynamically change to hibernation mode and vice versa. Both the Plug and Play system and power management system use WDM functions and implement similar methods of reacting to dynamic events.

• Registration of device notification events. Plug and Play provides user-mode code with the capability of registering events and getting notification on certain Plug and Play events. The RegisterDeviceNotification procedure allows the calling code to filter the class or device necessary to receive notifications. This filter may be specific, like the file system handle, or general, like the device class. Notification methods inherited from earlier Windows NT versions are also supported for backward compatibility.

Support Levels for Devices and Drivers

The Plug and Play support level that is provided by a device depends both on the hardware support for Plug and Play and on the Plug and Play support provided by the device driver. This concept is illustrated by the data presented in Table 5.1.

Table 5.1: Plug and Play Support Levels for Devices and Drivers

Device type	Plug and Play driver	Non-Plug and Play driver
Plug and Play device	Full-featured Plug and Play support	No Plug and Play support
Non-Plug and Play device	Partial support for Plug and Play	No Plug and Play support

As shown in this table, the appropriate driver is necessary for providing complete PnP support. A brief description of all possible configurations is shown below.

• Full-featured support—both the device and its driver support Plug and Play. To provide optimum Plug and Play support, the hardware component has to meet the OnNow initiative requirements, including ACPI specification. Plug and Play support implemented in Windows 2000/XP is oriented towards ACPI systems only.

• Plug and Play device/legacy driver—no Plug and Play support. If the device driver doesn't support Plug and Play, then the Plug and Play device will behave as a legacy device. Notice that this may limit Plug and Play functionality for the whole system.

• Legacy device/Plug and Play driver—this combination may provide partial Plug and Play support. If you have a legacy device that doesn't support Plug and Play at the hardware level, it may provide limited PnP support if the appropriate Plug and Play driver has been loaded. Although this system won't be able to automatically and dynamically detect the hardware and load the appropriate drivers, it will provide the capability of managing hardware resources. This system will also provide the interface for the driver to interact with the Plug and Play subsystem and register device notification events. If your hardware device has a Plug and Play driver, it will be displayed by the Device Manager. The tabs that allow you to configure device properties are available in the Device Manager window.

• Neither the device nor its driver support Plug and Play: no Plug and Play support. Legacy drivers will function as usual, but they won't support Plug and Play functions. All newly developed drivers should support Plug and Play.

As you can see, Plug and Play support depends on both the hardware device and the device driver. For example, if you have a manually installed legacy device, you still can gain functionality and provide partial Plug and Play support by installing a Plug and Play driver.

Note 

Windows XP supports Plug and Play for monitors if only the monitor, the display adapter, and the display driver are Plug and Play; otherwise, the monitor is detected as a default monitor.

Plug and Play Architecture in Windows 2000 and Windows XP

The Windows 2000/XP kernel provides Plug and Play support at boot-time. It provides interfaces to interact with various operating system components, such as the Hardware Abstraction Layer (HAL), the Executive subsystem, and device drivers. User-mode functions interact with kernel-mode functions, thus providing capabilities of dynamic configuration and interface with all other components supporting Plug and Play, such as Setup program and Control Panel applets. Schematic representation of PnP architecture in Windows 2000/XP is shown in Fig. 5.1.

Fig. 5.1: Plug and Play architecture in Windows 2000 and Windows XP

The Plug and Play modules shown in Fig. 5.1 will be discussed later in this chapter.

Kernel-Mode Plug and Play Manager

The Kernel-mode Plug and Play Manager supports functions for centralized management, and manages bus drivers during enumeration. It also supports device drivers, which include adding or starting a new device.

For example, Plug and Play Manager requests if the device can be unplugged or removed, and allows the driver of this device to synchronize pending I/O requests with the newly received one. The kernel-mode Plug and Play Manager interacts with the user-mode Plug and Play Manager when identifying devices available for these operations.

Power Manager and Policy Manager

Power Manager is the kernel-mode component that works together with Policy Manager to process API calls, coordinate events, and generate I/O Request Packets (IRP). For example, if devices send requests for unplugging, Power Manager collects these requests, identifies which of them should be serialized, and generates the appropriate IRPs.

Policy Manager monitors the system activity and collects integrated status information on the users, applications, and device drivers. Under certain conditions (or by direct request) Policy Manager generates IRPs for changing device driver status.

Input/Output Manager

Input/Output manager provides basic services for device drivers. Input/Output Manager is the kernel-mode component that translates user-mode read and write commands to the appropriate IRPs. Besides, I/O Manager manages all the other basic operating system IRPs. These interfaces function the same way as those in Windows NT 4.0.

 

Windows XP enhances the I/O subsystem by adding new APIs that will be available to drivers developed according to the Windows XP Logo requirements. Device drivers written specially for Windows XP will take advantage of the new Windows XP functionality, including System Restore and Volume Snapshot Service, which were mentioned in Chapter 2. At the same time, Windows XP provides full backward compatibility with drivers developed for Windows 2000. Notice that despite the fact that all existing Windows 2000 drivers will work with Windows XP, it is strongly recommended that you check if Windows XP drivers are available. To obtain an updated driver, contact the device vendor or visit the Windows Update site.

WDM Interface for Plug and Play

The Input/Output system provides leveled driver architecture. This section discusses types of WDM (Win32 Driver Model) drivers, driver levels, and device objects. If you're interested in this topic and intend to develop device drivers, you can find all the necessary information in the documentation supplied with the latest version of Windows DDK.

Driver Types

From the Plug and Play system point of view, there are the following types of drivers:

• Bus driver—serves the bus controller, adapter, bridge, or any other device that has child devices. Bus drivers are required drivers and are normally supplied by Microsoft. Each type of the bus present in the system has its own bus driver.

• Function driver—this is the main device driver, which provides the operational interface for its device. It's a required driver unless the device is used raw (an implementation in which I/O is done by the bus driver and any bus filter drivers). The function driver for a device is typically implemented as a driver/minidriver pair. In these driver pairs, a class driver (usually written by Microsoft) provides the functionality required by all devices of that type, and a minidriver (usually written by the device vendor) provides device-specific functionality. The Plug and Play Manager loads one function driver for each device.

• Filter driver—sorts I/O requests for a bus, a device, or a class of devices. Filter drivers are optional and any number of them can exist placed above or below a function driver and above a bus driver. Usually, system original equipment manufacturers (OEMs) or independent hardware vendors (IHVs) supply filter drivers.

In most cases, lower-level filter drivers modify the behavior of the device hardware. For example, a lower-level class filter driver for mouse devices can provide acceleration, performing a non-linear conversion of mouse movement data.

Upper-level filter drivers usually provide value-added features for a device. For example, an upper-level device filter driver for a keyboard can enforce additional security checks.

Driver Layers

For any given device, there are two or more driver layers: a bus driver for the underlying I/O bus (or the Plug and Play Manager for root-enumerated devices) and a function driver for the device. Optionally, one or more filter drivers can be provided for the bus or device.

Device Objects

A driver creates a device object for each device it controls; the device object represents the device to the driver. From the Plug and Play perspective, there are three kinds of device objects: physical device objects (PDOs), functional device objects (FDOs), and filter device objects. PDOs represent a device on the bus; every Plug and Play API that refers to a device refers to the PDO. FDOs represent the functionality of a device to a function driver. Filter device objects represent a filter driver as a hook to add value. These three kinds of device objects are all of the DEVICE_OBJECT type, but are used differently and can have different device extensions.

Additional Windows NT/2000/XP Interfaces

Windows 2000/XP Plug and Play drivers aren't limited to using only the WDM interfaces. Drivers can call other interfaces to support legacy Windows NT drivers, detection, or other Windows NT-specific capabilities which aren't provided under WDM. Notice that if a driver is intended for work in both Windows 2000 and Windows 98, only WDM interfaces can be used.

WDM Bus Drivers

Bus power management and Plug and Play are controlled by WDM bus drivers, which are standard WDM drivers that expose bus capabilities. Notice that in this context, any device from which other devices are enumerated is referred to as a bus. A bus driver responds to new Plug and Play and power management I/O request packets (IRPs), and can be extended using filter drivers.

The bus driver is mainly responsible for the following tasks:

• Enumerating the devices on its bus

• Reporting dynamic events on its bus to the operating system

• Responding to Plug and Play and power management IRPs

• Multiplexing access to the bus (for some buses)

• Generically administering the devices on its bus

During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. The method a bus driver uses to identify connected devices depends on the particular bus.

A bus driver performs certain operations on behalf of the devices on its bus, but usually doesn't handle reads and writes to the devices. (A device's function driver handles reads and writes to a device.) A bus driver acts as a function driver for its controller, adapter, bridge, or other device.

Microsoft provides bus drivers for most common buses, including PCI, Plug and Play ISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. A bus driver can be implemented as a driver/minidriver pair, the way a SCSI port/miniport pair drives a SCSI host adapter. In these driver pairs, one driver is linked to the second driver, and the second driver is a DLL.

The ACPI driver plays the role of both bus driver and function driver. ACPI allows the system to learn about devices that either don't have a standard way of enumerating themselves (that is, legacy devices) or are newly defined ACPI devices to be enumerated by ACPI (for example, the embedded controller device). ACPI also installs upper-level filter drivers for devices that have functionality beyond the standard for their bus. For example, if a PCI bus driver installs a graphics controller with power controls not supported by the PCI bus, the device can access its added functionality if the ACPI driver loads an upper-level filter driver for it.

WDM Device Drivers

WDM device drivers are usually the function driver/minidriver pair and filter drivers. In addition to providing the operational interface for its device, function drivers play an important role in a power-managed system, contributing information as the policy owner for the device about power management capabilities and carrying out actions related to transitions between sleeping and fully-on power states.

User-Mode Plug and Play Components

The user-mode Windows 2000 APIs for managing and configuring Plug and Play devices are 32-bit extended versions based on the Configuration Manager API for Windows 95. Windows 95 Configuration Manager is a virtual device driver (VxD) that exposes these routines as services to both ring 0 and ring 3 components.

In Windows 2000/XP, these procedures extend the user-mode Plug and Play Manager functionality. Actually, they're exclusively user-mode APIs. Windows NT/2000/XP Setup program performs driver installation. The Setup program uses 32-bit device installation APIs, which represent a superset of the Windows 95 installation procedures.

Windows 2000/XP provides APIs that can be used by applications for customized hardware event management and creating new hardware events.

Plug and Play Device Tree

Plug and Play Manager supports the device tree that you can view using Device Manager (Fig. 5.2). This device tree keeps track of the active devices in the system and information about those devices. The Plug and Play Manager updates the device tree as devices are added and removed, or as resources are reallocated. The device tree is hierarchical, with devices on a bus represented as children of the bus adapter or controller. The registry is the central repository for static hardware information. Plug and Play system components and drivers build, maintain, and access new and existing subtrees in the registry.

Fig. 5.2: The device tree displayed by the Device Manager is supported by the Plug and Play Manager

During enumeration, data for each device is stored under a new HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum key in the registry (this is the enum tree). Plug and Play makes decisions about which device drivers are loaded based on the results of enumeration. Thus, there's an important connection between the enum tree and the list of services under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services.

Notice that Device Manager allows you to view devices both by type and by connection. To view devices by connection, simply select the Devices by connection command from the View menu. The device tree displaying devices by connection is shown in Fig. 5.3.

Fig. 5.3: Viewing devices by connection

Each branch in the tree defines a device node with the following requirements for system configuration:

• Device unique identifier (Device ID, DID), which is typically identified by a friendly name

• Resources such IRQs and DMAs, including resource type

• Allocated resources

• Indicates whether the device node is a bus, if applicable (each bus device has additional device nodes under it in the tree)

Specific icons indicate the device type and indicate any device conflict on the computer. Problem codes and icons for troubleshooting devices are also displayed.

Device Manager does not display all devices by default. Legacy devices, devices that are no longer attached to the computer, and some other devices are hidden. To view such hidden devices, select the Show hidden devices command from the View menu.

Note 

You can set Device Manager to show a list of non-present devices. In Control Panel, double-click System, click the Advanced tab, and then in the Environment Variables dialog box (Fig. 5.4), create the variable DEVMGR_SHOW_NONPRESENT_DEVICES=1.

Fig. 5.4: The Environment Variables window

You can use Device Manager to enable or disable devices, troubleshoot devices, update drivers, use driver rollback, and change resources assigned to devices.

In order to scan for hardware changes, update the driver for the device, disable or uninstall the device, troubleshoot the device, or view its properties, right-click the appropriate device node in the device tree and then select the appropriate command from the popup menu.

Plug and Play Device Detection

Plug and Play implementation in the Windows XP operating system provides the following advantages:

• Detects and enumerates devices

• Allocates resources during detection

• Dynamically loads, initializes, and unloads drivers

• Notifies other drivers and applications when a new device is available

• Works with power management to insert and remove devices

• Supports a range of device types

After Windows XP detects a Plug and Play device, the device driver can be configured and loaded dynamically, requiring little or no user input. Some buses, such as PCI and USB, take full advantage of Plug and Play capability and are also automatically detected. After the device is detected, PnP Manager and Bus driver enumerate the device, load the required driver(s) and start the device. If the device is new (no information on this device is available in the registry), Windows XP will install and start driver(s) for this device.

As was already noted, Windows XP Setup inspects the hardware configuration of the computer and records information on the devices it had detected in the registry. Setup gets configuration information for system devices from the INF file associated with each device and, with Plug and Play devices, from the device itself.

On a PnP system, a device transitions through various PnP states as it is configured, started, possibly stopped to rebalance resources, and possibly removed. The transitions between various states of the PnP device are shown in Fig. 5.5.

Fig. 5.5: PnP device states

When a new device is installed, Windows XP uses the device ID to search INF files for an entry for that device. Windows XP uses this information to create an entry for the device under the Hkey_Local_Machine branch in the registry, and it copies the drivers needed. Then the registry entries are copied from the INF file to the driver's registry entry.

Windows XP uses driver-ranking schemes to determine which driver to load when multiple drivers are available for a device. Drivers are ranked based on whether they are signed with a digital signature, and how closely they match the device's hardware ID (HW ID). If there are multiple drivers for a device, the driver with the highest ranking is selected for installation. The list of driver-ranking schemes from the highest to the lowest rank is as follows:

• Signed driver with a perfect four-part HW ID match to the driver

• Signed driver with a two-part HW ID match to the driver

• Unsigned driver with a perfect four-part HW ID match to the driver

• Unsigned driver with a two-part HW ID match to the driver

When you need to install a new device, rely first on Windows XP to detect and configure it. How you do it depends on what type of device you have, as the following list explains:

• For Plug and Play-compliant devices, plug the device in.

• For PCI and ISA Plug and Play cards, turn the computer off and then install the device. When you restart the computer, Windows XP detects the device and starts the Plug and Play installation procedures automatically.

• For legacy devices, run the Add Hardware wizard and let Windows XP detect the device. This requires administrator privileges.

Devices are installed after the user logs on to the computer.

Whenever possible, choose new Plug and Play devices, even for a computer that does not have an ACPI BIOS, to gain some Plug and Play functionality.

An example illustrating all the processes that take place in the system when the user installs new devices, and all the components required for successful installation is provided in Fig. 5.6. The sequence of action is as follows:

1. The user plugs the device into the computer. Note that if the device and its bus support the so-called hot-plug notification, you can plug the device in when the system is up and running.

2. PnP Manager and bus driver enumerate the new device. First, the bus driver with the support from the bus receives notification from the new device, and then notifies the kernel-mode PnP Manager on the change in the hardware configuration (in our case, a new device has been added). The kernel-mode PnP Manager then queries the bus driver for a list of devices physically present on the bus and compares the new list to the previous copy. Thus, PnP Manager determines which device has been added, and requests the bus driver for information on the new device (such as hardware ID, vendor ID, compatible IDs, and device capabilities).

3. The kernel-mode PnP Manager notifies the user-mode PnP Manager that there is a device to be installed. The user-mode PnP Manager creates a new process using rundll32.exe and launches newdev.dll to install the device.

4. The New Device DLL calls device installation functions (Setup API) and PnP Configuration Manager functions (CfgMgr API) to carry out its installation tasks. The New Device DLL creates a list of possible drivers for the device, and if necessary displays the Found New Device wizard. Information on driver selection was provided earlier in this chapter.

5. The class installer and co-installers, if there are any, can participate in the device installation.

6. Setup transfers control to kernel mode to load drivers and start the device. Once Setup has selected the best driver for the device, copied the appropriate driver files, registered any device-specific co-installers, registered any device interfaces, and so forth, it transfers control to kernel mode to load the drivers and start the device. The appropriate CfgMgr function sends a request to the user-mode PnP Manager, which passes it to the kernel-mode PnP Manager.

7. The PnP Manager loads the appropriate function driver and any optional filter drivers for the device.

8. Installers can supply wizard pages to change device settings.

Fig. 5.6: Device Installation scheme

Driver Rollback

This new feature, introduced with Windows XP, provides a useful reliability enhancement Problems such as hardware conflicts, persistent STOP errors, or system instabilities occur after you install an incompatible driver. Needless to say, in such a situation it would be highly desirable to have the capability of replacing the driver that causes problems without reinstalling the operating system. Now, Windows XP provides this capability.

Driver RollBack is an indispensable troubleshooting tool when you need to restore a damaged system. It is also very useful when debugging beta-versions of drivers. For example, if after updating the driver version your system displays a STOP message during boot, you can try to boot the system in safe mode and perform rollback of the faulty driver.

To use Driver RollBack, proceed as follows:

1. Start the System applet in Control Panel, go to the Hardware tab and click the Device Manager button.

2. Right-click the device whose updated driver is causing the problem, and select the Properties command from the context menu.

3. Go to the Driver tab (Fig. 5.7). Click Roll Back Driver.

   
   Fig. 5.7: The Driver tab of the device properties window now allows you to perform driver rollback

   
   Fig. 5.8: The driver can't be rolled back, since there are no driver files backed up for the device

4. The Device Manager will prompt you to confirm driver rollback. Click Yes. If a previous version of the driver is unavailable, Driver Roll Back will display an error message and then prompt you to use other troubleshooting tools.