Use Windows Memory Diagnostic to Test RAM — Historical Guide
Run Windows Memory Diagnostic, find the matching result, and distinguish errors, a clean test and an incomplete run before replacing RAM.
- 5 min read
- 5 steps
View article illustration

Windows Memory Diagnostic tests memory outside your normal Windows session. The useful outcome is a recorded result from a completed run—not simply that the PC restarted. An error needs investigation; a clean run does not rule out every intermittent hardware problem.
This guide retains its Windows 7/Vista-era context. The tool also appears in current Microsoft documentation, but recovery menus and result-log locations can differ. Use the controls actually present on your installation rather than assuming a newer screenshot matches it.
1. Prepare for a restart and record the symptom
Save your work, close applications and arrange time when the computer can be unavailable. Back up important files while the system is usable. Use reliable power; for a laptop, connect its normal charger. If drive encryption is enabled, make sure you can retrieve the recovery key before diagnostic or recovery work. Do not disable encryption to run this test.
Write down the Windows version, PC model, installed RAM, recent memory changes and the symptom you are investigating. “Crashes during a particular game” is more useful than “slow PC”. A slow computer alone does not establish defective RAM, and this test does not repair damaged files or free storage space.
2. Run a standard test first
- Open Start and search for Windows Memory Diagnostic. Alternatively, press Win + R, enter
mdsched, and press Enter. - Choose the immediate restart only after saving your work. The alternative schedules the check for the next restart; scheduling is not the same as completing a test.
- Allow the pre-boot test to run. Record any displayed hardware-error message and whether the run finishes.
- After Windows returns, sign in and check the result. Keep the approximate start and finish times so you can distinguish this run from an old one.
Microsoft documents Standard as the default test. On the diagnostic screen, F1 opens options and F10 applies them; Extended takes longer. Start with the defaults so you have a reproducible baseline. If you later change the test mix, cache behavior or pass count, record those choices with the new result instead of treating the runs as identical.
No fixed completion time fits every memory size and test selection. A prolonged percentage display is not, by itself, a diagnosis. If the computer repeatedly freezes or restarts before completing the test, record that as an incomplete run and ask the PC maker about its supported hardware diagnostics.
3. Retrieve the result, not just the notification
A result notification may appear after sign-in. If you miss it, open Event Viewer and look for the event matching your test time. NZXT's documented Windows workflow uses Windows Logs > System and the source MemoryDiagnostics-Results. Use Find or the source filter, then read the message and timestamp together.
Microsoft's current troubleshooting page instead documents a MemoryDiagnostics-Results > Debug channel beneath Applications and Services Logs > Microsoft > Windows. Check that location if it exists on your version. These are version-dependent retrieval routes, not a reason to turn on unrelated diagnostic logs or copy a newer event ID into an older guide.
Record the event's source, log, time and complete result message. An Information-level event is not automatically a pass: read what the message says. If no matching result is present, do not treat an older clean event as evidence for today's run. NZXT also notes that results may be unavailable after a recovery-environment test.
4. Interpret the evidence before replacing parts
| Observation | What you know | Next useful action |
|---|---|---|
| Completed test reports no errors | That run did not detect errors under its settings. | Retest the original workload. Keep investigating if the symptom remains; do not declare the whole PC healthy. |
| Test reports hardware or memory errors | The memory subsystem needs investigation. | Save the result and contact the PC or RAM supplier with the configuration. The result alone does not identify a particular module or slot. |
| No new result can be found | The run is not verified from the available record. | Check the time, log location and whether the test actually completed. Preserve any on-screen message. |
| Test freezes or the PC restarts during it | You have an interrupted diagnostic, not a clean pass. | Record where it stopped and use model-specific hardware support before repeatedly forcing tests. |
| Crashes continue despite a clean run | This test has not explained the original failure. | Compare the crash timing and recent hardware/software changes; further targeted diagnosis may be needed. |
Illustrative record: “Standard test completed at 14:20; matching event reports no errors; the same application still crashes at 14:45.” The useful conclusion is that the observed crash remains unexplained, not that RAM has been proved fault-free. This is a hypothetical example, not a test result from our equipment.
5. Escalate with a useful record
Keep these fields together: PC/Windows version → memory configuration and recent changes → original symptom → test settings → completion time → exact result → symptom after restart. Redact computer/user identifiers before posting an event publicly. Give private device identifiers only through the manufacturer's support channel when needed.
If Windows will not start, follow the model's supported recovery or pre-boot diagnostic instructions. Older Windows recovery media may offer memory diagnostics, but a particular F-key or recovery menu is not universal. Do not reinstall Windows just to obtain a memory test.
Do not remove modules or change firmware timings as an automatic next step. Component isolation depends on the service manual, supported memory layout and whether the RAM is replaceable. For a managed, sealed or soldered-memory system, involve its administrator or manufacturer. Preserve a failing result before changing the configuration so a technician can compare it with later tests.
Documentation review: 27 October 2026. Based on Microsoft and NZXT instructions, with an editorial decision table and explicitly hypothetical record. No RAM fault was reproduced or repaired for this review. Legacy Windows interfaces are retained as historical context.


