Memory validation
How to test mixed RAM on Ryzen with Memtest86+
Test mixed RAM on Ryzen with Memtest86+: record settings and selected tests, save passes and errors, then investigate instability one change at a time.
Keep settings, test results and logs as separate evidence.
Name the configurationRecord DIMMs, slots, firmware and memory settings.
Preserve the test scopeKeep selected tests, range, passes and errors together.
Investigate and repeatChange one factor and record a new observation.
Your plan, at a glance.
THE LAB BRIEF
The short answer.
Record your RAM settings, run Memtest86+, save its selected tests, passes and errors, then test your normal workload. If errors appear, return to defaults and isolate one change at a time before blaming a DIMM.
- ConfigurationRecord before changing
- Pass countSelected tests matter
- Keep the reportSettings, passes, errors
Your Ryzen box boots. Great—now make the RAM earn its keep. Record its settings, run Memtest86+, save the result and put your normal workload through its paces. Keep configured speed, kernel logs and dedicated memory-test results as separate checks.
This procedure follows official Memtest86+ and Linux documentation checked on October 19, 2026; the mixed-RAM article supplies the recorded kernel-log observation.
Decide what each observation can show
Keep the following records separate. They answer related questions, but combining their labels can overstate what was actually tested.
| Evidence record | What it describes | Pair it with |
|---|---|---|
| Firmware/OS speed report | The reported memory configuration | A dedicated memory test |
| Kernel error log | Events exposed through the enabled reporting path | A tester that exercises memory patterns |
| Memtest86+ result | Selected tests and address range under recorded settings | Component isolation and your normal workload |
| Application workload record | Behaviour during that named workload and interval | The dedicated tester’s selected patterns |
These boundaries follow the Memtest86+ testing documentation and the kernel’s EDAC overview. Keep those records together when you compare configurations.
If you are buying RAM for a memory-integrity requirement, our ECC RAM buying and platform guide compares exact DDR4 and DDR5 ECC UDIMMs with platform-support checks. Verify active ECC separately from the memory-test result.
Record the configuration before changing it
Before you boot the tester, write down:
- CPU, motherboard model and revision, and firmware version.
- DIMM models, capacities and physical slot placement.
- Selected memory profile and the speed, timings and voltage reported or configured; distinguish a reported value from a physical measurement.
- Memtest86+ version, boot method, selected tests, address range and CPU sequencing mode.
- Date, elapsed observation time, completed passes, errors and any interruption or configuration change.
This makes the result repeatable and keeps a later run from inheriting the wrong label. A kit moved to different slots or combined with another kit is a changed configuration. Use the board documentation for supported placement rather than transferring a slot recommendation from another motherboard.
The 5600G versus 5600X platform guide makes the same point about CPU and firmware compatibility: match the exact CPU, board and firmware before carrying a result to another configuration.
Prepare the official standalone tester
Use the Memtest86+ project for the current installer or image and its platform-specific boot instructions. Memtest86+ is a separate project from PassMark’s Memtest86; keep the selected tool and its instructions together.
At the check date, the project lists v9.00, released October 15, 2026. Its EFI signing uses project trust, with Microsoft signing not yet provided. Follow the project’s Secure Boot trust instructions for your release and machine.
Prepare a spare USB medium with the appropriate official installer/image method, then use the board’s boot-selection procedure. Once it starts, record the configuration and selected tests.
Read passes in the context of the selected tests
The project README defines a completed pass around the selected tests. It also explains that changing selected tests, address range or CPU sequencing starts a new sequence and resets error statistics. Preserve the existing record before changing those controls.
A pass count is meaningful alongside that scope. A run limited to an address range should not be described as coverage of every installed memory location. Likewise, different test selections should remain distinguishable in the record.
Pass duration varies with CPU speed, memory speed and capacity; the project advises longer testing when you suspect intermittent errors. Record the completed passes and why you stopped.
For v9.00, the project page documents F6 text-report saving to a FAT32 USB drive. Save the report alongside your configuration and selected-test record, following the instructions for your version.
Investigate an error without declaring a DIMM faulty
A reported mismatch needs investigation. The README’s troubleshooting section explains that the test also exercises CPU, caches and motherboard, and cannot uniquely determine the failing component. It also describes combinations that fail together even when a module works in another system.
Preserve the report before changing settings or parts. If the configuration is overclocked, the project FAQ recommends trying defaults; it then discusses removing or rotating modules to narrow the problem. Apply that advice with the board’s supported DIMM placement and hardware-handling procedure.
Keep each resulting configuration as its own observation. Record which modules and slots were present when the test reported errors and when it did not. Changing a profile and moving several modules together makes a result harder to interpret. Use your kit and board documentation for settings, then change one factor at a time.
Use kernel logs as complementary evidence
The Linux RAS documentation describes EDAC’s hardware-error reporting, including correctable and uncorrectable memory events, through a core and memory-controller drivers. Check which reporting driver your configuration actually uses.
Record the reporting support and observation window before interpreting a quiet log. Save the observation window with the log, and keep the tester’s selected tests, range and passes beside it.
After dedicated testing, return to the intended OS workload and observe its behaviour and relevant logs. Keep that workload record alongside the memory-test report. A crash or other symptom still requires investigation even if selected memory tests completed without reported errors.
Retest the configuration that changed
A useful validation record names the configuration, test scope and result, plus what remains unverified. When firmware, memory profiles, DIMMs or slot placement change, create a new record and repeat the checks relevant to that change.
Save a new report whenever the configuration changes, then finish with your normal workload and its logs.
Sources & methodology
Where these facts come from.
- Memtest86+ — official releases, reports and boot FAQ · checked October 19, 2026
- Memtest86+ — operation, test scope and troubleshooting · checked October 19, 2026
- Linux kernel — EDAC purpose and reporting architecture · checked October 19, 2026
- Earlier bench article — dedicated-tester evidence limit · checked October 19, 2026
Source dates are listed above.
Prepared by Racks & Watts.