Guided path: I/O & drivers
Step 3 of 5
Drivers & device stacks
Function, filter, bus, class, and miniport drivers in layered request handling.
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
- 1Bus drivers enumerate hardware and expose child devices.
- 2Function/class drivers implement the main device behavior.
- 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.
expert
Plug and Play & power
How devices appear, initialize, and change power state without manual kernel bookkeeping.
Next step in your guided path
beginner
Storage & file systems
Disks, volumes, cache, and the file-system layers that make persistence usable.
Related topic
beginner
I/O system
How Windows turns API requests into IRPs, driver stack work, and device operations.
Part of a guided learning path