Device Objects and Driver Stack

Understanding Device Objects and Driver Stack is of utmost importance for understanding the Windows Driver Architecture. In this Windows Driver tutorial we will try to build our initial understanding of the Device Objects, Driver Objects and Device Stack.

Let us revisit the Figure below given in our previous blog Windows Driver Architecture.

Figure 1: Driver Stack

We mentioned that not all the drivers communicate directly with the driver. For given I/O request, there are several drivers layered as stack that participate in the request.

Driver Stack

Elaborating on the statement above and the figure given, the windows driver model classifies drivers broadly into following three kinds:

1. Bus Driver - Bottom of the stack and managers the bus where the device is attached. Most bus drivers are provided by Microsoft such as PCI, SCSI, USB, etc. Other bus drivers can be provided by IHVs and OEMs.
2. Function Driver - Main driver of the device and drives an individual device. It is typically written by the device vendor.
3. Filter Driver - Optional driver that filters I/O requests for a device, a class of devices or a bus.

The following figure shows the relationship between the bus driver, the function driver and the filter drivers for a device.

Figure 2: Driver Stack

Let us look them in detail:

Bus Driver

A Bus driver drives an individual I/O bus device and provides per-slot functionality that is device independent.
Microsoft provides bus drivers for mist buses, such as PCI, SCSI, USB, etc. Other bus drivers can be provided by IHVs and OEMs. Bus drivers are required drivers => there is one bus driver for each type of bus on a machine.
The primary responsibility of a bus driver are to:

• Enumerate the device on its bus.
• Respond to Plug and Play and Power management IRPs.
• Multiplex access to the bus.
• Generically administer the devices on the bus.

Bus drivers are essentially function drivers that also enumerate children. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them.
For details please follow:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540704%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Function Driver

Main driver of a device. A function driver is typically written by the device vendor and is required. The PnP manager loads at most one function driver for a device.
A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy.
For details please follow:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff546516%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Filter Driver

Filter Driver filters I/O request for a device, a class of device or a bus. These are optional drivers that add value to or modify the behavior of a device.

Bus Filter Drivers:

Typically add value to a bus and are supplied by Microsoft or system OEM. A bus filter driver could for example, implement proprietary enhancements to standard bus hardware.

Lower-Level Filter Driver:

Typically modify the behavior of device hardware.
A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically such filters redefine hardware behavior to match expected specifications.
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:

An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks.
For details please visit:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff545890(v=vs.85).aspx

A good example to follow and understand the Driver stack is mentioned in MSDN:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff565644(v=vs.85).aspx
Now, having established understanding of the Driver Stack, lets discuss Device Objects and how they are related to Driver Stack.

Device Objects and the Driver Stack

During system startup, the PnP Manager starts with the lowest level bus and loads the bus driver. A bus driver identifies the devices on its bus and creates device objects for them. Then, with similar iterative method, it creates device object stack for the device. More of it when we discuss Device Tree but I think we get the idea.
So, each driver has an associated device object to represent the driver's participation in the processing of I/O requests for that device. Thus, like the driver stack, these device object are arranged in a stack called as device stack.
The point to remember is that each device stack represents a device participation and is associated with a single device. A set of drivers or driver stack can service multiple device stack.
Thus, like our drivers, we have three kinds of Device Objects:

1. Physical Device Object (PDO) - Represents a device on a bus to a bus driver.
2. Functional Device Object (FDO) - Represents a device to a function driver.
3. Filter Device Object (Filter DO) - Represents a device to a filter driver.

Example: In the Figure below, we have two device, each with its own device stack - That are serviced by a single set of drivers.

Figure 3: Device Object and Driver Stack

Let us discuss the components given in the figure 3 in detail:

Bus Driver and Physical device Object

The bottom of the stack is a Physical Device Object (PDO), which is associated with a bus driver.
A bus driver creates a PDO for each device that it enumerates on the bus and requests resources for those device. The PnP manager uses that information to assign resources to each device. Each device has its own PDO.
A PDO represents the device to the bus driver as well as to other kernel-mode system components such as power manager, the PnP manager, and the I/O manager.

Function Driver and Functional Device Object

The core of the device stack is the functional device object (FDO)which is associated with a function driver.
The function driver creates an FDO and attaches it to the device stack. It translates the Windows abstraction of the device into the actual commands that are required to transfer data to and from a real device.

Filter Drivers and Filter Device objects

Device stacks can have multiple filter device objects (filter DOs), which can be placed above or below the FDO.
Each filter DO is associated with a filter driver. Filter drivers are optional, but often present. The usual purpose of a filter driver is to modify some of the I/O requests as they pass through the device stack.
For example, the filter drivers can be used to encrypt or decrypt read and write requests. Filter Drivers can also be used for purposes that do not require modification of I/O requests, such as tracking requests, and reporting the information back to a monitoring application. Sample of the same we will soon see in our upcoming blog series.

After having understanding of the layout of the Driver stack and Device stack, we will discuss how this arrangement actually works in our next blog.