System architecture

Every other chapter on this site sits at a specific floor of one building. This chapter is the elevator shaft: the map that tells you which floor you're on, and why the floor below always has to exist before the one above it can work.

Windows is not one program. It's a stack of layers, each one built on stable contracts provided by the layer beneath it, and each one hiding detail the layer above doesn't need to see. Understanding why the stack is shaped this way — not just memorizing the names of the boxes — is what makes every later chapter click into place instead of feeling like trivia.

Two privilege levels, not many

The x86-64 architecture defines four privilege rings (0–3), but Windows only uses two of them: ring 0 (kernel mode) and ring 3 (user mode). ARM64 Windows does the same thing with EL1/EL0. Everything you'll read about in this course lives on one side of that line or the other, and the line itself is enforced by hardware, not by convention — a user-mode program that tries to execute a privileged instruction (disabling interrupts, loading a page table, touching a device register directly) faults immediately, regardless of what the program wants to do.

That single hardware boundary is the reason Windows can isolate processes from each other and from the OS itself. It's also the most expensive boundary in the system to cross: every system call is a mode transition, and every mode transition has a real, measurable cost (you'll see the exact mechanism in Ntdll & the user/kernel boundary).

The stack, floor by floor

Reading top to bottom — the order this course follows, and the order the real Windows architecture diagram draws them in:

1. Applications & the Win32 environment (user mode) — the programs you run, the DLLs they load, and the windowing/session infrastructure (CSRSS, Win32k) that lets them draw on screen. This is Level 0.
2. System support processes & services (user mode, privileged) — Winlogon, the Service Control Manager, svchost — the small set of processes that exist to start and supervise everything else, rather than to do end-user work themselves.
3. IPC — the mechanisms (named pipes, RPC/COM, ALPC) that let the processes above talk to each other and to the kernel, since no two of them share memory by default.
4. Security — the Security Reference Monitor, tokens, and ACLs that every request above has to pass through before it's allowed to touch anything.
5. The Executive (kernel mode) — Ntoskrnl.exe's core managers: the Object Manager, the Process/Thread Manager, the Memory Manager. This is where "Windows" as an operating system, rather than a UI, actually lives.
6. I/O, storage & the cache manager (kernel mode) — how a request for a file becomes a request to a device stack.
7. Networking — a full stack in its own right, from the socket API down to the network adapter.
8. The registry — the Configuration Manager, the database every layer above reads its settings from.
9. The kernel (Ke) — interrupts, DPCs, IRQL, and the scheduler underneath the Executive.
10. Virtualization — Hyper-V, which can virtualize the hardware beneath the kernel that's running on top of it.
11. Boot, HAL & hardware — the floor: firmware, secure boot, and the hardware abstraction layer that lets the same kernel binary run on wildly different machines.

Each level's chapters assume you already understand the ones above it, exactly the way the Executive assumes processes and threads exist before it explains how memory is mapped into them.

Why layers, not one big program

The alternative to layering is a monolith: one blob of code where drivers, the scheduler, the filesystem, and the network stack are all free to call into each other directly. Early operating systems worked that way, and it made them nearly impossible to reason about — a bug in a network driver could corrupt scheduler state, because nothing stopped it from trying.

Windows' layering is a set of one-way dependencies enforced by API boundaries, not just a design guideline. The I/O Manager doesn't know the internal layout of a specific filesystem driver; it only knows how to build an IRP (I/O Request Packet) and hand it to whatever driver is next in the device stack. The Memory Manager doesn't know what a "process" means to the Object Manager beyond an address space it's been asked to manage. This is what lets Microsoft rewrite the storage stack or add a new filesystem without touching the scheduler — and it's what lets you, as a learner, understand the Memory Manager in isolation before ever opening the I/O Manager chapter.

A worked example: opening Notepad

It's worth walking through what "the stack" means for something as mundane as double-clicking Notepad, because every layer above actually participates:

• Win32 environment: Explorer, itself a Win32 app, asks CreateProcess to start notepad.exe.
• Executive: the Process Manager creates a new process object and address space; the Memory Manager reserves and maps the regions the loader will need.
• I/O & storage: the I/O Manager opens notepad.exe and its dependent DLLs from disk through the file-system stack.
• Applications (loader): the loader maps the PE image, resolves imports, and runs each DLL's entry point — see Executable loading & runtime for the full sequence.
• Security: every one of those operations — creating the process, opening the file, mapping memory — passes through an access check against the calling user's token.
• Applications (GUI): Notepad creates its main window, which means talking to Win32k to allocate a window object on the user's desktop.

None of this is visible to the user, and that invisibility is the entire point: layering succeeded exactly when the thing on top stopped needing to know about the thing underneath.

A common mistake

Beginners often picture "the kernel" as a single undifferentiated blob that does everything privileged. In practice the kernel-mode side of Windows is itself layered — the HAL, the kernel proper (Ke), the Executive's managers, and device drivers are distinct components with their own APIs and their own rules about what they're allowed to do and when. Kernel mechanisms covers exactly where those internal boundaries are and why violating them (like calling a blocking API from the wrong context) is one of the most common causes of a Windows bugcheck.

Keep this map open, mentally, as you read the rest of the course — every chapter from here on is one specific room in this building.