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

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

When Windows Server 2025 crashes with a blue screen (bugcheck), the operating system has only seconds to write diagnostic data before the machine restarts. Whether that data captures everything needed for root cause analysis — or nothing useful at all — depends entirely on how crash dump settings are configured before the failure occurs. Memory dump configuration covers dump type selection (complete, kernel, small, or automatic), ensuring the paging file is sized appropriately, setting the dump file destination, and enabling kernel debugging for live or post-mortem analysis with WinDbg. This guide also covers using Sysinternals NotMyFault to intentionally trigger a crash for testing, and how to analyze dump files with WinDbg’s !analyze -v command and Visual Studio to pinpoint the failing driver or component.

Prerequisites

• Windows Server 2025 with Administrator privileges
• Sufficient disk space for the target dump type (complete dump requires RAM + ~300 MB; kernel dump is typically 30–50% of RAM)
• Windows Debugger (WinDbg) from the Windows SDK or Microsoft Store
• Sysinternals NotMyFault (for controlled crash testing — use only on non-production servers)
• Symbol files access: configure srv*C:Symbols*https://msdl.microsoft.com/download/symbols in WinDbg
• Visual Studio 2022 (optional, for user-mode dump analysis)

Step 1: Understand Dump Types and Choose the Right One

Windows supports four crash dump types, configured via the CrashDumpEnabled registry value:

• Complete Memory Dump (1): Captures all physical RAM. Required for deep kernel analysis. Dump file size equals installed RAM.
• Kernel Memory Dump (2): Captures only kernel-allocated memory — typically 30–50% of RAM. Sufficient for most driver and OS crash analysis. Recommended for most servers.
• Small Memory Dump / Minidump (3): Captures only the bugcheck code, stack trace, and a small set of memory pages. Very small (256 KB) but may lack context for complex issues.
• Automatic Memory Dump (7): Like kernel dump but Windows automatically manages pagefile size. Default since Windows Server 2012.

Step 2: Configure Crash Dump Settings via Registry

Crash dump configuration lives in the CrashControl registry key. Always configure this proactively — you cannot change it after a crash has occurred:

$CrashControlPath = "HKLM:SYSTEMCurrentControlSetControlCrashControl"

# Set dump type: 1=Complete, 2=Kernel, 3=Small, 7=Automatic
# Kernel Memory Dump is the recommended default for most Windows Server 2025 deployments
Set-ItemProperty -Path $CrashControlPath -Name "CrashDumpEnabled" -Value 2 -Type DWord

# Set the path for the full memory dump file
Set-ItemProperty -Path $CrashControlPath -Name "DumpFile" `
    -Value "D:CrashDumpsMEMORY.DMP" -Type ExpandString

# Set the directory for minidumps (Small Memory Dump type)
Set-ItemProperty -Path $CrashControlPath -Name "MiniDumpDir" `
    -Value "D:CrashDumpsMinidumps" -Type ExpandString

# Enable automatic reboot after crash (default: enabled)
Set-ItemProperty -Path $CrashControlPath -Name "AutoReboot" -Value 1 -Type DWord

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

# Overwrite existing dump file (vs. keeping old ones — set to 0 to preserve)
Set-ItemProperty -Path $CrashControlPath -Name "Overwrite" -Value 1 -Type DWord

# Create the dump directory if it does not exist
$DumpDir = "D:CrashDumps"
if (-not (Test-Path $DumpDir)) {
    New-Item -ItemType Directory -Path $DumpDir | Out-Null
    New-Item -ItemType Directory -Path "$DumpDirMinidumps" | Out-Null
}

# Verify the configuration
Get-ItemProperty -Path $CrashControlPath |
    Select-Object CrashDumpEnabled, DumpFile, MiniDumpDir, AutoReboot, LogEvent, Overwrite

A reboot is not required for the settings to take effect — they are read at crash time from the registry.

Step 3: Ensure the Paging File Is Sized Correctly for Complete Dump

For a Complete Memory Dump, the paging file on the system drive must be at least equal to installed RAM plus 1 MB. Windows cannot write the dump if the pagefile is too small:

# Check installed RAM
$RAM_GB = [math]::Round((Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB, 1)
Write-Output "Installed RAM: $RAM_GB GB"
Write-Output "Minimum pagefile for complete dump: $([math]::Ceiling($RAM_GB + 1)) GB"

# Check current pagefile configuration
Get-CimInstance -ClassName Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, PeakUsage

# If the pagefile needs to be resized — disable automatic management, set size, re-enable
# This example sets a custom size on D: to hold the dump (separate from system pagefile)
$PageFile = Get-CimInstance -ClassName Win32_PageFileSetting -Filter "Name='D:\pagefile.sys'"
if ($PageFile) {
    $PageFile.InitialSize = [math]::Ceiling($RAM_GB + 2) * 1024  # MB
    $PageFile.MaximumSize = [math]::Ceiling($RAM_GB + 2) * 1024  # MB
    $PageFile.Put()
    Write-Output "Pagefile on D: resized to $([math]::Ceiling($RAM_GB + 2)) GB"
}

# Alternatively, use the System Properties GUI:
# System Properties → Advanced → Performance Settings → Advanced → Virtual Memory → Change

Step 4: Configure Kernel Debugger Settings

For live kernel debugging over a network connection (KDNet) or for post-mortem analysis, configure the debugger settings with bcdedit:

# Enable kernel debugging (does NOT enable live debug by default — sets the BCD flag)
bcdedit /debug on

# Configure network kernel debugging (KDNet) — useful for VM or remote server debugging
# Replace with your WinDbg host IP and a shared secret key
bcdedit /dbgsettings net hostip:192.168.10.50 port:50000 key:1.2.3.4

# Verify debug settings
bcdedit /dbgsettings

# For local/serial debugging (legacy):
# bcdedit /dbgsettings serial debugport:1 baudrate:115200

# Check current debug status
bcdedit | Select-String "debug"

# NOTE: Enabling /debug adds minor overhead. For production servers,
# configure dump settings (Steps 2-3) without enabling live debugging.
# Disable live debug after use:
# bcdedit /debug off

Step 5: Test Crash Dump Configuration with Sysinternals NotMyFault

Validate your dump configuration by intentionally triggering a crash on a non-production test server. Sysinternals NotMyFault (notmyfault64.exe) generates a controlled bugcheck:

# Download NotMyFault from Sysinternals
$SysInternalsUrl = "https://live.sysinternals.com/notmyfault64.exe"
$NotMyFaultPath  = "C:Toolsnotmyfault64.exe"

if (-not (Test-Path "C:Tools")) { New-Item -ItemType Directory -Path "C:Tools" | Out-Null }
Invoke-WebRequest -Uri $SysInternalsUrl -OutFile $NotMyFaultPath -UseBasicParsing

# Accept EULA silently (for automation)
Set-ItemProperty -Path "HKCU:SoftwareSysinternalsNotMyFault" `
    -Name "EulaAccepted" -Value 1 -Type DWord -Force

Write-Warning @"
ABOUT TO CRASH THE SERVER FOR DUMP TESTING.
Ensure this is a TEST server or Hyper-V VM with no active users.
The server will reboot automatically.
Press Ctrl+C to cancel within 10 seconds...
"@
Start-Sleep -Seconds 10

# Trigger a Stack Overflow bugcheck (0x000000ED is less destructive for testing)
# NotMyFault /crash parameter triggers immediate bugcheck
& $NotMyFaultPath /crash

After the server restarts, verify the dump file was created:

# Confirm dump file exists and note its size
Get-Item "D:CrashDumpsMEMORY.DMP" | Select-Object FullName, Length, LastWriteTime

# Check the System event log for bugcheck event (Event ID 1001)
Get-WinEvent -FilterHashtable @{ LogName="System"; Id=1001 } -MaxEvents 5 |
    Select-Object TimeCreated, Message

Step 6: Analyze Crash Dump with WinDbg

Open the dump file in WinDbg (run as Administrator). Configure the symbol path and run automated analysis:

# Configure WinDbg symbol path as an environment variable for persistence
[System.Environment]::SetEnvironmentVariable(
    "_NT_SYMBOL_PATH",
    "srv*C:Symbols*https://msdl.microsoft.com/download/symbols",
    "Machine"
)

# Launch WinDbg with the dump file from PowerShell
# Adjust WinDbg path based on your Windows SDK installation
$WinDbgPath = "C:Program Files (x86)Windows Kits10Debuggersx64windbg.exe"
$DumpFile   = "D:CrashDumpsMEMORY.DMP"

Start-Process -FilePath $WinDbgPath -ArgumentList "-z `"$DumpFile`""

Inside WinDbg, run the following commands to diagnose the crash:

; Set symbol path (if not already set via environment variable)
.sympath srv*C:Symbols*https://msdl.microsoft.com/download/symbols
.reload

; Run automated crash analysis — this is the most important command
!analyze -v

; Display bugcheck code and parameters
.bugcheck

; Show the call stack at the time of the crash
kp

; List loaded kernel modules (to identify third-party drivers)
lmv

; Check for memory corruption patterns
!memdump

; For user-mode process dumps, create a full dump from a running process:
; .dump /mf C:Dumpsprocessname.dmp

The !analyze -v output identifies the bugcheck code, the faulting module (often a third-party driver), the crash stack, and frequently includes a probable cause statement. Look for the FAULTING_MODULE and STACK_TEXT sections.

Step 7: Analyze User-Mode Dumps with Visual Studio

For application crashes (not OS bugchecks), generate and analyze user-mode dumps:

# Configure Windows Error Reporting to capture process dumps automatically
$WERPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps"
if (-not (Test-Path $WERPath)) { New-Item -Path $WERPath -Force | Out-Null }

# Configure for a specific application (e.g., w3wp.exe for IIS)
$AppWERPath = "$WERPathw3wp.exe"
New-Item -Path $AppWERPath -Force | Out-Null
Set-ItemProperty -Path $AppWERPath -Name "DumpFolder" -Value "D:CrashDumpsWER" -Type ExpandString
Set-ItemProperty -Path $AppWERPath -Name "DumpCount"  -Value 10 -Type DWord
Set-ItemProperty -Path $AppWERPath -Name "DumpType"   -Value 2  -Type DWord  # 2 = Full dump

Write-Output "WER configured: IIS worker process dumps will be saved to D:CrashDumpsWER"

# Generate an on-demand dump of a running process with ProcDump (Sysinternals)
# procdump.exe -ma -accepteula w3wp.exe D:CrashDumpsw3wp_$(Get-Date -Format yyyyMMdd_HHmmss).dmp

Open the resulting .dmp file in Visual Studio 2022 (File → Open → File), click Debug with Mixed, and use the Parallel Stacks and Call Stack windows to examine the thread state at crash time.

Conclusion

Properly configured memory dump settings on Windows Server 2025 are the difference between a crash that is diagnosable in hours and one that remains a mystery for days. By selecting the appropriate dump type for your RAM footprint and storage capacity, ensuring the paging file is sized correctly, setting a dedicated dump file path, and validating the entire pipeline with a controlled NotMyFault crash on a test server, you establish a reliable diagnostic foundation. When crashes do occur in production, WinDbg’s !analyze -v command and Microsoft’s public symbol server make driver-level and kernel-level crash analysis accessible without requiring deep kernel debugging expertise. Pair this with Windows Error Reporting for automatic user-mode dump capture, and your server crash diagnostics become systematic rather than reactive.