intermediate

Drivers & device stacks

Function, filter, bus, class, and miniport drivers in layered request handling.

Guided paths in this branch

Follow a short sequence step by step. Each path links to the first topic; use Read next on each page to continue.

Official Microsoft docs

Closest official references related to this topic on Microsoft Learn.

Why it matters

Most real device interactions involve layered drivers. Seeing the stack explains why debugging I/O often means following a request across several components.

Mental model

A device stack is a pipeline of specialists. Each driver adds, inspects, or refines part of the work.

Go one level deeper

Extra detail for readers who want more precision before opening a child topic.

  • Filter drivers can sit above or below class drivers (upper/lower filters).
  • WDM and KMDF are frameworks; the IRP model is the common contract.

How it works

  1. 1Bus drivers enumerate hardware and expose child devices.
  2. 2Function/class drivers implement the main device behavior.
  3. 3Filter drivers observe or modify requests before they continue.

Key terms

Filter driver
A driver that inspects or changes I/O passing through a stack.
Bus driver
A driver responsible for enumeration and management of devices on a bus.

A storage request through layered drivers

The request may travel from a file system to a volume driver, then a disk class driver, a port driver, and finally a miniport driver.

Common misconception

Not every driver talks to hardware directly; many only cooperate inside the stack.

You should read next

Ranked from your current topic, related links, branch depth, and any active guided path.

Related topics