7a:T49a,In Windows, every process receives its own **virtual address space (VAS)**—a range of virtual addresses that the process can use. This address space is an abstraction provided by the Windows kernel and the processor's Memory Management Unit (MMU), creating the illusion that each process has exclusive access to a large, contiguous block of memory. **The Core Principle:** Virtual addresses used by a process bear no direct relationship to physical RAM addresses. When a program accesses memory at virtual address `0x00007FF6A1234000`, the MMU translates this to whatever physical address currently holds that data—or triggers a page fault if the data must be retrieved from disk. This translation happens transparently, millions of times per second, enabling: - **Process Isolation**: Process A cannot access Process B's memory, even if they use identical virtual addresses - **Memory Overcommitment**: Total virtual memory across all processes can exceed physical RAM - **Relocatable Code**: Programs can be loaded at different addresses without recompilation - **Security Features**: The kernel can mark regions as read-only, non-executable, or completely inaccessible7b:T415,**Why Map the Kernel Everywhere?** You might wonder: why is kernel memory mapped into every process's address space? The answer involves performance: 1. **System Call Efficiency**: When a process makes a system call (transitioning from user to kernel mode), changing the entire page table mapping would be expensive. By keeping kernel mappings present in every process, the transition only requires changing a privilege level, not remapping memory. 2. **Interrupt Handling**: Hardware interrupts can occur at any time. The kernel must be immediately accessible to handle them without address space switching. 3. **Shared Data Structures**: Some data structures (like the `KUSER_SHARED_DATA` page) are legitimately shared between user and kernel mode. **Protection Through Privilege, Not Absence:** The kernel pages are *mapped* in user-mode address spaces but *protected*—the page table entries mark them as supervisor-only. User-mode code attempting to access kernel addresses triggers an access violation, enforced by the CPU hardware.7c:T1289,64-bit Windows Virtual Address Space Layout ═══════════════════════════════════════════════════════════════════ High Memory (Kernel Space - ring 0 only) 0xFFFFFFFF'FFFFFFFF ┌─────────────────────────────────────────────┐ │ HAL and System Reserved │ ├─────────────────────────────────────────────┤ │ Page Tables (PML4) │ ├─────────────────────────────────────────────┤ │ Kernel Non-Paged Pool │ ├─────────────────────────────────────────────┤ │ Kernel Paged Pool │ ├─────────────────────────────────────────────┤ │ System Cache Views │ ├─────────────────────────────────────────────┤ │ PFN Database │ ├─────────────────────────────────────────────┤ │ Kernel Code (ntoskrnl.exe, drivers) │ ├─────────────────────────────────────────────┤ 0xFFFF8000'00000000 │ Kernel Space Start (128 TB) │ ═══════════════════════════════════════════════════════════════════ │ │ │ NON-CANONICAL HOLE │ │ (Invalid addresses - cannot be used) │ │ │ ═══════════════════════════════════════════════════════════════════ 0x00007FFF'FFFFFFFF │ User Space End (128 TB) │ ├─────────────────────────────────────────────┤ │ Stack(s) │ ├─────────────────────────────────────────────┤ │ Memory-Mapped Files │ │ (DLLs, etc.) │ ├─────────────────────────────────────────────┤ │ │ │ Heap(s) - Growing Upward │ │ │ ├─────────────────────────────────────────────┤ │ Executable Image (.exe) │ ├─────────────────────────────────────────────┤ 0x00000000'00010000 │ First valid user address │ ├─────────────────────────────────────────────┤ 0x00000000'00000000 │ NULL pointer region (reserved) │ └─────────────────────────────────────────────┘ Low Memory (User Space - ring 3 accessible)7d:Te56,32-bit Windows Virtual Address Space Layout (Default 2GB/2GB) ═══════════════════════════════════════════════════════════════════ High Memory (Kernel Space - ring 0 only) 0xFFFFFFFF ┌─────────────────────────────────────────────┐ │ HAL and Boot Structures │ ├─────────────────────────────────────────────┤ │ Page Tables (PDE/PTE) │ ├─────────────────────────────────────────────┤ │ Kernel Non-Paged Pool │ ├─────────────────────────────────────────────┤ │ Kernel Paged Pool │ ├─────────────────────────────────────────────┤ │ System Cache │ ├─────────────────────────────────────────────┤ │ Kernel Code (ntoskrnl.exe, drivers) │ 0x80000000 │ Kernel Space Start (2 GB) │ ═══════════════════════════════════════════════════════════════════ 0x7FFFFFFF │ User Space End (2 GB) │ ├─────────────────────────────────────────────┤ │ Thread Stacks │ ├─────────────────────────────────────────────┤ │ Memory-Mapped Files │ │ (DLLs loaded here) │ ├─────────────────────────────────────────────┤ │ │ │ Heap(s) - Multiple allowed │ │ │ ├─────────────────────────────────────────────┤ │ Executable Image (.exe) │ │ (typically at 0x00400000) │ ├─────────────────────────────────────────────┤ 0x00010000 │ First valid user address │ ├─────────────────────────────────────────────┤ 0x00000000 │ NULL pointer region (reserved 64 KB) │ └─────────────────────────────────────────────┘ Low Memory (User Space - ring 3 accessible)7e:T59f,// Simplified representation of VAD structure // Actual Windows structure is more complex typedef struct _MMVAD_SHORT { // AVL tree linkage struct _MMVAD_SHORT* LeftChild; struct _MMVAD_SHORT* RightChild; struct _MMVAD_SHORT* Parent; // Address range (in page numbers, not bytes) ULONG_PTR StartingVpn; // Starting Virtual Page Number ULONG_PTR EndingVpn; // Ending Virtual Page Number // Flags encoding protection, type, etc. union { ULONG_PTR Flags; struct { ULONG_PTR VadType : 3; // Private, Mapped, etc. ULONG_PTR Protection : 5; // PAGE_READONLY, etc. ULONG_PTR PrivateMemory : 1; // Private or shared? ULONG_PTR MemCommit : 1; // Committed? // ... additional flags }; }; } MMVAD_SHORT, *PMMVAD_SHORT; // For mapped files and image sections, extended VAD typedef struct _MMVAD { MMVAD_SHORT Core; // Contains basic VAD info // Additional fields for mapped/image VADs union { ULONG_PTR LongFlags; struct { ULONG_PTR CopyOnWrite : 1; ULONG_PTR Inherit : 1; // Inherited to child processes? // ... more flags }; }; PCONTROL_AREA ControlArea; // Points to file/section backing PFILE_OBJECT FileObject; // The file backing this region } MMVAD, *PMMVAD;7f:T4ad,// Using WinDbg to examine VAD tree // First, find the process EPROCESS structure !process 0 0 notepad.exe PROCESS ffffb10c4a2e5080 SessionId: 1 Cid: 1234 Peb: 00ca1000 ParentCid: 0ab4 DirBase: 1a2b3000 ObjectTable: ffffc0012345abc0 Image: notepad.exe // Now dump the VAD tree !vad ffffb10c4a2e5080 VAD Level Start End Commit Type ffffb10c4b123000 6 00010 0001f 4 Private READWRITE ffffb10c4b234000 5 00020 00021 2 Mapped READONLY Pagefile-backed section ffffb10c4b345000 4 00400 00412 18 Mapped Exe EXECUTE_WRITECOPY \Windows otepad.exe ffffb10c4b456000 5 77000 770ff 256 Mapped Exe EXECUTE_WRITECOPY \Windows\System32 tdll.dll ffffb10c4b567000 3 7ffe0 7ffe0 1 Private READONLY ... // Examine a specific VAD in detail !vad ffffb10c4b345000 1 VAD @ ffffb10c4b345000 Start VPN: 400 End VPN: 412 ControlArea: ffffb10c4a1e7c00 FirstPrototypePte: fffff80045678000 Commit Charge: 18 Type: MAPPED_EXE Protection: PAGE_EXECUTE_WRITECOPY Flags: ImageMap, CopyOnWrite80:T61d,#include #include // Examine memory layout randomization void examineASLR() { HMODULE exeBase = GetModuleHandle(NULL); HMODULE ntdll = GetModuleHandle(L"ntdll.dll"); HMODULE kernel32 = GetModuleHandle(L"kernel32.dll"); printf("Process Memory Layout (changes each launch with ASLR): "); printf("================================================ "); printf("EXE Base Address: %p ", exeBase); printf("ntdll.dll Base: %p ", ntdll); printf("kernel32.dll Base: %p ", kernel32); // Stack location int stackVar; printf("Stack Variable Addr: %p ", &stackVar); // Heap location void* heapAlloc = HeapAlloc(GetProcessHeap(), 0, 100); printf("Heap Allocation: %p ", heapAlloc); HeapFree(GetProcessHeap(), 0, heapAlloc); // Check if high-entropy ASLR is enabled for this process PROCESS_MITIGATION_ASLR_POLICY aslrPolicy = {0}; if (GetProcessMitigationPolicy( GetCurrentProcess(), ProcessASLRPolicy, &aslrPolicy, sizeof(aslrPolicy))) { printf(" ASLR Policy: "); printf(" EnableBottomUpRandomization: %d ", aslrPolicy.EnableBottomUpRandomization); printf(" EnableForceRelocateImages: %d ", aslrPolicy.EnableForceRelocateImages); printf(" EnableHighEntropy: %d ", aslrPolicy.EnableHighEntropy); printf(" DisallowStrippedImages: %d ", aslrPolicy.DisallowStrippedImages); } }81:T4a1,One of the most important concepts in Windows memory management is the distinction between **reserved** and **committed** memory. This two-phase allocation model provides flexibility and efficiency by separating address space reservation from actual memory resource consumption. **Reserved Memory:** Reserving memory claims a range of virtual addresses without consuming physical RAM or page file space. It's essentially placing a placeholder in the VAD tree saying "this region is allocated, but empty." Attempting to access reserved (but not committed) memory causes an access violation. **Committed Memory:** Committing memory actually allocates backing store—the system guarantees that physical RAM or page file space exists to hold the data. Only committed memory can be accessed without faulting. **Why the Distinction Matters:** This model enables efficient patterns like: 1. **Thread Stacks**: Reserve 1 MB, commit only 64 KB initially, grow on demand 2. **Sparse Arrays**: Reserve huge range, commit only pages actually used 3. **Memory-Mapped Files**: Reserve full file size, commit pages as accessed 4. **Growing Buffers**: Reserve maximum size, commit incrementally82:T9df,#include #include void demonstrateReserveCommit() { // Phase 1: Reserve 1 MB of address space // No physical memory consumed yet! SIZE_T reserveSize = 1024 * 1024; // 1 MB LPVOID reserved = VirtualAlloc( NULL, // Let system choose address reserveSize, // Size to reserve MEM_RESERVE, // Reserve only, don't commit PAGE_READWRITE // (Ignored until commit) ); if (!reserved) { printf("Reserve failed: %lu ", GetLastError()); return; } printf("Reserved 1 MB at: %p ", reserved); // Attempting to access reserved memory causes access violation! // CRASH: ((char*)reserved)[0] = 'x'; // Phase 2: Commit first 64 KB SIZE_T commitSize = 64 * 1024; // 64 KB LPVOID committed = VirtualAlloc( reserved, // Within reserved region commitSize, // Size to commit MEM_COMMIT, // Now commit PAGE_READWRITE // With read/write access ); if (!committed) { printf("Commit failed: %lu ", GetLastError()); VirtualFree(reserved, 0, MEM_RELEASE); return; } printf("Committed 64 KB starting at: %p ", committed); // Now we can use the committed memory memset(committed, 'A', commitSize); printf("Wrote to committed memory successfully "); // Phase 3: Commit an additional 64 KB further into the reserved region LPVOID moreCommit = VirtualAlloc( (BYTE*)reserved + (256 * 1024), // 256 KB offset commitSize, MEM_COMMIT, PAGE_READWRITE ); printf("Committed another 64 KB at: %p ", moreCommit); // Query the region to see state MEMORY_BASIC_INFORMATION mbi; VirtualQuery(reserved, &mbi, sizeof(mbi)); printf(" First region state: %s ", mbi.State == MEM_COMMIT ? "COMMITTED" : mbi.State == MEM_RESERVE ? "RESERVED" : "FREE"); // Clean up VirtualFree(reserved, 0, MEM_RELEASE); // Release entire region printf("Released all memory "); } // Pattern 2: Reserve+Commit in one call (common shorthand) void simpleAlloc() { // Most allocations do both at once LPVOID mem = VirtualAlloc( NULL, 4096, MEM_RESERVE | MEM_COMMIT, // Both flags together PAGE_READWRITE ); // Ready to use immediately memset(mem, 0, 4096); VirtualFree(mem, 0, MEM_RELEASE); }83:T576,Understanding the Commit Limit and Commit Charge ═══════════════════════════════════════════════════════════════════ COMMIT LIMIT = Physical RAM + Page File Size (current) - Represents maximum possible committed memory system-wide - If page file can grow, this limit can increase dynamically COMMIT CHARGE = Sum of all committed memory across all processes - Every MEM_COMMIT allocation increases this - Every VirtualFree/process exit decreases this EXAMPLE SCENARIO: System: 16 GB RAM + 20 GB Page File = 36 GB Commit Limit Process A: Commits 4 GB → System Commit Charge = 4 GB Process B: Commits 8 GB → System Commit Charge = 12 GB Process C: Commits 10 GB → System Commit Charge = 22 GB Remaining commitment available: 36 - 22 = 14 GB IMPORTANT: Commit Limit ≠ RAM - You can commit more than physical RAM - Excess goes to page file when needed - But you CANNOT commit more than Commit Limit When Commit Limit is reached: - VirtualAlloc with MEM_COMMIT fails - malloc() returns NULL - new throws std::bad_alloc - System becomes unstable Monitoring (Task Manager → Performance → Memory): - "In use" = Working Set (physical RAM) - "Committed" = Commit Charge (what we discussed) - Shows both "X / Y" where Y is Commit Limit84:T68f,A Windows process's address space contains several distinct regions, each serving a specific purpose. Understanding these regions helps diagnose memory issues, optimize performance, and exploit protections. **1. Null Region (0x00000000 - 0x0000FFFF):** The first 64 KB of address space is permanently reserved and uncommitted. This catches null pointer dereferences—attempting to read from or write to addresses near NULL causes an access violation rather than silently corrupting memory. **2. Executable Image (.exe and .dlls):** The main executable and all loaded DLLs are mapped into the address space. Within each image: - `.text` section: Code (PAGE_EXECUTE_READ) - `.data` section: Initialized globals (PAGE_READWRITE) - `.rdata` section: Read-only data, import tables (PAGE_READONLY) - `.bss` section: Uninitialized globals (PAGE_READWRITE) **3. Heap(s):** Process heaps managed by the heap manager (ntdll!RtlHeap or the Low Fragmentation Heap). Each process has a default heap, and can create additional heaps. Heaps grow upward from their initial location. **4. Thread Stacks:** Each thread receives a stack, typically with 1 MB reserved and 64 KB+ committed. Stacks have guard pages to detect overflow. Stack grows downward (toward lower addresses). **5. Memory-Mapped Files:** File contents mapped into the address space. Includes: - DLL/EXE sections (shared, copy-on-write) - Explicitly mapped files (data files, IPC) - Page file backed sections (anonymous mappings) **6. PEB and TEB:** The Process Environment Block (PEB) and Thread Environment Blocks (TEBs) contain critical per-process and per-thread information and are mapped at specific locations.85:Tdff,#include #include #include // Walk the process memory map void examineMemoryMap() { SYSTEM_INFO si; GetSystemInfo(&si); printf("Memory Information "); printf("══════════════════════════════════════════════════════════ "); printf("Page Size: %lu bytes ", si.dwPageSize); printf("Allocation Granularity: %lu bytes ", si.dwAllocationGranularity); printf("User Address Range: %p - %p ", si.lpMinimumApplicationAddress, si.lpMaximumApplicationAddress); printf(" "); // Walk all memory regions LPVOID address = si.lpMinimumApplicationAddress; MEMORY_BASIC_INFORMATION mbi; SIZE_T totalCommitted = 0; SIZE_T totalReserved = 0; SIZE_T totalFree = 0; printf("Address Range Size State Type Protection "); printf("────────────────────────────────────────────────────────────────── "); while (address < si.lpMaximumApplicationAddress) { if (VirtualQuery(address, &mbi, sizeof(mbi)) == 0) { break; } const char* state = ""; switch (mbi.State) { case MEM_COMMIT: state = "COMMIT "; totalCommitted += mbi.RegionSize; break; case MEM_RESERVE: state = "RESERVE"; totalReserved += mbi.RegionSize; break; case MEM_FREE: state = "FREE "; totalFree += mbi.RegionSize; break; } const char* type = ""; switch (mbi.Type) { case MEM_IMAGE: type = "IMAGE "; break; case MEM_MAPPED: type = "MAPPED "; break; case MEM_PRIVATE: type = "PRIVATE"; break; default: type = " "; break; } char prot[32]; switch (mbi.Protect) { case PAGE_EXECUTE_READ: strcpy(prot, "EXECUTE_READ"); break; case PAGE_EXECUTE_READWRITE: strcpy(prot, "EXECUTE_RW"); break; case PAGE_READWRITE: strcpy(prot, "READWRITE"); break; case PAGE_READONLY: strcpy(prot, "READONLY"); break; case PAGE_WRITECOPY: strcpy(prot, "WRITECOPY"); break; case PAGE_NOACCESS: strcpy(prot, "NOACCESS"); break; case PAGE_GUARD: strcpy(prot, "GUARD"); break; default: sprintf(prot, "0x%x", mbi.Protect); break; } // Print significant regions (skip tiny ones for readability) if (mbi.RegionSize >= 64 * 1024 || mbi.State != MEM_FREE) { printf("%p - %p %8llu KB %s %s %s ", mbi.BaseAddress, (BYTE*)mbi.BaseAddress + mbi.RegionSize, mbi.RegionSize / 1024, state, type, prot); } address = (BYTE*)mbi.BaseAddress + mbi.RegionSize; } printf(" ════════════════════════════════════════════════════════ "); printf("Summary: "); printf(" Total Committed: %.2f MB ", totalCommitted / (1024.0 * 1024.0)); printf(" Total Reserved: %.2f MB ", totalReserved / (1024.0 * 1024.0)); printf(" Total Free: %.2f GB ", totalFree / (1024.0 * 1024.0 * 1024.0)); }86:T648,// Analyzing process memory in WinDbg // Attach to process first // Show high-level memory statistics !address -summary --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal Free 120 7ffe'df580000 ( 127.995 TB) 99.99% 250 0'12a40000 ( 298.250 MB) 47.76% 0.00% Image 212 0'06ee0000 ( 110.875 MB) 17.76% 0.00% Heap 48 0'05c00000 ( 92.000 MB) 14.73% 0.00% Stack 14 0'00f00000 ( 15.000 MB) 2.40% 0.00% TEB 7 0'0000e000 ( 56.000 KB) 0.01% 0.00% PEB 1 0'00001000 ( 4.000 KB) 0.00% 0.00% // Show detailed memory map !address // Find specific allocations !address -f:Heap // Show all heap regions !address -f:Stack // Show all stack regions !address -f:Image // Show all image (DLL/EXE) regions // Examine specific module !dh notepad // Show PE headers lm vm notepad // Verbose module information // Stack analysis !teb // Thread Environment Block StackBase: 00000083b3b00000 StackLimit: 00000083b3af4000 DeallocationStack: 00000083b3a00000 // The stack layout: // DeallocationStack (reserved start) // ... reserved but uncommitted ... // StackLimit (committed start + guard page) // ... committed stack space ... // StackBase (top of stack)72:{"json":{"id":"seed_1451e4d7fd4bbd8f752fe9aa5214c7d6","slug":"windows-memory-management","category":"Operating Systems","topic":"Windows Memory Management","title":"Windows Memory Management","description":"Master the intricacies of Windows memory management including virtual address space layout, paging file mechanics, working set management, memory pools, and modern memory compression. Understand how Microsoft's flagship OS handles memory at the system level.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_81ce3eb5f6eeedda7763770a0eabd4f9","title":"Virtual Address Space","order":0,"content":[{"id":"opening-hook","title":"The Windows Memory Landscape","content":[{"data":{"content":"Every process running on Windows exists within its own **virtual address space**—a private, isolated view of memory that appears continuous and exclusively owned, even as the physical reality involves shared RAM, disk backing, and complex kernel structures. Understanding this virtual address space is fundamental to comprehending how Windows manages memory, provides process isolation, enables security features, and achieves the performance characteristics that power billions of devices worldwide.\n\nWindows memory management has evolved dramatically from the limited 16-bit segmented models of Windows 3.x through the 32-bit flat model of Windows NT to today's sophisticated 64-bit architectures supporting terabytes of virtual address space. Each evolution brought new capabilities, new challenges, and new solutions that systems programmers and performance engineers must understand."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete architecture of Windows virtual address space—from the fundamental user/kernel split to the nuances of address space layout randomization (ASLR), the differences between 32-bit and 64-bit address spaces, and how Windows organizes VADs (Virtual Address Descriptors) to track memory regions. This knowledge forms the foundation for understanding all other Windows memory management concepts.","variant":"info"},"type":"callout"}]},{"id":"vas-fundamentals","title":"Fundamentals of Virtual Address Space","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"rows":[["Private per process","Each process has its own VAS isolated from others","Memory corruption in one process cannot directly affect another"],["Sparse","Not all addresses in the range are usable simultaneously","Process can allocate memory on-demand without reserving upfront"],["Paged","Backed by RAM and/or page file in page-sized chunks","Memory can be swapped to disk when physical RAM is under pressure"],["Protected","Kernel enforces access permissions on memory regions","Stack, heap, code all have appropriate RWX permissions"],["Divided","Split between user-mode and kernel-mode regions","Kernel memory always mapped but inaccessible from user mode"]],"caption":"Virtual Address Space Characteristics","headers":["Characteristic","Description","Implication"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"Think of VAS as a Ledger, Not a Warehouse","content":"The virtual address space is like a ledger of accounts, not a physical warehouse. Creating a 'slot' in the ledger (reserving address space) costs almost nothing—the expense comes when you actually put something in it (committing memory). This distinction between **reserved** and **committed** memory is central to Windows memory management.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"user-kernel-split","title":"The User/Kernel Address Space Split","content":[{"data":{"content":"Every Windows virtual address space is divided into two primary regions: **user mode** space and **kernel mode** space. This division is enforced by the processor hardware and represents a fundamental security boundary.\n\n**The Classical 32-bit Split:**\n\nOn 32-bit Windows, the total 4 GB (2^32 bytes) address space is traditionally split:\n- **Lower 2 GB (0x00000000 – 0x7FFFFFFF)**: User mode space\n- **Upper 2 GB (0x80000000 – 0xFFFFFFFF)**: Kernel mode space\n\nThis 2GB/2GB split was chosen as a balance between user application needs and kernel requirements. However, some applications need more user-mode address space, leading to the `/3GB` boot option that provides 3 GB user / 1 GB kernel—at the cost of reduced kernel virtual address space.\n\n**The 64-bit Revolution:**\n\nWith 64-bit Windows, the theoretical 16 exabytes (2^64) of address space eliminates practical limitations. However, current implementations don't use the full range:"},"type":"text"},{"data":{"rows":[["32-bit (default)","2 GB","2 GB","4 GB"],["32-bit (/3GB)","3 GB","1 GB","4 GB"],["64-bit (pre-8.1)","8 TB","8 TB","16 TB"],["64-bit (8.1+)","128 TB","128 TB","256 TB"],["64-bit (Server 2025)","Up to 64 PB*","Up to 64 PB*","128 PB*"]],"caption":"Windows Virtual Address Space Sizes","headers":["Windows Version","User Mode Space","Kernel Mode Space","Total VAS"]},"type":"table"},{"data":{"icon":"Info","title":"Canonical Address Form","content":"On x64 processors, only 48 bits of the 64-bit address are currently used (or 57 bits with LA57/5-level paging). The unused upper bits must be sign-extended from bit 47, creating 'canonical' addresses. Addresses where the high bits don't match are invalid, causing a fault. This is why user addresses start with 0x0000 and kernel addresses start with 0xFFFF on 64-bit Windows—they're in different halves of the canonical address space.","variant":"note"},"type":"callout"},{"data":{"content":"$7b"},"type":"text"},{"data":{"fileName":"Address Space Layout Conceptual View","languages":[{"code":"$7c","label":"64-bit Layout","value":"text"},{"code":"$7d","label":"32-bit Layout","value":"text2"}]},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"virtual-address-descriptors","title":"Virtual Address Descriptors (VADs)","content":[{"data":{"content":"While page tables track the mapping of individual pages to physical memory, the Windows Memory Manager uses a higher-level structure called **Virtual Address Descriptors (VADs)** to track regions of virtual memory. VADs are organized in a **self-balancing AVL tree** for each process, enabling O(log n) lookup of any virtual address.\n\n**What VADs Track:**\n\nEach VAD describes a contiguous region of virtual addresses and stores:\n- **Starting and Ending Virtual Page Numbers**: The range of pages covered\n- **Protection**: Read, write, execute, copy-on-write permissions\n- **Type**: Private memory, mapped file, image section, etc.\n- **Commit State**: Whether pages are reserved, committed, or a mix\n- **Backing**: For mapped files, a pointer to the section object\n\n**VAD Tree Structure:**\n\nThe VAD tree enables the Memory Manager to quickly answer questions like:\n- Is address X allocated? What protection does it have?\n- What's the next free region after address Y?\n- What file backs the memory at address Z?"},"type":"text"},{"data":{"fileName":"VAD Structure (Simplified)","languages":[{"code":"$7e","label":"C","value":"c"},{"code":"$7f","label":"WinDbg","value":"windbg"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"VADs vs. Page Tables","content":"Think of VADs as the Memory Manager's high-level bookkeeping, while page tables are the CPU's low-level implementation. VADs describe *what should be* at an address (a file mapping, private memory, etc.), while page tables describe *where it actually is* (in RAM, on disk, not yet allocated). The Memory Manager uses VADs to lazily populate page tables on demand.","variant":"tip"},"type":"callout"},{"data":{"content":"**VAD Types:**\n\nWindows uses several VAD types to handle different memory allocation patterns:"},"type":"text"},{"data":{"rows":[["`VadNone`","Basic private allocation","VirtualAlloc for private data"],["`VadDevicePhysicalMemory`","Physical memory mapping","Device driver mappings"],["`VadImageMap`","Executable image section",".exe and .dll files"],["`VadAwe`","Address Windowing Extensions","Large database buffers"],["`VadWriteWatch`","Write-tracked regions","JIT compilers, GC"],["`VadLargePages`","Large page (2MB/1GB) allocations","High-performance apps"],["`VadRotatePhysical`","Rotating physical page backing","Special allocations"]],"headers":["VAD Type","Description","Example Use"]},"type":"table"}],"titleType":"number","titleNumber":3},{"id":"aslr","title":"Address Space Layout Randomization (ASLR)","content":[{"data":{"content":"Address Space Layout Randomization (ASLR) is a critical security feature that randomizes the memory locations of key process structures. Introduced in Windows Vista and enhanced in every subsequent release, ASLR makes exploitation significantly harder by preventing attackers from predicting where code and data will be located.\n\n**The Threat Model:**\n\nWithout ASLR, an attacker who discovers a buffer overflow vulnerability knows exactly where critical structures reside. They can craft an exploit that:\n1. Overflows a buffer to overwrite a return address\n2. Points the return address to known shellcode location\n3. Or jumps to a known library function (return-to-libc attack)\n\n**How ASLR Defeats This:**\n\nWith ASLR, the attacker doesn't know where anything is located:\n- The executable loads at a random base address\n- Each DLL loads at a random address\n- The heap grows from a random starting point\n- Thread stacks are placed randomly\n- Even kernel structures are randomized"},"type":"text"},{"data":{"rows":[["EXE Base","8 bits (256 locations)","17-19 bits","High-entropy ASLR on 64-bit"],["DLL Base","8 bits","19 bits","Per-boot randomization"],["Stack","14 bits","17 bits","Per-thread randomization"],["Heap","5 bits","17 bits","Per-process randomization"],["Kernel","N/A","24 bits","KASLR (Kernel ASLR)"]],"caption":"ASLR Entropy (Randomization Bits) on Windows","headers":["Component","32-bit Entropy","64-bit Entropy","Notes"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"ASLR Requires Proper Compilation","content":"ASLR only works for executables compiled with the `/DYNAMICBASE` linker flag (and `/HIGHENTROPYVA` for 64-bit high-entropy ASLR). Legacy applications without these flags load at their preferred base address, negating ASLR benefits. Modern Visual Studio enables these by default, but third-party and legacy software may not be protected.","variant":"warning"},"type":"callout"},{"data":{"content":"**ASLR Implementation Details:**\n\n**Boot-time DLL Randomization:**\nWhen Windows boots, system DLLs are loaded at randomized addresses. All processes share these mappings (for memory efficiency), so the DLL randomization is per-boot, not per-process. This means the same DLL has the same address in all processes until the next reboot.\n\n**Per-Process Image Randomization:**\nEach process's main executable is randomized individually if compiled with ASLR support. Unlike DLLs, the EXE base changes every process launch.\n\n**Stack and Heap Randomization:**\nBeyond base addresses, Windows adds additional randomization:\n- Stack base varies per thread\n- Initial stack pointer has additional offset\n- Heap manager adds random padding\n- Memory allocations aren't strictly sequential\n\n**Control Flow Guard (CFG) Integration:**\nWindows 10 added Control Flow Guard, which validates indirect call targets. Combined with ASLR, this significantly raises the exploitation difficulty."},"type":"text"},{"data":{"fileName":"Checking ASLR Status","languages":[{"code":"# Check if executables have ASLR enabled using dumpbin\ndumpbin /headers \"C:\\Windows\\System32\notepad.exe\" | findstr \"DLL characteristics\"\n\n# Output shows:\n# 8160 DLL characteristics\n# High Entropy Virtual Addresses <- HIGHENTROPYVA\n# Dynamic base <- DYNAMICBASE (ASLR)\n# NX compatible <- DEP\n# Terminal Server Aware\n\n# Using PowerShell to check multiple files\nGet-ChildItem \"C:\\Windows\\System32\\*.exe\" | ForEach-Object {\n $pe = [System.Reflection.Assembly]::LoadFile($_.FullName)\n # ... PE header analysis\n}\n\n# Using Process Hacker or windbg for live analysis\n# In WinDbg attached to a process:\n!dh -f ntdll # Show DLL characteristics\nlm # List modules with base addresses\n\n# Compare base addresses across process launches:\n# Launch 1: notepad.exe at 0x00007FF6A1340000\n# Launch 2: notepad.exe at 0x00007FF67E280000\n# Addresses differ - ASLR is working!","label":"PowerShell","value":"powershell"},{"code":"$80","label":"C","value":"c"}]},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"reserved-vs-committed","title":"Reserved vs. Committed Memory","content":[{"data":{"content":"$81"},"type":"text"},{"data":{"left":[{"data":{"items":["Claims virtual address range","No RAM or page file consumed","Very fast operation","Cannot be accessed (causes AV)","Creates VAD entry in process","Prevents fragmentation of VAS","Typical use: stack guard pages"],"title":{"icon":"Info","text":"Reserved Memory","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Allocates from system commit limit","RAM or page file space guaranteed","Slightly slower (accounting)","Can be read/written per protection","Page tables created on first access","Physical pages allocated lazily","Typical use: heap allocations"],"title":{"icon":"CheckCircle","text":"Committed Memory","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"VirtualAlloc Reservation and Commit","languages":[{"code":"$82","label":"C","value":"c"},{"code":"$83","label":"Commit Accounting","value":"text"}]},"type":"code"},{"data":{"icon":"Info","title":"Lazy Physical Page Allocation","content":"Even committed memory doesn't immediately consume physical RAM. Windows uses **demand paging**: physical pages are allocated only when first accessed. Committing just adds to the system commit charge (accounting) and creates the appropriate VAD entry. The actual page tables and physical pages materialize on first touch.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"process-memory-regions","title":"Process Memory Regions in Detail","content":[{"data":{"content":"$84"},"type":"text"},{"data":{"fileName":"Examining Process Memory Map","languages":[{"code":"$85","label":"C","value":"c"},{"code":"$86","label":"WinDbg Analysis","value":"windbg"}]},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Windows Virtual Address Space","content":[{"data":{"content":"We've covered the foundational concepts of Windows virtual address space. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**Every process has private VAS** — Virtual addresses are isolated per-process; the same address in different processes refers to different physical memory.","**User/Kernel split** — Lower addresses for user mode (2-128 TB), upper addresses for kernel mode. Kernel is mapped everywhere but protected.","**VADs track regions** — The AVL tree of Virtual Address Descriptors provides O(log n) lookup and tracks allocation metadata.","**ASLR randomizes layout** — Critical security feature that randomizes code, stack, heap, and library locations to hinder exploitation.","**Reserved ≠ Committed** — Reserving claims address space (free), committing allocates from system commit limit (expensive).","**Lazy allocation** — Even committed memory doesn't consume physical RAM until first accessed (demand paging)."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nWith the virtual address space foundation in place, we'll explore the **paging file**—how Windows extends available memory beyond physical RAM, manages page-out and page-in operations, and configures this critical system resource."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the architecture of Windows virtual address space—the fundamental abstraction upon which all Windows memory management builds. Every memory operation, from simple malloc() to complex kernel pool allocations, operates within this virtual address space framework.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_fab275f7fa4beca2262ad3974b7aab95","title":"Paging File","order":1,"content":null,"isLocked":true},{"id":"seed_3ec1798062415e481bd3ae359acf2eb6","title":"Working Sets","order":2,"content":null,"isLocked":true},{"id":"seed_17f5a90d485c42251e34a725c0ee312a","title":"Memory Pools","order":3,"content":null,"isLocked":true},{"id":"seed_6465b0d82f2caaf84676b29f75ac5ed9","title":"Memory Compression","order":4,"content":null,"isLocked":true}]}}