Guided path: I/O & drivers
Step 2 of 5
I/O Manager
The kernel component that builds, routes, and completes I/O requests.
Official Microsoft docs
Closest official references related to this topic on Microsoft Learn.
Why it matters
The I/O Manager is the traffic coordinator of device access. Understanding it explains why the same API style can work across files, devices, and named pipes.
Mental model
Think of it as a dispatcher that wraps requests in a standard format so every driver layer can understand what to do next.
Go one level deeper
Extra detail for readers who want more precision before opening a child topic.
- Major function codes (IRP_MJ_*) select dispatch routines in each driver.
- File objects tie a handle in user mode to a device stack in kernel mode.
How it works
- 1The manager creates IRPs and fills key metadata about the request.
- 2It targets the relevant device object and hands the request to the driver stack.
- 3Completion paths propagate results back up to the caller.
Key terms
- Completion
- The phase where results and status codes flow back to the request origin.
- Dispatch routine
- The driver entry point for a given I/O request type.
One model for many device types
The same core I/O machinery can dispatch requests to file systems, storage drivers, network drivers, and more.
Common misconception
The I/O manager does not replace drivers. It standardizes and routes work between them.
You should read next
Ranked from your current topic, related links, branch depth, and any active guided path.
intermediate
Drivers & device stacks
Function, filter, bus, class, and miniport drivers in layered request handling.
Next step in your guided path
intermediate
File systems
NTFS and friends translating raw storage into directories, files, and metadata.
Related topic
expert
Plug and Play & power
How devices appear, initialize, and change power state without manual kernel bookkeeping.
Natural next depth in this branch