Introduction to Windows Diagnostics and Memory Dump Configuration

When Windows Server 2019 encounters a fatal error — typically a kernel panic caused by a buggy driver, hardware failure, or memory corruption — it generates a blue screen of death (BSOD) and writes a memory dump file to disk before restarting. These dump files are critical for diagnosing the root cause of the crash. Windows supports several dump types: Small Memory Dump (256 KB, contains only the crash parameters and stack trace), Kernel Memory Dump (variable size, contains the full kernel memory and loaded drivers), Complete Memory Dump (full physical RAM, the most detailed), and Automatic Memory Dump (similar to Kernel but Windows manages the size). Configuring the correct dump type, ensuring adequate disk space, and knowing how to analyze the resulting dump files with Windows Debugger (WinDbg) are essential skills for Windows Server administrators.

Configuring Memory Dump Settings via System Properties

Access memory dump settings through System Properties. Open the Run dialog and type sysdm.cpl. Navigate to the Advanced tab and click Settings under Startup and Recovery. The System Failure section contains the memory dump configuration:

Automatically restart: should be checked for production servers to allow automatic recovery from BSODs. Unchecking it keeps the blue screen on screen until manually rebooted, which can be useful during active troubleshooting. Write debugging information: the dropdown selects the dump type. Dump file: the path where the dump file is written — default is %SystemRoot%MEMORY.DMP. Overwrite any existing file: checked by default; uncheck if you want to preserve multiple dump files.

For production servers where detailed analysis is needed, select Kernel Memory Dump as it captures all relevant kernel state without requiring the enormous disk space of a Complete Memory Dump. For servers with intermittent crashes where you need maximum information, use Automatic Memory Dump (the default on Windows Server 2019) which automatically adjusts between kernel and complete depending on available page file space.

Configuring Dump Settings via Registry and PowerShell

Memory dump configuration is stored in the Windows Registry at HKLMSYSTEMCurrentControlSetControlCrashControl. Configure it via PowerShell for remote management or scripted deployment:

# Set dump type: 0=None, 1=Complete, 2=Kernel, 3=Small (256KB), 7=Automatic
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name CrashDumpEnabled -Value 2

# Set dump file path
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name DumpFile -Value "D:CrashDumpsMEMORY.DMP"

# Auto restart after BSOD
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name AutoReboot -Value 1

# Send alert to Event Log
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name LogEvent -Value 1

# Overwrite existing dump
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name Overwrite -Value 1

Redirect dump files to a non-system volume (D: in this example) to avoid filling the OS volume during a crash loop and to ensure the dump write succeeds even when C: is nearly full.

Page File Requirements for Memory Dumps

Windows requires a page file on the system volume (C:) to enable memory dump creation. The page file must be large enough to store the dump data. Requirements by dump type:

Small Memory Dump: page file can be as small as 2 MB. Kernel Memory Dump: page file must be at least the size of the dump output, which varies but is typically 1–4 GB for a server with 16–64 GB RAM. Complete Memory Dump: page file must be at least physical RAM size + 1 MB. Automatic Memory Dump: Windows automatically adjusts the page file size as needed, but it must be able to grow to at least the size of a kernel dump.

Configure the page file to allow system management (variable size) and ensure the initial/minimum size is at least 2 GB on the system volume:

# Check current page file settings
Get-WmiObject -Class Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize
# Set page file to system managed on C:
$cs = Get-WmiObject -Class Win32_ComputerSystem
$cs.AutomaticManagedPagefile = $true
$cs.Put() | Out-Null

Installing Windows Debugger (WinDbg) for Dump Analysis

WinDbg is Microsoft’s kernel and user-mode debugger used to analyze crash dump files. Install it as part of the Windows SDK or as a standalone tool from the Microsoft Store. On the analysis workstation (not necessarily the crashed server), install via Windows Package Manager:

winget install Microsoft.WinDbg

Configure the Microsoft Symbol Server so WinDbg can resolve kernel and driver symbols during analysis. Set the symbol path in WinDbg or via an environment variable:

[Environment]::SetEnvironmentVariable("_NT_SYMBOL_PATH", "SRV*C:Symbols*https://msdl.microsoft.com/download/symbols", "Machine")

Analyzing a Memory Dump with WinDbg

Open WinDbg, then open the memory dump file: File > Open Crash Dump. Select the MEMORY.DMP file. WinDbg loads the symbols (downloading from Microsoft’s symbol server if not cached). Run the automated analysis command:

!analyze -v

The output provides: the bugcheck code and parameters (e.g., DRIVER_IRQL_NOT_LESS_OR_EQUAL with parameters pointing to a specific address), the faulting module (often a specific driver .sys file), the call stack at the time of the crash (showing which functions were executing), and a probable cause (WinDbg often identifies the exact driver causing the fault). Additional useful commands:

!lmvm drivername    # Show details for a specific loaded module/driver
lm                  # List all loaded modules
!thread             # Show the current thread's call stack
kb                  # Display the call stack

Configuring Small Memory Dumps for Production Servers

For servers where disk space is limited or where you want to collect crash data over time without overwriting previous dumps, configure Small Memory Dumps (minidumps). These are stored in C:WindowsMinidump as individual numbered files, one per crash. Unlike the main MEMORY.DMP, minidumps are not overwritten by subsequent crashes:

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name CrashDumpEnabled -Value 3
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name MinidumpDir -Value "C:WindowsMinidump"

List minidump files and their dates to track crash frequency:

Get-ChildItem "C:WindowsMinidump" | Sort-Object LastWriteTime -Descending | Select-Object Name, LastWriteTime, Length

Analyze a minidump in WinDbg the same way as a full dump — open the .dmp file and run !analyze -v. Minidumps contain less data than kernel dumps but still usually identify the faulting driver and bugcheck parameters needed for root-cause analysis.