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

When a Windows Server 2016 system experiences a kernel-mode crash, also known as a Blue Screen of Death or Bug Check, the operating system can be configured to capture diagnostic information in the form of a memory dump file. Analyzing this dump file allows engineers to identify the root cause of the crash, whether it is a faulty device driver, a hardware memory error, a kernel deadlock, or a third-party software defect. This guide explains how to configure memory dump settings, enable kernel crash diagnostics, analyze dump files using the Windows Debugger, and set up automatic event-driven diagnostics using the built-in Windows diagnostics infrastructure.

Proper dump configuration requires sufficient free disk space on the system drive or a configured dump target volume. A complete memory dump of a server with 64 GB of RAM requires at least 64 GB of free space. A kernel memory dump is more practical for most scenarios as it captures only kernel-mode memory, which typically ranges from 256 MB to a few gigabytes regardless of total RAM.

Step 1: Configure Crash Dump Settings via System Properties

Open an elevated PowerShell window and launch the System Properties dialog directly:

Start-Process "SystemPropertiesAdvanced.exe"

In the Advanced tab, click Settings under Startup and Recovery. Under Write debugging information, select from the available dump types: Small memory dump (256 KB) captures minimal information and is useful for crash pattern analysis; Kernel memory dump captures all kernel-mode memory and is the best balance of detail and size; Complete memory dump captures all physical RAM and is required for the most thorough analysis. Set the dump file path to a volume with sufficient free space, such as D:CrashDumpsMEMORY.DMP. Ensure Overwrite any existing file is checked to prevent disk exhaustion.

Step 2: Configure Dump Settings via Registry

You can also configure crash dump settings programmatically through the registry, which is useful for automating the configuration across multiple servers:

$regPath = "HKLM:SYSTEMCurrentControlSetControlCrashControl"
Set-ItemProperty -Path $regPath -Name "CrashDumpEnabled" -Value 2  # 2 = Kernel dump
Set-ItemProperty -Path $regPath -Name "DumpFile"         -Value "D:CrashDumpsMEMORY.DMP"
Set-ItemProperty -Path $regPath -Name "AutoReboot"       -Value 1
Set-ItemProperty -Path $regPath -Name "Overwrite"        -Value 1

CrashDumpEnabled values: 0 = None, 1 = Complete dump, 2 = Kernel dump, 3 = Small dump, 7 = Automatic (OS chooses).

Step 3: Verify Page File Configuration

Windows requires a page file on the system drive to hold the crash dump temporarily before writing it to the configured dump file path. Verify that a system-managed or adequately sized page file exists:

Get-WmiObject -Class Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize

If no page file is returned or the maximum size is too small for a kernel dump, configure one:

$cs = Get-WmiObject -Class Win32_ComputerSystem
$cs.AutomaticManagedPagefile = $true
$cs.Put()

Step 4: Enable the Windows Error Reporting Service

Windows Error Reporting collects application crash data and can submit it to Microsoft for analysis or to a custom corporate symbol server. Ensure the service is running and configured appropriately:

Set-Service -Name "WerSvc" -StartupType Automatic
Start-Service -Name "WerSvc"

Configure WER to store local crash data in a custom path via Group Policy under Computer Configuration, Administrative Templates, Windows Components, Windows Error Reporting, Configure Default Consent.

Step 5: Enable Application Verifier for Driver Diagnostics

Application Verifier and Driver Verifier are built-in tools that stress-test drivers and applications by enabling additional runtime checks. Enable Driver Verifier for suspect third-party drivers from an elevated command prompt:

verifier /standard /driver SuspectDriver.sys

Warning: Driver Verifier significantly increases the likelihood of a bug check if the targeted driver has issues. Only enable it in a controlled diagnostic session, not on production servers unless directed by the driver vendor or Microsoft support. Disable it after the diagnostic session:

verifier /reset

Step 6: Analyze a Dump File with WinDbg

Download the Windows Debugger (WinDbg) from the Windows SDK. Open a crash dump by running the following from the WinDbg command line after configuring the Microsoft public symbol server:

windbg -z D:CrashDumpsMEMORY.DMP -y srv*C:Symbols*https://msdl.microsoft.com/download/symbols

Once the dump is loaded, run the automated analysis command:

!analyze -v

The output identifies the Bug Check code, the faulting module, the call stack at the time of the crash, and suggested next steps. The FOLLOWUP_MODULE field in the output typically points to the driver or component responsible for the crash.

Step 7: Configure Automatic Memory Diagnostics

Enable the Windows Memory Diagnostics tool to run automatically at next boot to check for hardware RAM errors:

mdsched.exe

Select Restart now and check for problems. After the server reboots, the memory test runs before Windows loads. Results are recorded in Event Viewer under Windows Logs, System with source MemoryDiagnostics-Results. If errors are found, replace the faulty DIMM before continuing to use the server.

Properly configured crash dump and diagnostics settings transform an unexpected server crash from an unresolved mystery into a traceable, diagnosable event that your team can resolve systematically.