How to Configure Windows Diagnostics and Memory Dump on Windows Server 2022

Introduction to Windows Diagnostics and Memory Dumps on Windows Server 2022

When Windows Server 2022 crashes or becomes unresponsive, the operating system can write a memory dump to disk — a snapshot of RAM contents at the moment of failure. Analyzing these dumps is one of the most powerful ways to diagnose kernel bugs, driver crashes, and hardware issues that cause system instability. Beyond crash dumps, Windows provides tools for generating process-level dumps, which capture the memory of a specific application at a point in time and are invaluable for diagnosing application hangs, memory leaks, and access violations. This guide covers configuring all types of Windows memory dumps, generating test dumps, analyzing dump files with WinDbg, and working with process-level diagnostics tools.

Types of Memory Dump Files on Windows Server 2022

Windows Server 2022 supports four types of kernel dump configurations, each with different trade-offs between detail and disk space:

Complete Memory Dump: Captures the entire contents of physical RAM at the time of the crash. This is the most detailed dump type and requires a paging file on the system volume that is at least as large as the total physical RAM, plus 1 MB. For a server with 64 GB RAM, you need a minimum 64 GB + 1 MB pagefile. Complete dumps are written to %SystemRoot%MEMORY.DMP by default. Choose this type when you need maximum diagnostic detail and have the disk space available.

Kernel Memory Dump: Captures only kernel-mode memory — the operating system and driver code and data. User-mode process memory is excluded. Kernel dumps are typically 50-100 MB on most servers, making them far more practical for production environments. This is the recommended default for most scenarios as it contains the crash analysis data without the overhead of user-mode memory. Written to %SystemRoot%MEMORY.DMP.

Automatic Memory Dump: Introduced in Windows Server 2012. Behaves like a kernel memory dump but with one additional benefit: Windows dynamically manages the pagefile size to ensure there is always enough space for a kernel dump, even if the pagefile is set to system-managed size. This is the default setting on Windows Server 2022 installations.

Small Memory Dump (Mini Dump): Captures only the stop error code, the list of loaded drivers, and a small amount of kernel context (typically 256 KB). Small dumps are not useful for deep analysis but are valuable for quick identification of the crashing driver or component. They are written to %SystemRoot%Minidump and a new file is created for each crash rather than overwriting the previous one.

Configuring Memory Dump Settings via System Properties

The most common way to configure dump settings is through System Properties in the GUI. Access it via:

Control Panel > System > Advanced system settings > Advanced tab > Startup and Recovery > Settings

In the Startup and Recovery dialog, the “Write debugging information” dropdown controls the dump type. Options map to: Small memory dump, Kernel memory dump, Complete memory dump, and Automatic memory dump.

You can configure the same settings via the registry, which is easier to script across multiple servers:

# Configure Kernel Memory Dump
$RegPath = "HKLM:SYSTEMCurrentControlSetControlCrashControl"

# Dump type: 0=None, 1=Complete, 2=Kernel, 3=Small, 7=Automatic
Set-ItemProperty -Path $RegPath -Name "CrashDumpEnabled" -Value 2 -Type DWord

# Dump file path
Set-ItemProperty -Path $RegPath -Name "DumpFile" -Value "%SystemRoot%MEMORY.DMP" -Type ExpandString

# Overwrite existing dump file
Set-ItemProperty -Path $RegPath -Name "Overwrite" -Value 1 -Type DWord

# Auto-reboot after crash (1=yes, 0=no - disable for servers needing manual intervention review)
Set-ItemProperty -Path $RegPath -Name "AutoReboot" -Value 1 -Type DWord

# Log event to System event log on crash
Set-ItemProperty -Path $RegPath -Name "LogEvent" -Value 1 -Type DWord

# Send alert notification
Set-ItemProperty -Path $RegPath -Name "SendAlert" -Value 1 -Type DWord

Verify the current settings:

Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" |
    Select-Object CrashDumpEnabled, DumpFile, Overwrite, AutoReboot, LogEvent

Free Space Requirements for Memory Dumps

The system volume must have sufficient free space to write a dump file when a crash occurs. Insufficient disk space is a common reason why dump files are not generated after a crash, making post-mortem analysis impossible.

Calculate your space requirements based on dump type and RAM:

# Check current RAM and pagefile configuration
$OS = Get-CimInstance Win32_OperatingSystem
$TotalRAM_GB = [math]::Round($OS.TotalVisibleMemorySize / 1MB, 1)
Write-Host "Total Physical RAM: $TotalRAM_GB GB"

# For Complete dump: need TotalRAM + 1 MB free on system volume
# For Kernel dump: need approximately 50-100 MB (varies)
# For Automatic dump: Windows manages pagefile automatically

# Check system volume free space
$SystemDrive = $env:SystemDrive
$Disk = Get-PSDrive $SystemDrive.Replace(":","")
Write-Host "System drive free: $([math]::Round($Disk.Free/1GB,1)) GB"
Write-Host "Pagefile minimum needed for complete dump: $([math]::Round($TotalRAM_GB + 0.01, 1)) GB"

For servers with large amounts of RAM (256 GB or more), complete memory dumps are impractical. Use kernel or automatic memory dump on large-memory servers. If you need full RAM analysis on such a server, use Live Kernel Dump instead (available in Windows Server 2016 and later), which captures kernel memory without crashing the server:

# Generate a live kernel dump without crashing the server (Windows Server 2016+)
$LiveDumpPath = "C:LiveDump_$(Get-Date -Format 'yyyyMMdd_HHmmss').dmp"
# Using NotMyFault or Windows Task Manager diagnostic dump for process-level
# For kernel live dump, use the NotMyFault -livedump option (see below)

Using NotMyFault to Test Dump Generation

NotMyFault is a Sysinternals tool created by Mark Russinovich specifically for testing memory dump configuration and deliberately crashing Windows for diagnostic purposes. It is invaluable for verifying that your dump settings are correct before a real crash occurs.

Download NotMyFault from the Microsoft Sysinternals website: https://docs.microsoft.com/en-us/sysinternals/downloads/notmyfault

NotMyFault provides multiple crash types to test different dump scenarios:

# Run NotMyFault from an elevated command prompt
# WARNING: These commands will immediately crash/affect the system

# Generate a Bug Check (BSOD) to test crash dump writing:
notmyfault64.exe /crash

# Generate a live kernel dump WITHOUT crashing (safe, no reboot required):
notmyfault64.exe /livedump C:LiveDump.dmp

# Generate a hang (for testing hang detection):
notmyfault64.exe /hang

# Exhaust non-paged pool (kernel memory pressure test):
notmyfault64.exe /leak

The /livedump option is the safest test because it generates a kernel dump without causing a system crash or reboot. Use this on production servers to verify dump infrastructure. After running /livedump, open the resulting .dmp file in WinDbg to confirm it is valid and analyzable.

Note: The GUI version of NotMyFault (notmyfault64.exe without arguments) presents a dropdown of crash types including buffer overflow, code overwrite, and stack overflow — all useful for driver development testing but destructive on production systems.

Analyzing Memory Dumps with WinDbg

WinDbg (Windows Debugger) is the primary tool for analyzing Windows memory dump files. Install it from the Windows SDK or the Microsoft Store (WinDbg Preview). For server-side analysis, download the standalone WinDbg tools package.

Configure WinDbg symbol path to download symbols from Microsoft’s public symbol server. Without symbols, WinDbg cannot resolve function names or module information:

; In WinDbg, set the symbol path before opening a dump:
.sympath srv*C:Symbols*https://msdl.microsoft.com/download/symbols

; Reload symbols after setting the path:
.reload /f

Open a crash dump file: File > Open Crash Dump and navigate to C:WindowsMEMORY.DMP.

The most important WinDbg command for crash analysis is !analyze -v:

!analyze -v

This command automatically identifies the crash cause, provides the stop code (bug check code), identifies the faulting module and driver, and often provides a direct explanation of what went wrong. A typical output structure includes:

The BugCheck section shows the stop code (e.g., 0x0000007E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED). The MODULE_NAME and IMAGE_NAME fields identify the driver or module that caused the crash. The ANALYSIS_VERSION and FOLLOWUP_NAME sections indicate where to look for more information.

Additional useful WinDbg commands:

; Show loaded kernel modules
lm

; Display the call stack at the time of the crash
k

; Show all threads and their call stacks
~*k

; Check the crash's exception record
.exr -1

; Check the context record
.cxr

; List all IRPs (I/O request packets - useful for I/O related crashes)
!irpfind

Task Manager Memory Dump

For process-level memory dump creation without additional tools, Windows Task Manager provides a built-in dump option. In Task Manager, navigate to the Details tab, right-click any running process, and select Create dump file. The dump is saved to %LOCALAPPDATA%Temp<ProcessName>.DMP.

This creates a full user-mode process dump (minidump with full memory) suitable for analysis with WinDbg or Visual Studio. It is the fastest way to capture application state on a production server without additional tool installation.

For automated dump capture, use the PowerShell equivalent via ProcDump (see next section) or the Windows Error Reporting configuration.

Using ProcDump for Process-Level Dumps

ProcDump (from Sysinternals) is the standard tool for capturing process memory dumps based on conditions: CPU usage spikes, exception triggers, performance counter thresholds, or manual trigger. Download from https://docs.microsoft.com/en-us/sysinternals/downloads/procdump.

# Create a manual dump of a process by name
procdump64.exe -ma w3wp.exe C:DumpsIIS_Worker_Dump.dmp

# Create a dump on CPU spike: dump when w3wp exceeds 80% CPU for 5 seconds
procdump64.exe -ma -c 80 -s 5 w3wp.exe C:Dumps

# Create a dump on application exception (first-chance exceptions)
procdump64.exe -ma -e 1 -f "" notepad.exe C:Dumps

# Monitor a process and capture 3 dumps on any .NET exception:
procdump64.exe -ma -e 1 -f "System.OutOfMemoryException" -n 3 w3wp.exe C:Dumps

# Create a dump of a process by PID:
procdump64.exe -ma 1234 C:DumpsProcess_1234.dmp

# Install ProcDump as an unhandled exception handler (captures on crash):
procdump64.exe -i C:Dumps

The -ma flag creates a full memory dump (all heap memory). Without -ma, ProcDump creates a mini dump which may lack sufficient data for deep analysis.

For IIS troubleshooting, identify the specific application pool worker process PID first:

# Find IIS worker process PID for a specific application pool
& "$env:SystemRootSystem32inetsrvappcmd.exe" list wp
# Or:
Get-Process w3wp | Select-Object Id, @{N='AppPool';E={$_.MainWindowTitle}}

Configuring Automatic Dump on Specific Events

Windows Error Reporting (WER) can be configured to automatically capture dumps when specific applications crash or hang. Configure WER settings via Group Policy or registry:

# Configure WER to capture full dumps for all application crashes:
$WerPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps"

if (-not (Test-Path $WerPath)) {
    New-Item -Path $WerPath -Force | Out-Null
}

Set-ItemProperty -Path $WerPath -Name "DumpFolder" -Value "C:CrashDumps" -Type ExpandString
Set-ItemProperty -Path $WerPath -Name "DumpCount" -Value 10 -Type DWord
# DumpType: 0=custom, 1=mini, 2=full
Set-ItemProperty -Path $WerPath -Name "DumpType" -Value 2 -Type DWord

# For a specific application (e.g., w3wp.exe):
$AppPath = "$WerPathw3wp.exe"
New-Item -Path $AppPath -Force | Out-Null
Set-ItemProperty -Path $AppPath -Name "DumpFolder" -Value "C:CrashDumpsIIS" -Type ExpandString
Set-ItemProperty -Path $AppPath -Name "DumpType" -Value 2 -Type DWord
Set-ItemProperty -Path $AppPath -Name "DumpCount" -Value 5 -Type DWord

With this configuration, whenever an application crashes, WER automatically writes a full memory dump to the specified folder without requiring manual intervention.

Conclusion

Memory dump configuration and analysis is a critical skill for Windows Server 2022 administrators responsible for diagnosing system instability and application failures. Configure kernel or automatic memory dumps on all production servers, verify dump configuration using NotMyFault’s /livedump option, and ensure sufficient disk space and pagefile sizing. For application-level diagnostics, deploy ProcDump and configure WER local dump capture so that crashes are captured automatically. When a crash occurs, !analyze -v in WinDbg provides the fastest path from dump file to root cause identification.