How to Configure Windows Diagnostics and Memory Dumps on Windows Server 2012 R2

When Windows Server 2012 R2 encounters a critical system failure — typically manifesting as a Blue Screen of Death (BSOD) or Stop Error — the operating system can capture a memory dump file containing the contents of physical RAM at the time of the crash. These dump files are invaluable for post-mortem analysis using Windows Debugger (WinDbg) or kernel debuggers to identify the root cause of the failure. Beyond crash dumps, Windows Server 2012 R2 provides application crash dumps, Windows Error Reporting, and proactive diagnostic features. This guide covers configuring memory dump settings, analysing dump files, configuring application crash dumps, and using automated diagnostic tools.

Prerequisites

Administrator privileges are required. The system drive must have sufficient free space to store the dump file — complete memory dumps require free space equal to the installed RAM plus 1 MB. For a server with 64 GB RAM, ensure at least 65 GB free on the target dump partition. The Windows Debugging Tools (WinDbg) should be installed if local dump analysis is required; these are available as part of the Windows Software Development Kit (SDK).

Step 1: Configure Crash Dump Settings

Access crash dump configuration through System Properties. Right-click This PC, select Properties, click Advanced system settings, navigate to the Advanced tab, and click Settings under Startup and Recovery.

The available dump types are:

None: No dump file is written (not recommended for production). Small memory dump (minidump): Writes a 256 KB file containing basic crash information and the crashed thread’s call stack. Useful for frequent crashes with limited disk space. Kernel memory dump: Writes kernel and driver memory (typically 200 MB to 2 GB depending on RAM). Sufficient for most crash analysis. Complete memory dump: Writes all physical RAM to the dump file. Required for analysis of user-mode process crashes and the most detailed debugging. Automatic memory dump: Default since Windows Server 2012; similar to kernel memory dump but Windows manages the paging file size automatically to ensure dump space is available.

Configure via PowerShell (sets to Kernel Memory Dump, dump file path, and auto-restart):

# 1 = Complete, 2 = Kernel, 3 = Small, 7 = Automatic
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "CrashDumpEnabled" -Value 2

# Set dump file path (dedicate a separate volume for dumps if possible)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "DumpFile" -Value "D:CrashDumpsMEMORY.DMP"

# Overwrite existing dump file with new one
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "Overwrite" -Value 1

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

# Write event to System log
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "LogEvent" -Value 1

Step 2: Ensure Adequate Paging File for Dump Generation

The system paging file on the boot volume must be large enough to hold the initial dump data before it is written to the dump file. For kernel dumps, the paging file should be at least the size of physical RAM. Configure the paging file via PowerShell:

# Disable automatic paging file management
$cs = Get-WmiObject Win32_ComputerSystem
$cs.AutomaticManagedPagefile = $false
$cs.Put()

# Set paging file size (Initial = Current RAM MB, Maximum = RAM + 1024 MB)
$pf = Get-WmiObject Win32_PageFileSetting
if ($pf -eq $null) {
    Set-WmiInstance -Class Win32_PageFileSetting -Arguments @{Name="C:pagefile.sys"; InitialSize=8192; MaximumSize=16384}
} else {
    $pf.InitialSize = 8192
    $pf.MaximumSize = 16384
    $pf.Put()
}

Verify current paging file configuration:

Get-WmiObject Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

Step 3: Configure Application Crash Dumps (WER)

Windows Error Reporting (WER) controls how application crashes are captured. Configure WER to create local application dump files for post-mortem analysis:

# Enable local crash dumps for all applications
$werPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps"
New-Item -Path $werPath -Force | Out-Null
Set-ItemProperty -Path $werPath -Name "DumpFolder" -Value "D:AppCrashDumps" -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

# Create the dump folder
New-Item -Path "D:AppCrashDumps" -ItemType Directory -Force

To configure crash dump settings for a specific application (e.g., w3wp.exe for IIS worker processes):

$appPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumpsw3wp.exe"
New-Item -Path $appPath -Force | Out-Null
Set-ItemProperty -Path $appPath -Name "DumpFolder" -Value "D:AppCrashDumpsIIS" -Type ExpandString
Set-ItemProperty -Path $appPath -Name "DumpType" -Value 2 -Type DWord
Set-ItemProperty -Path $appPath -Name "DumpCount" -Value 5 -Type DWord

Step 4: Use Windows Memory Diagnostic Tool

The Windows Memory Diagnostic tool tests physical RAM for hardware faults. This is particularly useful when investigating intermittent BSODs that may be caused by faulty memory modules.

Schedule a memory test on next reboot:

mdsched.exe

In the dialog, select “Restart now and check for problems” or “Check for problems the next time I start my computer”. On the next boot, the diagnostic runs and logs results to the Windows Event Log (System log, Event ID 1201 for results, source MemoryDiagnostics-Results).

Check memory diagnostic results via PowerShell after the test completes:

Get-WinEvent -LogName System | Where-Object {$_.Id -eq 1201} | Select-Object TimeCreated, Message | Format-List

Step 5: Analyse Crash Dumps with WinDbg

Install Windows Debugging Tools from the Windows SDK and open a kernel dump for analysis. Launch WinDbg with the dump file:

windbg -z D:CrashDumpsMEMORY.DMP

After WinDbg loads the dump, run the automated analysis command:

!analyze -v

This command analyses the crash and outputs the stop code, faulting module name, call stack at the time of crash, and often suggests the root cause. Common commands during dump analysis:

# Show the call stack at the time of crash
k

# Show all threads and their stacks
~*kb

# Show loaded modules
lmv

# Check for driver issues
!drivers

Step 6: Monitor for Crash Indicators

Proactively monitor event logs for warning signs that precede crashes. Schedule a PowerShell script to check for critical events:

# Check for recent BSOD events (Event ID 41 = unexpected shutdown)
Get-WinEvent -LogName System | Where-Object {$_.Id -in @(41, 1001, 6008)} | Select-Object TimeCreated, Id, Message | Format-List

# Check for hardware errors (WHEA events)
Get-WinEvent -LogName "Microsoft-Windows-Kernel-WHEA/Errors" -ErrorAction SilentlyContinue | Select-Object TimeCreated, Message | Format-List

Step 7: Configure Diagnostic Data Collection

Use the built-in Performance Monitor diagnostic templates for automated issue detection. The System Diagnostics Data Collector Set generates a comprehensive HTML report:

# Start the System Diagnostics data collector set (runs for 60 seconds)
logman start "System Diagnostics"
Start-Sleep -Seconds 60
logman stop "System Diagnostics"

# Report is generated in C:PerfLogsSystemDiagnostics
Get-ChildItem "C:PerfLogsSystemDiagnostics" -Recurse -Filter "*.html"

Summary

Properly configured crash dump and diagnostics settings on Windows Server 2012 R2 transform a catastrophic system failure from an unresolvable mystery into a diagnosable event. By setting appropriate dump types, ensuring adequate paging file space, configuring WER for application crash dumps, and using WinDbg for analysis, administrators can identify the root cause of crashes — whether hardware failures, driver bugs, or application defects — and take corrective action. Regular review of system and WHEA event logs provides early warning of developing hardware issues before they cause outages.