How Device Drivers Work

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Device Drivers Work

In this section

  • Device Driver Architecture

  • Device Driver Physical Structure

  • Device Driver Processes and Interactions

  • Related Information

A device driver is a component that Windows uses to interact with a hardware device, such as a modem or network adapter. Rather than access the device directly, Windows loads device drivers and calls functions in the drivers to carry out actions on the device. Each device driver exports a set of functions; Windows calls these functions. The driver functions contain the device-specific code needed to carry out actions on the device.

Driver Signing and Digital Signatures

Windows Server 2003 includes many features that help to ensure that the device drivers installed on a computer are reliable and up to date.

Drivers are signed by Microsoft after they pass a series of tests for functionality and reliability. For a driver to earn this certification, it must pass a series of tests administered by the Windows Hardware Quality Labs (WHQL). Due to stringent WHQL standards, using signed drivers typically results in a more stable system. Microsoft digitally signs drivers that pass the WHQL tests and Windows Server 2003 performs signature detection for signed drivers for various device types, which include the following:

  • Keyboards

  • Hard disk controllers

  • Modems

  • Mouse devices

  • Multimedia devices

  • Network adapters

  • Printers

  • SCSI adapters

  • Smart card readers

  • Video adapters

Note

  • During installation of some hardware devices, you may be prompted to choose Ignore on the driver signing dialog box. This indicates that the driver has not gone through digital signing.

A digital signature indicates that a driver file is an original, unaltered system file that Microsoft has approved for use with Windows Server 2003.

Windows Server 2003 checks for a digital signature during device driver installation and issues a message if the driver is not signed. Windows Server 2003 checks a database of known problem drivers when a computer is started or when a device driver is loaded; if a driver is located in the database of known problem drivers, that driver cannot be loaded, installed, or used on the computer.

Updated versions of signed drivers are available for download from the Windows Update Web site.

Device Driver Architecture

The Windows Server 2003 I/O system provides a layered architecture for serial device drivers, consisting of the drivers and their corresponding device objects.

Plug and Play Drivers

Plug and Play supports three types of drivers:

  • Function drivers, which drive individual devices

  • Filter drivers, which filter I/O requests for devices, classes of devices, and buses

  • Bus drivers, which service bus controllers, adapters, and bridges

The most common bus driver types are PCI, PnP ISA, SCSI, and USB. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them.

Device Objects

A driver creates a device object (DO) for each device it controls; the device object represents the device to the driver. Plug and Play recognizes three types of device objects:

  • Physical device objects (PDOs), which represent individual devices on a bus to a bus driver

  • Functional device objects (FDOs), which represent individual devices to a function driver

  • Filter device objects (filter DOs), which represent individual devices to a filter driver

The following figure shows a chain of attached device objects and drivers for a Plug and Play device.

Device Objects in a Device Stack

Device Objects in a Device Stack

The device stack includes a device object for each driver involved in handling the I/O to a particular device.

Components for Device Objects in a Device Stack

Component Description

Lower-level filter driver

Optional filter driver, loaded after the bus driver and any bus driver filters. There are two types of filters, device-specific and per-class. A lower-level device-specific filter monitors and/or modifies I/O requests to a particular device; typically, such filters redefine hardware behavior to match specifications. A lower-level per-class filter monitors and/or modifies I/O requests for a class of devices; for example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data.

Upper-level filter driver

Optional filter driver, loaded after the function driver, which attaches its device object above the FDO. There are two types of upper-level filters, device-specific and per-class. An upper-level device filter driver adds value for a particular device; for example, an upper-level device filter for a keyboard could enforce additional security checks. An upper-level per-class filter adds value for all devices of a particular class.

For Plug and Play devices, the device object at the bottom of the device stack is the PDO created by the underlying bus driver. The FDO is created by the function driver for the device. Filter DOs are attached above and below the FDO.

The PDO is created by the underlying bus driver when it enumerates the device. The FDO and filter DOs are created by FDOs or filter DOs for devices enumerated by the Plug and Play Manager

Device Driver Physical Structure

The following figure shows how device drivers operate in both kernel mode and user mode.

Device Driver Physical Structure

Device Driver Physical Structure

The following table describes the components of the preceding Device Driver Physical Structure diagram.

Components for Device Drivers

Component Description

Win32 API

32-bit application programming interface for Windows operating systems that initiates I/O operations through Ntdll

Ntdll

Function library that exposes stubs that invoke Windows system calls (like NtReadFile below) as exported functions

NtReadFile

I/O Manager system call that creates an I/O request packet and directs it to the appropriate driver

I/O Manager

Subsystem that controls and interacts with all devices on the system and provides routines that drivers can call to have the I/O Manager insert IRPs into the associated device queue

IRP

I/O Request Packet sent by I/O Manager to request services from a driver

IoCallDriver

Routine that sends an IRP to the driver associated with a specified device object

Once the request has been processed, the outcome is one of three results:

Queue for later process

The device driver defers the request processing to a later time; for example, when necessary resources are available, or the device is not busy.

Send to hardware port

The device driver programs the hardware to perform the operation specified in the request.

Send to another device driver

The device driver sends the request to another device driver; for example, if the request parameters change.

Device Driver Processes and Interactions

This section describes device driver processes and interactions for computers running Windows Server 2003.

How Windows Server 2003 Installs Device Drivers

Windows Server 2003 automatically configures a device so that it will work properly with other devices that are installed on the computer. As part of the configuration process, Windows assigns a unique set of system resources to each device so that it can function with little or no user input.

Windows Server 2003 device drivers included on the Setup CD are stored in a single cabinet file, Driver.cab. This file is used by Setup and other system components as a driver file source. Information files (.inf files) are searched when Windows Server 2003 starts or new hardware is detected. These text files provide the names and locations of driver-related files and the initial settings required for new devices to work. During setup, Driver.cab is copied from the installation CD to the WINNT\Driver Cache\platform directory of the local hard disk. The variable platform here is a placeholder for a specific value that reflects the architecture of the system: for example, i386.

Device drivers are installed with no user intervention if certain conditions are met:

  • Installing the driver does not require showing a user interface.

  • The driver package contains all files needed to complete the installation.

  • The driver package is available on the system in the Driver.cab file or was previously installed.

  • The driver package is digitally signed.

  • No errors occur during installation.

If any of the conditions is not met, the device installation restarts and the user might need to respond to dialog boxes or messages. Manual installation of a driver requires that the person installing the driver be a member of the Administrators group.

Windows Server 2003 determines which device driver to load for a device using the following criteria.

  • Driver ranking schemes

  • Driver search location policies

  • Windows Driver Protection

  • Windows Update

To facilitate device installation, devices that are set up and configured in the same way are grouped into a device setup class. For example, SCSI media changer devices are grouped into the MediumChanger device setup class.

How Device Drivers Are Processed

Microsoft uses a multistage process to test device drivers. Drivers are subjected to compatibility, reliability, and functionality tests administered by the Windows Hardware Quality Lab (WHQL). Drivers that successfully complete the process are digitally signed. Because of this testing, signed drivers are typically more robust and reliable. Once a driver is digitally signed, Windows Server 2003 recognizes it when it is loaded. Windows Server 2003 will notify a user if a driver is not signed or if a driver file has been changed since its inclusion on the Microsoft Hardware Compatibility List (HCL).

The digital signature is associated with an individual driver version and certifies that the driver provided with the device is identical to the driver that was tested.

Driver Signature Checking

Driver Signature Checking enables you to detect unsigned drivers before you install them. You can set verification levels for driver signature checking to ensure that Windows Server 2003 inspects files for digital signatures whenever you install or update drivers.

Signature Checking Levels are set to one of three categories, as described in the following table. These levels apply to processing both signed and unsigned drivers.

Signature Checking Levels

Level Description

Level 0 (Ignore)

Disables digital signature checking. Setup silently checks the signature on the driver, logs any unsigned driver files to a log file, and allows installation of the driver even if the driver is unsigned.

Level 1 (Warn)

Checks the signature on the driver before installation by checking whether the driver has passed WHQL testing. A message appears whenever a user tries to install a driver that fails a signature check. The driver can still be installed; however, this is not recommended.

Level 2 (Block)

Blocks installation of a driver that fails a signature check. The user is notified that Windows Server 2003 cannot install the unsigned driver.

Note

  • Warn is the default setting. You can change the signature-checking policy for a user without administrator permissions, but you must have administrator permissions to change the driver-signing policy for a computer.

Verifying File Signatures

The File Signature Verification Tool (Sigverif.exe) detects signed files and allows you to do the following:

  • View the certificate of a signed files to verify that the file has not been tampered with after being digitally signed

  • Search for signed files in a specific location

  • Search for unsigned files in a specific location

How Drivers are Ranked

Windows Server 2003 uses driver ranking schemes to determine which driver to load when multiple drivers are available for a device. Drivers are ranked by whether they are signed and how closely their Plug and Play ID matches the device’s Plug and Play ID. The Plug and Play ID of a driver or device consists of hardware IDs and compatible IDs. If the hardware ID of the driver exactly matches one of the hardware IDs of the device, there is a hardware match. If some other match occurs (for example, device compatible ID to driver compatible ID) there is a compatible match. Driver rank also depends on whether the device information file (.inf file) for the device includes information specifically for installations in a Windows Server 2003 environment. If multiple drivers for a device exist, the lowest ranking driver — the driver with the highest chance of optimum functionality — is installed.

The following table summarizes the driver ranking scheme for Windows Server 2003 from lowest (best match) to highest.

Windows Server 2003 Driver Ranking Scheme

Rank Description

1

Signed driver with a hardware match to a device

2

Signed driver with a compatible match to a device

3

Unsigned driver with a hardware match to the device, with Windows Server 2003 targeted in the INF section

4

Unsigned driver with a compatible match to the device, with Windows Server 2003 targeted in the INF section

5

Unsigned driver with a hardware match to the device, without Windows Server 2003 targeted in the INF section

6

Unsigned driver with a compatible match to the device, without Windows Server 2003 targeted in the INF section

How Driver Protection Affects Applications

Windows Driver Protection prevents the installation of drivers known to cause instabilities when installed under Windows Server 2003. Windows Server 2003 includes a list of such drivers, known as the Driver Protection List, which is checked at the following times.

  • During installation of Windows Server 2003

  • Each time the system is rebooted

  • Each time a device or application is installed

Driver Protection compares each driver that attempts to load under Windows Server 2003 against the Driver Protection List before loading that driver. The comparison and matching happen using the criteria in the following table.

File Attributes Matched by Driver Protection

Key Meaning

SYS_NAME

File name of the driver file.

BIN_PRODUCT_VERSION

Product version of the driver file.

UPTO_BIN_PRODUCT_VERSION

Superset of the BIN_PRODUCT_VERSION. Represents all product versions of the driver file that are less than or equal to the version specified.

LINK_DATE

Link date of the driver file. LINK_DATE appears to the operating system as a more accurate and consistent value than BIN_PRODUCT_VERSION, primarily due to the various ways versioning information can be stored. LINK_DATE is consistently set by the linker.

UPTO_LINK_DATE

Superset of LINK_DATE. Represents all link dates of the driver file that are less than or equal to the date specified.

If Driver Protection finds a match for a driver in the Driver Protection List, the following occurs:

  • The driver is not loaded under Windows Server 2003.

  • The operating system logs an event in the Event Log.

  • A notification is displayed to the user.

Windows Driver Protection is a low-level kernel feature that was designed to be the last resort for protecting a Windows Server 2003 system from errant drivers. Driver Protection will block known problem drivers from loading, but it does not block any associated applications that might depend on those drivers. Therefore, the behavior of applications that depend on blocked drivers will vary depending on the implementation of the application.

Some applications — such as antivirus programs — install drivers in order to provide their core functionality. Other applications — such as CD-burning applications — use drivers for portions of their feature sets. If a driver does not load, the former category of application might not work at all, while the latter might work for features that do not depend on the driver. Because Microsoft works closely with the driver and application vendors to implement fixes, in most cases the application vendor will have an updated version compatible with Windows Server 2003 available on the vendor’s Web site for download.

Most applications that ship drivers on the Driver Protection List will already be in the Windows Server 2003 application compatibility database. Users will get warnings whenever these applications are installed or run. However, because many drivers are sublicensed to multiple application vendors, Microsoft may not have information about every application that includes the driver. Therefore, for some applications, only the Driver Protection warning will appear.

The Driver Protection List database is updated through Microsoft Windows Update. Drivers are added to the Driver Protection List based upon feedback from users about problems that can be reproduced and confirmed by Microsoft. Whenever a system connects to the Windows Update Web site, the system’s driver protection list is updated. If a driver on the list was previously installed, the driver will be disabled and the user will be told how to obtain a new driver.

How Drivers are Located

Driver search location policies are Group Policies that specify where to search for new or updated device drivers. Group Policy can be configured to search a local machine and/or Windows Update, as well as turning off this policy.

Windows Update

The Windows Update Web site provides a central location for product enhancements, such as device drivers. Windows Server 2003 users can install or update drivers from the Windows Update Web site. When a user accesses the Windows Update Web site, Windows Update compares the drivers installed on a user’s system with the latest updates available. If newer drivers are found, Windows Update offers the list of applicable drivers to the user.

Drivers are included on Windows Update only if they are digitally signed, they have passed the testing requirements for the Windows Logo Program, and the vendor has given Microsoft redistribution rights for those drivers. This helps to ensure that the drivers offered from Windows Update are of high quality and reliability.

Devices each have a hardware ID that uniquely identifies the device, which is identified in the .inf file for the driver. Drivers that have a hardware or compatible match with the device, such as a device hardware ID to driver hardware ID, are candidates for download and installation. If a hardware or compatible match exists, Windows Update determines whether the driver on Windows Update is newer than the installed one. If the driver on Windows Update is newer, the driver is presented to the user for potential download. Also, if the hardware ID for the driver on Windows Update is a better match than the installed one, Windows Update offers that driver to the user. If the user chooses to install the offered driver, the file is downloaded, and the Windows Update ActiveX control points Device Manager to the .inf file for installation.

The following resources contain additional information that is relevant to this section.