Drivers & device stacks

The I/O Manager routes IRPs through a device stack without needing to understand what's inside it. This chapter is about what actually is inside it — the different roles drivers play, and why real hardware interactions almost always involve several of them cooperating.

A pipeline of specialists, not a monolith

A single physical device is rarely represented by a single driver. Instead, Windows composes a device stack out of drivers with distinct, narrow responsibilities:

• Bus drivers enumerate hardware attached to a bus (PCI, USB, and so on) and expose each discovered device as a child device object the rest of the system can address. A bus driver's job is discovery and enumeration, not implementing device-specific behavior.
• Function/class drivers implement the main behavior a device category needs — a disk class driver knows how to talk to storage devices in general terms; it doesn't need to know the specific hardware quirks of one manufacturer's controller.
• Filter drivers sit above or below a function driver specifically to observe or modify requests passing through, without owning the device's core behavior themselves — antivirus minifilters, encryption filters, and various monitoring tools are all implemented this way.
• Miniport drivers (for storage and networking especially) implement the genuinely hardware-specific bottom layer, working underneath a more generic port or class driver that handles everything common across an entire device category.

Why splitting responsibility this finely pays off

The practical payoff of this decomposition: a hardware vendor writing a new storage controller driver only has to implement the narrow, hardware-specific miniport layer — the generic disk semantics, the class driver behavior, the filesystem interaction above it, all of that is shared, tested, existing infrastructure the vendor doesn't have to reimplement or risk getting wrong. And because the layering is uniform (via the I/O Manager's IRP model, from the previous chapter), a security product can insert a filter driver into practically any device stack without needing device-specific integration work for every possible piece of hardware it might encounter.

A worked example: a storage request through the full stack

Writing to a file on a local disk plausibly travels through, in order: the filesystem driver (NTFS, interpreting the write against on-disk structures — see File systems), possibly one or more filter drivers (a backup product's change-tracking filter, an encryption filter), a volume manager (translating a volume-relative offset into a disk-relative one), a disk class driver (implementing generic disk semantics), a port driver, and finally a miniport driver that actually speaks the hardware protocol to the physical storage controller. Each layer only understands its own responsibility; none of them needs to understand the full chain to do its job correctly.

A common mistake

Assuming every driver in a device stack talks to hardware directly is a natural but incorrect intuition — most of the drivers involved in a typical request never touch a physical register or issue a hardware command at all. They exist to enumerate, filter, translate, or route. This matters practically for debugging: a misbehaving I/O operation is just as likely to be caused by a filter driver several layers away from the hardware as by the hardware-facing miniport itself, and tools that trace IRP flow through the whole stack (rather than assuming the bottom-most driver is automatically the culprit) are usually the right diagnostic approach.

Where this connects

• Plug and Play & power covers how the device objects these drivers cooperate over actually come into existence and get torn down.
• File systems is a specific, especially important function-driver layer within a storage device stack.