The I/O system

The Executive named the I/O Manager as one of its core components, alongside the Object Manager, Memory Manager, and Process Manager. This level is that component in full — how Windows turns "read this file" or "write to this device" into coordinated work across potentially many separate drivers, none of which necessarily know about the others.

Requests, not direct hardware access

Applications never talk to hardware directly — not even indirectly through a single driver, most of the time. Instead, every I/O operation becomes an IRP (I/O Request Packet), a standardized kernel structure the I/O Manager builds to describe what's being asked for, then routes to a device stack: an ordered chain of driver objects, each of which gets a chance to inspect, modify, forward, or complete the request before it reaches whatever's actually at the bottom.

This chapter is the overview; The I/O Manager covers the routing component itself, Drivers & device stacks covers the different roles drivers play within a stack, and Plug and Play & power covers how devices come into existence and change power state in the first place.

Why layering, again, and not one driver per device

The same architectural principle running through this entire course shows up here too: rather than one monolithic driver handling a device end to end, Windows layers specialized drivers, each responsible for one aspect of the work. A storage request, for instance, might pass through a filesystem driver, a volume manager, a disk class driver, and a hardware-specific miniport driver — four separate components, each understanding only its own layer, cooperating through the same standardized IRP mechanism. This is exactly what lets Microsoft (or a third party) insert an antivirus filter driver, a disk encryption filter, or a deduplication filter into an existing storage stack without rewriting the filesystem or the hardware driver underneath — the new component just becomes one more layer the same request passes through.

A worked example: opening a file

Opening a file from an ordinary application looks, from the calling code's point of view, like a single function call. Underneath: the call crosses into the kernel (through Ntdll), the I/O Manager builds an IRP describing the open request, and that IRP travels down the relevant device stack — through the filesystem driver that interprets the requested path against on-disk structures, potentially through filter drivers doing security scanning or auditing, down to the volume and disk drivers that actually address physical storage. Completion status and, eventually, data travel back up the same layered path in reverse.

A common mistake

Assuming a driver is always the final authority handling a request — that whichever driver "answers" is doing the whole job — misreads how layered I/O actually works. Many drivers in a stack never touch hardware at all; they exist purely to observe, transform, or route requests before handing them to the next layer down. Debugging an I/O problem often means figuring out which layer in the stack actually caused an observed behavior, not assuming any single driver is uniquely responsible.

Where this connects

• Storage & file systems covers the specific device stack a file-open request travels through, in detail.
• The Cache Manager sits between the I/O system and the Memory Manager, specifically to avoid repeating expensive device-stack traversals for data that's already been read recently.