Windows Internals

Windows NT utilizes an object-based architecture designed for portability, multi-processor scalability, and security. Unlike Unix-like systems that represent resources as file descriptor streams in a virtual filesystem, Windows encapsulates resources as structured system objects managed by the kernel.

The Executive and the Kernel

The core operating system space in Windows NT is split into two primary layers: the Microkernel and the Executive.

• The Kernel: Operates at the lowest level, handling thread scheduling, interrupt/exception dispatching, and multiprocessor synchronization. It is non-preemptible and executes in close proximity to the Hardware Abstraction Layer (HAL).
• The Executive: A collection of subsystems that manage memory, processes, security, and I/O.

Core Executive Components

1. Object Manager: Creates, tracks, and destroys kernel objects and manages the system-wide namespace.
2. Process Manager: Handles process creation, thread block allocation, and lifetime tracking.
3. Security Reference Monitor (SRM): Enforces access validation rules on objects using security descriptors.
4. I/O Manager: Coordinates device-independent I/O operations via I/O Request Packets (IRPs).

For example, when a process is created, the user-space subsystem call invokes the Executive’s process manager, which translates to a native system call:

// Example: Creating a new process using the Win32 API CreateProcessW
#include <windows.h>
#include <stdio.h>

int main() {
    STARTUPINFO si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    
    // CreateProcessW maps to NtCreateUserProcess in the NT Executive
    BOOL success = CreateProcessW(
        L"C:\\Windows\\System32\\notepad.exe",
        NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi
    );
    
    if (success) {
        printf("Process created. PID: %lu\n", pi.dwProcessId);
        
        // Always close thread and process handles to prevent resource leaks
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    } else {
        printf("Process creation failed: %lu\n", GetLastError());
    }
    return 0;
}

The Object Manager and Handles

A Handle is a process-specific index pointing to an entry in the process’s handle table, which contains pointers to the actual kernel-space objects. The Object Manager maintains a reference count for every object:

• Handle Count: The number of open handles pointing to the object.
• Pointer Count: The total references, including internal kernel-space pointer references.
• An object is only deleted from memory when both counters reach zero.

For example, a C program acquires a handle to an event object, increments the reference count, and closes it:

// Example: Creating, using, and destroying a handle to a kernel-object
#include <windows.h>
#include <stdio.h>

void manage_event_object() {
    // Create a named auto-reset event object
    HANDLE hEvent = CreateEventW(NULL, FALSE, FALSE, L"Local\\MyIPCEvent");
    
    if (hEvent == NULL) {
        printf("Failed to create event: %lu\n", GetLastError());
        return;
    }
    
    // Signal the event object
    SetEvent(hEvent);
    
    // Close the handle, decrementing the kernel object reference count
    CloseHandle(hEvent);
}

rectangle "User Application" as app
rectangle "Object Manager" as om
rectangle "Specific Object (e.g. File)" as obj

app -> om : "Open File 'data.txt'"
om -> om : "Check Permissions"
om -> obj : "Create Reference"
om --> app : "Return Handle (e.g. 0x4A2)"

The Registry: The Central Database

The Registry is a hierarchical database that stores configuration settings for the operating system, hardware devices, and user profiles. The database is loaded from binary files called Hives (e.g., SYSTEM, SOFTWARE, SAM).

Accessing the Registry is optimized by keeping critical sections cached in memory. The Executive provides a set of system calls to navigate keys (analogous to directories) and values (analogous to files).

For example, a C program queries the OS product name by opening a registry key:

// Example: Querying registry key values using the Win32 API
#include <windows.h>
#include <stdio.h>

void query_registry() {
    HKEY hKey;
    char productName[256];
    DWORD dataSize = sizeof(productName);
    DWORD dataType;
    
    // RegOpenKeyExA maps to NtOpenKey inside the executive
    LONG status = RegOpenKeyExA(
        HKEY_LOCAL_MACHINE,
        "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion",
        0, KEY_READ, &hKey
    );
    
    if (status == ERROR_SUCCESS) {
        // RegQueryValueExA maps to NtQueryValueKey
        status = RegQueryValueExA(
            hKey, "ProductName", NULL, &dataType,
            (LPBYTE)productName, &dataSize
        );
        
        if (status == ERROR_SUCCESS) {
            printf("Product Name: %s\n", productName);
        }
        RegCloseKey(hKey);
    }
}

Win32 and the Subsystem Model

Windows NT was designed around the concept of Environmental Subsystems. Applications do not call native kernel APIs directly; instead, they link against subsystem DLLs (like kernel32.dll, user32.dll, or gdi32.dll) that implement a specific API personality.

These subsystem DLLs translate user requests into native system calls located in ntdll.dll, which performs the CPU transition (using syscall on x64 or sysenter on x86) into the executive kernel.

For example, resolving a native undocumented delay execution call directly through ntdll.dll:

// Example: Invoking a native system call wrapper in ntdll.dll directly
#include <windows.h>
#include <stdio.h>

typedef LONG (NTAPI *pfnNtDelayExecution)(
    BOOLEAN Alertable,
    PLARGE_INTEGER DelayInterval
);

void native_sleep(LONGLONG milliseconds) {
    HMODULE hNtdll = GetModuleHandleA("ntdll.dll");
    if (!hNtdll) return;
    
    pfnNtDelayExecution NtDelayExecution = 
        (pfnNtDelayExecution)GetProcAddress(hNtdll, "NtDelayExecution");
        
    if (NtDelayExecution) {
        LARGE_INTEGER interval;
        // Native delays are specified in 100-nanosecond intervals (negative means relative)
        interval.QuadPart = -(milliseconds * 10000LL);
        
        printf("Invoking NtDelayExecution native call...\n");
        NtDelayExecution(FALSE, &interval);
    }
}

Windows Drivers: The WDM and WDF

Windows drivers are classified under different architectures, moving from raw hardware control to managed object wrappers.

• Windows Driver Model (WDM): The legacy architecture requiring driver authors to manually implement power management states, Plug and Play (PnP), and synchronization.
• Windows Driver Frameworks (WDF): The modern framework providing object-oriented interfaces.
  • KMDF (Kernel-Mode Driver Framework): Runs in Ring 0, handles synchronization queues automatically.
  • UMDF (User-Mode Driver Framework): Runs driver code in Ring 3 as a standard user process. If a UMDF driver crashes, the system restarts the process without causing a Blue Screen of Death (BSOD).

For example, a basic kernel driver entry point initialization routine:

// Example: Minimal Windows Driver Framework (WDF) entry point
#include <ntddk.h>
#include <wdf.h>

NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT  DriverObject,
    _In_ PUNICODE_STRING RegistryPath
) {
    WDF_DRIVER_CONFIG config;
    NTSTATUS status;
    
    KdPrint(("WDF Minimal Driver Initializing...\n"));
    
    WDF_DRIVER_CONFIG_INIT(&config, WDF_NO_EVENT_CALLBACK);
    
    status = WdfDriverCreate(
        DriverObject,
        RegistryPath,
        WDF_NO_OBJECT_ATTRIBUTES,
        &config,
        WDF_NO_HANDLE
    );
    
    return status;
}

Security: Tokens and ACLs

The Security Reference Monitor (SRM) enforces access rights on objects using two main data structures:

• Access Token: Created upon user authentication, storing SIDs (Security Identifiers) for the user and their group memberships, along with user privileges.
• Security Descriptor: Attached to every securable kernel object. It contains:
  • DACL (Discretionary Access Control List): Identifies which SIDs are allowed or denied specific actions (read, write, execute).
  • SACL (System Access Control List): Identifies which actions on the object should generate audit logs in the security event log.

For example, verifying if the current process’s token indicates administrator elevation:

// Example: Checking user elevation level by inspecting the process access token
#include <windows.h>
#include <stdio.h>

BOOL is_current_token_elevated() {
    HANDLE hToken = NULL;
    TOKEN_ELEVATION elevation;
    DWORD size = sizeof(elevation);
    BOOL isElevated = FALSE;
    
    // Open the current process access token
    if (OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)) {
        // Query token elevation status
        if (GetTokenInformation(hToken, TokenElevation, &elevation, sizeof(elevation), &size)) {
            isElevated = elevation.TokenIsElevated;
        }
        CloseHandle(hToken);
    }
    return isElevated;
}

/* In Windows user space, Win32 calls translate into native wrappers inside */
HMODULE hNtdll = GetModuleHandleA("ntdll.dll");

/* In Windows user space, Win32 calls translate into native wrappers inside */
HMODULE hNtdll = GetModuleHandleA(".dll");

References & Further Reading

• Russinovich, M. E., Ionescu, A., & Yosifovich, P. (2017). Windows Internals, Part 1: System architecture, processes, threads, memory management, and more (7th ed.). Microsoft Press.
• Russinovich, M. E., Solomon, D. A., & Ionescu, A. (2012). Windows Internals (6th ed.). Microsoft Press.
• Silberschatz, A., Galvin, P. B., & Gagne, G. (2018). Operating System Concepts (10th ed.). Wiley. (Chapter 20: The Windows 10 Operating System).
• Microsoft Corporation. (n.d.). Windows Driver Architecture. Microsoft Learn.