Operating Systems - Windows NT Architecture & Case Study
Windows NT (New Technology) is the architectural foundation of every modern version of Windows (Windows 10, Windows 11, and Windows Server). Designed from scratch by a team led by David Cutler (the legendary architect of VMS), Windows NT was engineered to be portable, multiprocessor-capable, preemption-based, and highly secure.
Unlike Unix and Linux, which evolved from a 1970s terminal-centric, file-descriptor paradigm, Windows NT was architected around kernel objects, asynchronous I/O request packets, and a hybrid microkernel-inspired design.
Windows NT Architecture Overview
+-------------------------------------------------------------------------+
| USER MODE |
| |
| +--------------------+ +--------------------+ +--------------------+ |
| | User Applications | | Win32 Subsystem | | Subsystem DLLs | |
| | (.exe, services) | | (csrss.exe) | | (kernel32, user32) | |
| +--------------------+ +--------------------+ +--------------------+ |
| | |
| v |
| +--------------------------------------------------------------------+ |
| | System Service Dispatcher | |
| | (ntdll.dll / syscall) | |
| +--------------------------------------------------------------------+ |
+-----------------------------------|-------------------------------------+
| User / Kernel Boundary
+-----------------------------------|-------------------------------------+
| KERNEL MODE |
| |
| +--------------------------------------------------------------------+ |
| | Executive Subsystems (NTOSKRNL.EXE) | |
| | - Object Manager - Virtual Memory Manager (VMM) | |
| | - Process & Thread Manager - Security Reference Monitor (SRM) | |
| | - I/O Manager (IRP Stack) - Configuration Manager (Registry) | |
| +--------------------------------------------------------------------+ |
| | Kernel (Microkernel Core) | |
| | - Thread Scheduling & Context Switching | |
| | - Interrupt & Exception Dispatching (DPC / APC) | |
| | - Multiprocessor Synchronization (Spinlocks) | |
| +--------------------------------------------------------------------+ |
| | Graphics & Window Manager (win32k.sys) | |
| | - User & GDI rendering engine (Modern parts rewritten in Rust) | |
| +--------------------------------------------------------------------+ |
| | Hardware Abstraction Layer (HAL / hal.dll) | |
| | - Motherboard / APIC / timer abstraction | |
| +--------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+
The Hybrid Architecture: Executive vs Kernel
Windows NT divides its kernel-mode binary (ntoskrnl.exe) into two distinct conceptual layers:
- The Executive: The outer layer providing high-level OS primitives (memory management, security enforcement, process control, object lifecycles, and I/O routing).
- The Kernel: The inner microkernel-like core. It never calls the Executive. It handles low-level CPU operations: thread scheduling, interrupt dispatching, exception handling, and multiprocessor spinlocks.
Why Is Windows NT Called a "Hybrid" Kernel?
Pure microkernels (like Mach, QNX, or Minix) run device drivers, graphics engines, and filesystems in user mode, transferring data via inter-process message passing. While secure, message-passing introduces significant context-switching latency.
Windows NT originally placed the graphics and windowing system (win32k.sys) in user space. In Windows NT 4.0, Microsoft moved the graphics engine into kernel space to achieve the 60 Hz interactive display speeds required for workstation games and CAD software. Because it combines microkernel abstraction layers (HAL, Object Manager) with monolithic performance placement (in-kernel graphics and drivers), it is categorized as a Hybrid Kernel.
Object Manager: "Everything is an Object"
In Unix, the unifying abstraction is the byte-stream file ("everything is a file"). In Windows NT, the fundamental abstraction is the Kernel Object:
+---------------------------------------------------------------+
| OBJECT_HEADER |
| - Reference Count - Pointer Count |
| - Type Object Pointer - Security Descriptor (DACL, SACL) |
| - Object Name (Optional) - Handle Count |
+---------------------------------------------------------------+
| OBJECT_BODY |
| (Process, Thread, File, Event, Mutex, Section, Registry Key) |
+---------------------------------------------------------------+
Types of Objects
- Executive Objects: High-level resources visible across the system:
Process,Thread,File,Section(memory-mapped file),Event,Mutex,Semaphore, andKey(Registry). - Kernel Objects: Low-level synchronization primitives used internally by the scheduler:
KTHREAD,KPROCESS,KINTERRUPT.
Handle-Based Security & DACLs
User applications never touch raw kernel pointers. Instead:
- The app requests a resource (e.g.
CreateFileWorOpenProcess). - The Object Manager calls the Security Reference Monitor (SRM).
- The SRM compares the caller's Access Token (containing the user's Security Identifier - SID) against the object's Discretionary Access Control List (DACL).
- If permitted, the kernel inserts a pointer into the process's private Handle Table and returns an opaque integer: a
HANDLE. - Subsequent operations (e.g.
ReadFile,WaitForSingleObject) reference the handle, avoiding repeated security checks.
Asynchronous I/O & I/O Request Packets (IRP)
Traditional Unix was designed around synchronous blocking I/O (read(), write()). Windows NT was designed from day one around packet-driven asynchronous I/O.
Layered Device Drivers & IRPs
When an application initiates an I/O operation:
- The I/O Manager constructs an in-memory structure called an I/O Request Packet (IRP).
- The IRP is passed down a stack of independent, layered device drivers:
[ App: WriteFile() ]
|
v
[ I/O Manager: Allocates IRP ]
|
v
[ File System Filter Driver ] ---> (Antivirus inspection / BitLocker encryption)
|
v
[ File System Driver (NTFS) ] ---> (Translates file offsets to logical block numbers)
|
v
[ Volume / Partition Driver ] ---> (Manages partitions and dynamic disks)
|
v
[ Storage Bus Driver (NVMe) ] ---> (Dispatches DMA commands to hardware)
Each driver inspects its allocated I/O stack location inside the IRP, performs its hardware or software transformation, and either completes the packet or forwards it downward.
I/O Completion Ports (IOCP)
For high-throughput network servers, Windows NT provides I/O Completion Ports (IOCP).
- While Unix historically used readiness notification (
select,poll,epoll—which tell you when a socket is ready to read), Windows IOCP provides true asynchronous completion notification (the kernel transfers the data into your buffer first, then notifies your worker thread pool that the I/O is done). - IOCP manages an internal kernel LIFO thread queue, automatically preventing thread context thrashing and CPU over-subscription under massive concurrent loads.
Memory Architecture: Two-Phase Virtual Memory
The Windows Virtual Memory Manager (VMM) implements a clean distinction between reserving address space and allocating physical memory:
Virtual Address Space
+-------------------------------+-------------------------------+
| Reserved Region (MEM_RESERVE) | Committed Region (MEM_COMMIT) |
| - Reserves 64-bit addresses | - Backed by physical RAM or |
| - Zero physical RAM used | Pagefile storage |
+-------------------------------+-------------------------------+
MEM_RESERVE: Allocates virtual address space without consuming physical RAM or pagefile backing. A database engine can reserve 1 TB of virtual address space instantly.MEM_COMMIT: Binds committed virtual addresses to actual physical page frames or pagefile backing on demand.
The Page Frame Number (PFN) Database
Physical RAM frames are tracked in a global array called the PFN Database, which categorizes physical pages into distinct operational states:
- Active/Valid: Page is mapped into a process working set.
- Standby: Page was removed from a process working set but remains clean in RAM. If the process touches it again, it is re-attached instantly (a soft page fault, zero disk I/O).
- Modified: Page was modified and removed from a working set; awaiting the Modified Page Writer to flush it to disk.
- Free & Zeroed: Ready for immediate assignment to new allocations.
Modern Evolution: Hyper-V & WSL2
Modern Windows is no longer just an operating system running on bare metal; it frequently runs as a virtualized container on top of Microsoft's Type-1 hypervisor:
+-----------------------------------+-----------------------------------+
| Windows Host OS (NTOSKRNL) | WSL2 Guest (Custom Linux Kernel)|
| - Win32 Applications | - Standard GNU/Linux User Space |
| - Desktop Window Manager (DWM) | - Native ELF64 binaries |
+-----------------------------------+-----------------------------------+
\ /
v v
+-----------------------------------------------------------------------+
| Hyper-V Type-1 Hypervisor |
| (Hardware-Enforced Partitioning at Ring -1 / VMX Root) |
+-----------------------------------------------------------------------+
| Bare-Metal Hardware |
+-----------------------------------------------------------------------+
Windows Subsystem for Linux (WSL1 vs WSL2)
- WSL1 (System Call Emulation): The Windows kernel translated Linux system calls into NT system calls in real time. Complex calls (like
fork()or raw socket access) were slow or incompatible. - WSL2 (True Virtualization): Boots an official, Microsoft-compiled upstream Linux kernel inside a lightweight Hyper-V utility VM in under one second. It shares RAM dynamically with Windows using memory ballooning and bridges file access through the 9P network protocol.
Rust in the Windows Kernel
Because over 70% of historical Microsoft security bulletins stemmed from memory safety flaws in C and C++, Microsoft has actively begun rewriting critical kernel-mode components in Rust. Starting in Windows 11, the core font-parsing and graphics engine inside win32k.sys was rewritten in Rust (win32kbase_rs), eliminating entire classes of kernel privilege-escalation exploits.
