How to Use Windows Memory Diagnostic on Windows Server 2012 R2
Memory hardware failures are a common but often overlooked cause of server instability, random crashes, application errors, and data corruption on Windows Server 2012 R2. Unlike many hardware faults that generate clear error messages, memory errors frequently manifest as intermittent, seemingly random BSODs or application failures that are difficult to diagnose without dedicated memory testing. Windows Server 2012 R2 includes the Windows Memory Diagnostic (mdsched.exe) tool, which tests physical RAM for hardware defects using multiple testing passes and algorithms. This guide covers running the built-in diagnostic, interpreting results, performing extended tests, and responding to memory errors detected in production.
Prerequisites
Administrator privileges are required to schedule and run the memory diagnostic. The diagnostic runs during boot, before Windows fully loads, so a scheduled maintenance window should be planned for production servers. For servers running workloads that cannot tolerate downtime, consider hot-add memory alternatives or use the WHEA event log to monitor for in-service memory errors before scheduling a full test reboot. The test duration depends on the amount of installed RAM — expect approximately 10-15 minutes per 8 GB of RAM for the default Standard test.
Step 1: Launch Windows Memory Diagnostic
Launch the Windows Memory Diagnostic from the Run dialog, Start menu, or command line:
mdsched.exeThe tool presents two options: Restart now and check for problems (immediate test — requires reboot confirmation from any active users), or Check for problems the next time I start my computer (schedules the test for the next system restart). For production servers, the scheduled option is preferred as it allows proper planning and notification.
To schedule the test from PowerShell without the GUI dialog:
# Schedule memory diagnostic for next reboot (sets registry flag)
REG ADD "HKLMSYSTEMCurrentControlSetControlSession Manager" /v BootExecute /t REG_MULTI_SZ /d "memtestautocheck autochk *" /f
# Alternative: Use the official scheduling method
Start-Process -FilePath "mdsched.exe" -Verb RunAsStep 2: Configure Test Options During Boot
When the diagnostic boots, press F1 to access test options before the test begins. The available test configurations are:
Basic: Runs MATS+, INVC, and SCHCKR tests. Fastest option, suitable for quick checks. Standard (default): Includes all Basic tests plus LRAND, Stride6, CHCKR3, WMATS+, and WINVC. Covers most common memory failure modes. Recommended for routine checks. Extended: All Standard tests plus MATS+ (cache disabled), Stride38, WSCHCKR, WStride-6, CHCKR4, WCHCKR3, ERAND, Stride6 (cache disabled), CHCKR8. Most thorough testing algorithm set. Recommended when hardware failure is suspected.
Also configurable: Cache option (Default, On, Off) — testing with CPU cache disabled forces the processor to read directly from RAM, detecting errors that cached testing might miss. Pass Count — the number of times to repeat the test algorithm set (default 2, increase to 4+ for suspected failures).
Press F10 to apply settings and start the test with the selected configuration.
Step 3: Monitor Test Progress
During the test, the screen displays:
Current test pass number and total passes. Percentage complete within the current pass. Overall percentage complete. Status field showing “No problems have been detected so far” (or an error if one is found). Test algorithm currently running.
The test runs continuously through all memory addresses. If an error is detected, the test records the memory address, expected value, and actual value. Multiple errors at different addresses suggest widespread RAM failure, while errors at a single address may indicate a single bad memory cell or module.
Step 4: Retrieve Test Results from Event Log
After the test completes, Windows restarts and logs the results to the Windows System event log under source MemoryDiagnostics-Results (Event ID 1201 for no errors, Event ID 1101 for errors detected).
Query the memory diagnostic results via PowerShell:
# Check for Windows Memory Diagnostic results
Get-WinEvent -LogName System | Where-Object {$_.ProviderName -eq "Microsoft-Windows-MemoryDiagnostics-Results"} | Select-Object TimeCreated, Id, Message | Format-List
# Check for specific memory diagnostic event IDs
Get-WinEvent -LogName System | Where-Object {$_.Id -in @(1101, 1201)} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-ListA successful result with no errors produces Event ID 1201 with the message “The Windows Memory Diagnostic tested the computer’s memory and detected no errors.” An error result produces Event ID 1101 with details about the failing memory address range.
Step 5: Monitor for In-Service Memory Errors with WHEA
The Windows Hardware Error Architecture (WHEA) monitors hardware errors in real-time while the server is running and logs correctable and uncorrectable memory errors to the System event log. Check for WHEA memory errors without requiring a reboot:
# Check for WHEA memory errors in event log
Get-WinEvent -LogName System | Where-Object {$_.ProviderName -eq "Microsoft-Windows-WHEA-Logger"} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
# Check the WHEA dedicated error log
Get-WinEvent -LogName "Microsoft-Windows-Kernel-WHEA/Errors" -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-ListWHEA Event ID 18 indicates a correctable hardware error. Frequent correctable errors (more than one per hour) indicate degrading memory that will eventually produce uncorrectable errors. WHEA Event ID 19 indicates an uncorrectable hardware error — this is a critical condition requiring immediate hardware replacement.
Step 6: Create an Automated Memory Error Alert
Set up a Task Scheduler task triggered by WHEA error events to send an immediate alert:
# Create a scheduled task triggered by WHEA Event ID 18 or 19
$trigger = New-ScheduledTaskTrigger -AtLogOn # Placeholder - replace with event trigger
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument @"
-NonInteractive -Command "Send-MailMessage -SmtpServer smtp.yourdomain.com -From [email protected] -To [email protected] -Subject 'MEMORY ERROR on $env:COMPUTERNAME' -Body 'WHEA memory error detected. Immediate investigation required.'"
"@
# Register the task with an event-based trigger via XML
$taskXml = @'
<QueryList><Query Id="0" Path="System"><Select Path="System">*[System[Provider[@Name="Microsoft-Windows-WHEA-Logger"] and (EventID=18 or EventID=19)]]</Select></Query></QueryList>
powershell.exe
-NonInteractive -File C:ScriptsSendMemoryAlert.ps1
'@
$taskXml | Out-File "C:TempMemoryAlertTask.xml" -Encoding Unicode
schtasks /create /tn "WHEA Memory Error Alert" /xml "C:TempMemoryAlertTask.xml" /f /ru SYSTEMStep 7: Interpret Errors and Plan Response
When memory errors are detected, follow this response procedure. First, identify the failing DIMM. Most server hardware platforms include BIOS/UEFI event logs or IPMI/iDRAC/iLO logs that report the specific DIMM slot containing the error. Access these through the server’s management interface.
Verify memory seating as a first step — reseat all DIMMs in their slots, as poor contact due to thermal cycling is a common cause of intermittent memory errors. Retest after reseating. If errors persist after reseating, replace the identified DIMM. For ECC (Error Correcting Code) memory servers, single-bit errors are automatically corrected, but multi-bit errors are uncorrectable and cause immediate server crashes.
# Check server BIOS for hardware event logs (HP iLO example via PowerShell module)
# Get-HPiLOSystemEventLog -Server $iloIP -Username admin -Password (Read-Host -AsSecureString)
# For Dell iDRAC:
# racadm getsel
# For generic IPMI:
# ipmitool sel listSummary
Windows Memory Diagnostic on Windows Server 2012 R2 provides a built-in, zero-cost mechanism for diagnosing RAM hardware failures that cause mysterious crashes and data corruption. The Extended test mode with multiple passes provides thorough coverage of all memory cells and fault modes. Combined with real-time WHEA monitoring for in-service error detection and automated alerting via Task Scheduler event triggers, administrators can detect degrading memory before it causes uncorrectable failures, enabling planned maintenance rather than emergency hardware replacement during an outage.
