Windows Memory Diagnostic and memtest: from symptom to RMA

Verified 2026-10-293 min read

Run mdsched, read the result from Event Viewer, then decide whether one pass is enough or you need MemTest86 — and how to isolate the module, slot or CPU memory controller.

Tested onPro (26H2) · Build 26300.9457 · x64

Build: 26300.9457
Edition: Pro (26H2)
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Troubleshoot

The short answer

Bad memory rarely announces itself. It shows up as random failures that move around:

different bugcheck codes each time (0x1A, 0x50, 0x3B, 0x124);
applications crashing in different DLLs;
installers failing with checksum errors;
files that corrupt silently.

The method is: prove it is memory, isolate which module, then decide module vs slot vs CPU.

Step 1: rule out the easy impostors

Before blaming the DIMMs, check the things that look identical:

# storage errors look like memory errors
Get-PhysicalDisk | Select-Object FriendlyName,HealthStatus,OperationalStatus
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='disk','Ntfs','volmgr'} -MaxEvents 20 |
  Select-Object TimeCreated,ProviderName,Id,LevelDisplayName

# driver-level and firmware events
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 20 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

A failing SSD with bad sectors produces checksum failures and bugchecks that look exactly like bad RAM. Check SMART first — it is faster than a memory test.

Step 2: reproduce on purpose

Memory faults are load- and temperature-dependent. A machine that passes at idle can fail after an hour of real work.

Use a workload that touches a lot of memory:

a large compile or archive extraction;
a virtual machine with a fixed RAM allocation;
a memory tester with several passes.

Record what you were doing and how long it took to fail. A fault that appears in three minutes after boot is a different class of problem from one that appears after four hours.

Step 3: test memory properly

Two options:

In-Windows test (fast, less trustworthy): the Windows Memory Diagnostic schedules a test on the next boot. Convenient, but it uses the running OS’s memory map.
Bootable tester (slow, trustworthy): run several full passes overnight. One pass is not a verdict.

Running Windows Memory Diagnostic and reading the log

mdsched.exe

Choose Restart now, or schedule it for the next start. The test runs outside Windows, in a pre-boot environment with no drivers competing for memory — which is why it beats any in-OS checker.

The result is written to the System log on the next boot:

Get-WinEvent -LogName System -MaxEvents 500 |
  Where-Object { $_.ProviderName -match 'MemoryDiagnostic' } |
  Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List

Event ID	Meaning
1201	test completed and found errors
1101	test started / configuration recorded

A pass produces no 1201 event at all. There is no “no errors found” message to look for — absence of the error event is the result. Most guides get this backwards.

What one pass does not prove: marginal cells that only fail under repeated access, an unstable XMP/EXPO profile (the test runs at defaults), faults that need heat, or which DIMM is at fault. That is why Step 3 continues with a bootable tester.

Test rules that make the result meaningful:

Test the sticks one at a time, in the primary slot.
Test at stock settings (XMP off). With XMP on you are testing the overclock, not the module.
Test for hours, not minutes.
Record errors verbatim — address, test name, pass number.

Step 4: isolate the component

Result	Conclusion
Errors on one module in any slot	Module is faulty — replace
Errors only in one slot, any module	Slot or board trace — test another board if possible
Errors everywhere, all modules	CPU memory controller, firmware, or power delivery
Errors only with all slots populated	Memory controller load/rank limit; reduce population or lower speed
Errors only with XMP on	Profile not stable on this platform — see XMP

Before replacing hardware, update the firmware. Memory training and compatibility fixes ship in BIOS/UEFI updates more often than people expect.

Step 5: what evidence to keep for an RMA

Warranty departments reject vague claims. Keep:

the exact failure (bugcheck code, event log entries, screenshots);
the memory test log (passes, error addresses);
the configuration at failure (speed, slots, XMP state);
the module part numbers and serial numbers;
what you already ruled out (SSD, PSU, drivers).

Step 6: after the replacement

Test the new module alone, stock settings, several passes.
Add the other modules back one at a time.
Re-enable XMP only if you actually need it, and re-run the verification.
Watch WHEA for a week.

Lab boundary

E1. The procedure is standard practice documented by Microsoft (WHEA, memory diagnostics) and platform vendors. The lab cannot inject memory faults into a VM, so no failing module was reproduced here.