Windows NT Architecture: A Deep Dive for Security Professionals

1) Introduction and Scope

This document provides a highly technical study guide to the architecture of Windows NT-based operating systems. Our focus is on understanding the fundamental design principles, internal mechanics, and their implications for system security and analysis. We will dissect the layered model, explore kernel and user mode interactions, and examine key components such as the Executive, Kernel, and Hardware Abstraction Layer (HAL). This guide is intended for security professionals, system administrators, and advanced developers seeking a profound understanding of the operating system's inner workings.

The scope includes:

• Layered Architecture: User Mode vs. Kernel Mode separation and its security implications, focusing on processor privilege levels (rings).
• Hybrid Kernel Design: The interplay between the microkernel-like core Kernel and the monolithic-like Executive, and the rationale behind this design choice for performance and modularity.
• Key Kernel-Mode Components: Detailed examination of Executive subsystems (Object Manager, Memory Manager, I/O Manager, Security Reference Monitor, Process Manager, Configuration Manager, Cache Manager, LPC Facility), the core Kernel (scheduling, synchronization, interrupt handling, exception dispatching), and the HAL.
• User-Mode Components: Environment Subsystems (Win32, POSIX, OS/2), System Processes (e.g., csrss.exe, lsass.exe), and their interaction with kernel services via Native API (ntdll.dll).
• Inter-Process Communication (IPC): Mechanisms like LPC and RPC, their protocols, and security considerations.
• I/O Processing: The role and structure of I/O Request Packets (IRPs), I/O stack locations, and the I/O Manager's dispatching and completion mechanism.
• Security Mechanisms: Deep dive into Access Control Lists (ACLs), Security Identifiers (SIDs), Access Control Entries (ACEs), and the Local Security Authority (LSA) and its role in authentication and authorization.
• Memory Management: Virtual memory, paging, memory protection mechanisms, page tables, and the concept of session space.
• Driver Model: Kernel-mode driver layering, the Windows Driver Model (WDM), and the implications for driver security and IRQL management.

2) Deep Technical Foundations

Windows NT is built upon a robust, preemptive, reentrant multitasking design, engineered for both uniprocessor and Symmetric Multiprocessing (SMP) systems. Its core architectural tenet is the strict separation of User Mode and Kernel Mode. This separation is enforced by the processor's privilege levels, commonly referred to as rings or protection rings.

• Ring 0 (Kernel Mode): The most privileged level, possessing unrestricted access to all system memory, hardware, and critical operating system data structures. Code executing in Ring 0 is trusted and forms the core of the OS. Any compromise of Ring 0 code can lead to complete system compromise. Direct hardware manipulation, interrupt handling, and core OS services reside here.
• Ring 3 (User Mode): The less privileged level where applications and most system services execute. Processes in User Mode are confined to their own virtual address spaces and must explicitly request kernel services for privileged operations through system calls. This isolation prevents errant or malicious user-mode code from directly affecting the operating system's integrity.

This two-ring model simplifies portability to architectures that may not support intermediate privilege levels (e.g., Rings 1 and 2 on some architectures). The transition from User Mode to Kernel Mode is typically achieved via a software interrupt (trap) or a specific instruction (e.g., SYSCALL on x64).

I/O Processing: Windows NT employs a packet-driven I/O model. I/O operations are abstracted into I/O Request Packets (IRPs). These packets encapsulate all necessary information for an I/O operation, such as the target device object, the requested function (e.g., IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL), buffer addresses, byte counts, and status information. IRPs are asynchronously processed by device drivers, allowing for efficient handling of concurrent I/O requests and enabling complex I/O operations like scatter-gather DMA. The IRP is passed down a stack of drivers, with each driver adding its own IO_STACK_LOCATION to the IRP to process its part of the operation.

Multiprocessing: SMP systems are supported through kernel-level synchronization primitives (e.g., spinlocks, mutexes, semaphores) and sophisticated thread scheduling mechanisms. The kernel manages processor affinity, load balancing, inter-processor communication (IPC), and ensures data consistency across multiple cores. Interrupt handling is managed via Interrupt Request Levels (IRQLs) and the Advanced Programmable Interrupt Controller (APIC).

3) Internal Mechanics / Architecture Details

3.1) The Hybrid Kernel

Windows NT's kernel is characterized as a hybrid kernel. It blends aspects of microkernels with monolithic kernels. The core Kernel component resides in Ring 0 and provides fundamental services like thread scheduling, interrupt handling, and exception dispatching. However, a significant portion of the OS's functionality, historically found in user-mode servers in pure microkernels, is integrated into the Executive layer, also operating in Ring 0. This design choice aims to balance performance and modularity.

+-------------------------------------------------+
|                   User Mode                     |
|-------------------------------------------------|
| Applications, Services, Environment Subsystems  |
| (Win32, POSIX, OS/2)                            |
+-------------------------------------------------+
|               System Calls (NT API)             |
+-------------------------------------------------+
|             NTDLL.DLL (Runtime Library)         |
+-------------------------------------------------+
|                   Kernel Mode                   |
|-------------------------------------------------|
|                Executive Services               |
| (Object Mgr, Memory Mgr, I/O Mgr, SRM, etc.)    |
+-------------------------------------------------+
|                     Kernel                      |
| (Scheduling, Sync, Trap Handling, Dispatching)  |
+-------------------------------------------------+
|        Hardware Abstraction Layer (HAL)         |
+-------------------------------------------------+
|                  Device Drivers                 |
+-------------------------------------------------+
|                     Hardware                    |
+-------------------------------------------------+

Key Kernel-Mode Components:

• Kernel: The lowest level of the kernel-mode executive.

  • Scheduling: Manages thread execution, prioritization, context switching, and processor allocation. It implements various scheduling algorithms to optimize performance, including priority-based, preemptive scheduling.
  • Synchronization: Provides low-level primitives like spinlocks, mutexes, semaphores, and events for safe concurrent access to shared resources by multiple threads or processors. Spinlocks are crucial for protecting critical sections in multiprocessor environments, ensuring only one processor can hold the lock at a time.
  • Interrupt Handling: Processes hardware interrupts from devices, dispatching them to appropriate interrupt service routines (ISRs) based on their Interrupt Request Level (IRQL). Higher IRQLs mask lower ones, ensuring critical events are handled promptly.
  • Trap Handling & Exception Dispatching: Manages software-generated interrupts (traps) and hardware exceptions (e.g., division by zero, access violations, page faults). It directs control flow to appropriate handlers, debuggers, or initiates system error reporting. This is the mechanism for transitioning from user mode to kernel mode.
  • Initialization: Responsible for initializing critical boot-time device drivers and core kernel structures, setting up the initial execution environment.

• Executive: A collection of kernel-mode modules providing high-level OS services, built upon the core Kernel.

  • Object Manager (Ob): The central registry and manager for all kernel objects (processes, threads, files, devices, registry keys, etc.). It enforces naming conventions, security checks, and manages object lifetimes via reference counting.
    • Object Namespace: A hierarchical structure (similar to a file system) where named objects are registered. Example: \??\C:\Windows\System32\notepad.exe (a symbolic link to a device) or \Registry\Machine\Software.
    • Handles: Opaque values representing a reference to an object. They are obtained by opening or creating an object and are subject to access control. Each process maintains its own handle table mapping these handles to kernel object pointers.
    • Object Types: Define the structure, methods, and behavior of objects (e.g., Process, Thread, File, Key, Device, Driver). The Object Manager ensures type safety and manages object creation and deletion.
  • Memory Manager (Mm): Manages virtual memory, including memory protection, paging to/from disk (page file), physical memory allocation, and demand paging. It implements the PE (Portable Executable) parser for efficient process image mapping.
    • Virtual Address Space: Each process has its own 64-bit (on x64) virtual address space, providing isolation and enabling larger memory footprints than physical RAM. This space is divided into regions (e.g., code, data, heap, stack).
    • Page Tables: Hardware-managed data structures (e.g., Level 4 Page Tables on x64) that map virtual addresses to physical memory addresses. The Memory Manager manipulates these tables.
    • Session Space: Introduced for Terminal Services/Remote Desktop Services, this is a kernel-mode memory region associated with a user session. It allows multiple instances of user-mode subsystems (like Win32k.sys) to coexist without interfering with each other, each mapping their own user-mode DLLs into their session space. This is crucial for multi-user environments.
  • I/O Manager (Io): Orchestrates all I/O operations. It translates user-mode requests into IRPs, dispatches them to appropriate device drivers, manages the I/O completion process, and handles I/O error reporting.
    • IRP Structure (Conceptual):

      typedef struct _IRP {
          // ... Common IRP fields ...
          PIO_STACK_LOCATION Tail.Overlay.Current; // Pointer to current stack location
          // ... Other IRP fields ...
      } IRP, *PIRP;
      
      typedef struct _IO_STACK_LOCATION {
          UCHAR MajorFunction; // e.g., IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_CREATE, IRP_MJ_CLOSE
          UCHAR MinorFunction; // Specific sub-function within the major function
          // ... other fields ...
          PVOID Parameters;    // Pointer to parameters specific to MajorFunction union
          PDEVICE_OBJECT  DeviceObject; // Pointer to the device object for this stack location
          PDRIVER_OBJECT  DriverObject; // Pointer to the driver object for this stack location
      } IO_STACK_LOCATION, *PIO_STACK_LOCATION;

      An IRP is passed down the driver stack. Each driver in the stack gets its own IO_STACK_LOCATION within the IRP. The I/O Manager initializes the first IO_STACK_LOCATION and passes it to the top driver. Each driver processes its part and passes the IRP to the next lower driver using IoCallDriver, decrementing the CurrentStackLocation pointer in the IRP.
    • Device Objects (DEVICE_OBJECT): Kernel objects representing physical or logical devices. They contain information about the device's capabilities, driver, and associated I/O queue.
    • Driver Objects (DRIVER_OBJECT): Kernel objects representing loaded device drivers. They contain pointers to the driver's dispatch routines (e.g., an array indexed by MajorFunction codes).
  • Security Reference Monitor (SRM - srmsrv.sys): Enforces security policies. It validates access requests against Access Control Lists (ACLs) associated with securable objects.
    • Security Identifiers (SIDs): Unique, variable-length identifiers for users, groups, well-known security principals (e.g., S-1-5-32-544 for Administrators), and security contexts.
    • Access Control Lists (ACLs): Contain a list of Access Control Entries (ACEs).
    • Access Control Entries (ACEs): Define permissions (Allow, Deny, Audit) for specific SIDs on an object. ACEs are processed in order; DENY ACEs take precedence over ALLOW ACEs.
  • Process Manager (Ps): Manages process and thread creation, termination, context switching, and scheduling. It also manages job objects for grouping processes.
  • Configuration Manager (Cm): Manages the system registry (hive.sys), providing a hierarchical, persistent storage for configuration data.
  • Cache Manager (Cc): Caches file data in memory to improve I/O performance, coordinating with the Memory Manager and I/O Manager.
  • Local Procedure Call (LPC) Facility: Provides efficient inter-process communication (IPC) between user-mode subsystems and kernel-mode components, and between kernel-mode components themselves. It utilizes connection-oriented ports and message passing.

• Hardware Abstraction Layer (HAL - hal.dll): A crucial layer that abstracts hardware differences, presenting a consistent interface to the kernel and drivers. It handles platform-specific details for interrupt controllers (e.g., APIC vs. PIC), I/O ports, DMA controllers, and multiprocessor configurations.

  • Example: The HAL provides functions like KeQueryPerformanceCounter which abstract the underlying hardware timer mechanism, whether it's a TSC (Time-Stamp Counter) on x86 or a platform-specific timer on other architectures.

• Kernel-Mode Drivers (.sys files): Loadable modules that interface directly with hardware or provide system-level services. They operate in Ring 0 and are subject to the same privilege level as the kernel.

  • Driver Levels:
    • Highest Level: File system drivers (e.g., ntfs.sys, fastfat.sys), network drivers.
    • Intermediate Level: Function drivers (main device driver), filter drivers (e.g., for security monitoring, encryption, or protocol transformation).
    • Lowest Level: Bus drivers (e.g., PCI bus driver), legacy NT drivers.

3.2) User Mode Components

• Environment Subsystems: Provide APIs for applications to interact with the OS.

  • Win32 Subsystem (client/server runtime subsystem - csrss.exe and win32k.sys): The primary subsystem. csrss.exe is a user-mode process responsible for console windows, process/thread creation, and shutdown. win32k.sys is a kernel-mode driver handling window management, input events, and graphics rendering (GDI).
    • Virtual DOS Machines (VDMs): Emulate MS-DOS environments for running legacy 16-bit applications.
      • NTVDM.EXE: The user-mode process that hosts the VDM environment.
      • WOWEXEC.EXE: The process that hosts 16-bit Windows (Win16) applications within a VDM.
  • POSIX Subsystem: Supports POSIX.1 compliant applications. Largely superseded by Windows Subsystem for Linux (WSL).
  • OS/2 Subsystem: Supports 16-bit OS/2 applications. Discontinued after Windows 2000.

• Integral Subsystem (Security Subsystem):

  • Local Security Authority (LSA - lsass.exe): Manages security policies, user authentication (via security packages like Kerberos or NTLM), and the generation of security tokens. It interacts with the Security Reference Monitor (SRM) in kernel mode to enforce access controls.
  • Workstation Service (wkssvc): Implements the network redirector (client-side file/print sharing).
  • Server Service (srvsvc): Implements the server-side file/print sharing.

• Dynamic-Link Libraries (DLLs):

  • ntdll.dll: The NT Native API library, mapped into every user-mode process. It acts as the primary interface between user-mode applications and kernel-mode services, performing the necessary system calls (traps). It exposes functions like NtCreateFile, NtReadFile, NtWriteFile, etc.
  • Environment subsystem DLLs (e.g., kernel32.dll, user32.dll, gdi32.dll for Win32). These libraries wrap NT API calls into more familiar Win32 API functions, providing a higher-level abstraction. For example, CreateFileW in kernel32.dll eventually calls NtCreateFile in ntdll.dll.

3.3) Inter-Process Communication (IPC)

• Local Procedure Call (LPC) Facility: A high-performance IPC mechanism used extensively within Windows NT for communication between user-mode subsystems and kernel-mode components, and between Executive subsystems. It utilizes connection-oriented ports and message passing.

  • Port Structure (Conceptual):

    +-----------------+       +-----------------+
    | User Mode Proc A| ----> | LPC Port Server |
    | (Client)        |       | (Kernel Mode)   |
    +-----------------+       +-----------------+
                                      |
                                      v
    +-----------------+       +-----------------+
    | User Mode Proc B| ----> | LPC Port Server |
    | (Server)        |       | (Kernel Mode)   |
    +-----------------+       +-----------------+

    Client processes connect to server ports. Messages are queued and processed asynchronously. This is the backbone for many system service interactions, like csrss.exe communicating with win32k.sys.

• Remote Procedure Call (RPC): A higher-level IPC mechanism built on top of LPC (and other transport protocols like TCP/IP), allowing communication between processes on different machines. It defines interfaces and handles serialization/deserialization of data, making distributed computing more manageable.

4) Practical Technical Examples

4.1) Tracing an I/O Operation with IRPs

Let's trace a simplified file read operation from a user-mode application.

1. User Mode Application: Calls ReadFile() (e.g., provided by kernel32.dll).
2. kernel32.dll: Translates the Win32 API call into a call to NtReadFile() in ntdll.dll.
3. ntdll.dll: Performs a system call (e.g., SYSCALL instruction on x64) to enter Kernel Mode, passing the parameters for NtReadFile. The kernel's system call dispatcher identifies the requested NT API function.
4. Kernel Mode - I/O Manager (io.sys):
   • Receives the system call and identifies it as a request for file I/O.
   • Allocates an IRP using IoAllocateIrp. The IRP's Type field is set to IO_TYPE.
   • Populates the IRP with details: IRP_MJ_READ as the major function, the user-provided buffer address (after probing for validity using ProbeForRead), byte count, and a pointer to the file object obtained from the file handle.
   • Determines the driver stack for the file object. It adds an IO_STACK_LOCATION for the file system driver (e.g., NTFS). The I/O Manager sets the MajorFunction and other parameters in this stack location.
   • If the file system driver is not the lowest level driver, it adds another IO_STACK_LOCATION for the next driver in the stack (e.g., the disk class driver). The CurrentStackLocation pointer in the IRP is decremented for each added stack location.
   • Dispatches the IRP to the file system driver's IRP_MJ_READ dispatch routine by calling IoCallDriver.
5. File System Driver (e.g., ntfs.sys):
   • Receives the IRP. It retrieves its IO_STACK_LOCATION (pointed to by Irp->Tail.Overlay.Current) and processes the IRP_MJ_READ.
   • It consults its internal structures (e.g., file record, Master File Table - MFT) to determine the physical location of the requested data on disk.
   • If the data is not in the file system cache (CcRead), it generates a new IRP for the underlying storage driver (e.g., disk.sys). This new IRP will have its own IO_STACK_LOCATION for the disk driver.
   • It may copy data from a system buffer (allocated by the I/O Manager) to the original user-mode buffer, or vice-versa, after ensuring the user buffer is valid.
   • It marks the IRP as pending (IoMarkIrpPending) if the operation will complete asynchronously. This is crucial for non-blocking I/O.
   • It passes the IRP down to the next driver in the stack by calling IoCallDriver, passing the IRP and its own device object. The CurrentStackLocation pointer in the IRP is decremented.
6. Disk Driver (e.g., disk.sys):
   • Receives the IRP. It processes the IRP_MJ_READ request.
   • Translates logical block addresses (LBAs) to physical disk sectors.
   • Issues commands to the hardware controller via HAL and port I/O operations.
   • When the hardware signals completion (via an interrupt), the disk driver's ISR is invoked. The ISR typically signals an event or schedules a Deferred Procedure Call (DPC) that the disk driver's completion routine uses to complete the IRP. This is done to minimize the time spent at high IRQLs.
7. File System Driver (Completion):
   • The IRP is passed back up the driver stack. When the IRP reaches the file system driver's completion routine (set in the IO_STACK_LOCATION), it processes the completion.
   • If the data was read into a system buffer, it copies data from the system buffer to the original user-mode buffer.
   • Completes its own IRP by calling IoCompleteIrp. This signals the I/O Manager that the operation is done.
8. I/O Manager (Completion):
   • Receives the completed IRP.
   • If the IRP was marked pending, it uses an Asynchronous Procedure Call (APC) to notify the original user-mode thread that the operation is complete. The APC function pointer is typically stored in the IRP's UserBuffer or UserEvent field.
   • Frees the IRP using IoFreeIrp.
9. User Mode Application: Receives notification (e.g., via an event handle being signaled or by the ReadFile call returning) and processes the read data.

Example: Examining an IRP with WinDbg

Using a kernel debugger (like WinDbg) attached to a target system:

kd> !irp <address_of_irp>

This command would display the IRP's structure, including its Type, Size, MajorFunction, MinorFunction, and pointers to IO_STACK_LOCATIONs for each driver in the I/O stack. One could then examine each IO_STACK_LOCATION to see how parameters were set by each driver.

kd> !irp poi(g_MyIrpAddress)
IRP at ffffe001`2a028000 - 0000000000000000
    Irp.m_Flags      00000000
    Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0000000000000000
    Irp.m_CancelRoutine 0000000000000000
    Irp.m_CancelState 0
    Irp.m_CancelIrql  0
    Irp.m_CancelTimeout 0
    Irp.m_CancelThread 0000000000000000
    Irp.m_CancelContext 0000000000000000
    Irp.m_IoStatus.Status 0000000000000000
    Irp.m_IoStatus.Information 0
    Irp.m_UserBuffer 00007ff7`41110000
    Irp.m_AssociatedIrp.Irp.IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.IoStatus.Information 0
    Irp.m_Flags      0
    Irp.m_AssociatedIrp.Irp.m_Flags 0
    Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_CancelRoutine 0
    Irp.m_CancelState 0
    Irp.m_CancelIrql  0
    Irp.m_CancelTimeout 0
    Irp.m_CancelThread 0
    Irp.m_CancelContext 0
    Irp.m_IoStatus.Status 0
    Irp.m_IoStatus.Information 0
    Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelThread 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelContext 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelIrql 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelTimeout 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelState 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Status 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_IoStatus.Information 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_UserBuffer 0
    Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_AssociatedIrp.Irp.m_CancelRoutine 0
    Irp.m_Associated

---

## Source

- Wikipedia page: https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
- Wikipedia API endpoint: https://en.wikipedia.org/w/api.php
- AI enriched at: 2026-03-30T22:47:06.280Z