# Windows Memory Diagnostic and memtest: from symptom to RMA

> 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 on**

- Build: 26300.9457
- Edition: Pro (26H2)
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## 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:

```powershell
# 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

```powershell
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:

```powershell
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:

1. **Test the sticks one at a time**, in the primary slot.
2. **Test at stock settings** (XMP off). With XMP on you are testing the overclock, not the module.
3. **Test for hours**, not minutes.
4. **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](https://windows.homes/en/hardware/ram/xmp-expo/) |

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).

> **Caution: Never “fix” it by lowering the speed**
>
> Dropping memory speed can hide a marginal fault instead of fixing it. If stock settings are unstable, that is a fault — lowering speed is a workaround for a machine you are about to replace or RMA.

## Step 6: after the replacement

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

## Related

- [ECC and WHEA](https://windows.homes/en/hardware/ram/ecc-whea/)
- [Memory compression and page file](https://windows.homes/en/hardware/ram/compression-pagefile/)
- [Hardware failure evidence](https://windows.homes/en/hardware/)

## 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.

## Sources

- [Microsoft Learn — WHEA reference](https://learn.microsoft.com/en-us/windows-hardware/drivers/whea/)
- [Microsoft Learn — Win32_PhysicalMemory](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-physicalmemory)
- [Microsoft Learn — Win32_PageFileSetting](https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-pagefilesetting)

---

Source: https://windows.homes/en/hardware/ram/diagnostics/