Full Diagnostic Tree & Step-by-Step Overview
What specific behavior or error pattern occurred during your MemTest86 execution?
- MemTest86 throws hundreds of errors immediately across multiple test algorithms
- Errors occur sporadically only during specific tests (e.g., Test 6 Block Move or Test 13 Hammer Test)
- Errors only appear when XMP / EXPO memory overclock profiles are enabled in UEFI
- MemTest86 freezes, reboots, or fails to initialize before completing a full pass
How are the physical RAM modules installed across your motherboard's DIMM slots?
- Multiple modules installed in a dual-channel configuration (e.g., Slots A2 and B2)
- Errors persist even when testing a single RAM module in a designated primary slot
- Errors move to different memory address ranges when shifting the same stick to another slot
Isolate Faulty Physical DIMM Module via Single-Stick Elimination
Solution:
Root Cause: Physical Semiconductor Cell Degradation or Silicon Defect
When MemTest86 outputs thousands of bit flip errors immediately upon test initialization, one or more dynamic random-access memory (DRAM) chips on a physical DIMM module have suffered permanent hardware degradation. A single failing memory cell causes data corruption across entire address ranges when the memory controller reads or writes bit patterns (e.g., 0x55555555 or 0xAAAAAAAA).
# Diagnostic Verification:
1. Boot into the MemTest86 UEFI interface.
2. Review the Summary Screen or inspect the generated MemTest86.log saved to the bootable USB drive.
3. Note the failing CPU Channel and Bits in Error field.
4. Power down the system completely and remove all RAM modules except one stick seated in primary slot A2 (or the vendor-recommended single-stick slot).
# Step-by-Step Fix:
1. Execute Single-Stick Isolation Loop:
Run MemTest86 (Pass 1 through Pass 4) on Stick #1 alone in Slot A2.If Stick #1 passes 4 complete passes without errors, remove it and label it as Healthy.Insert Stick #2 into Slot A2 and re-test. If Stick #2 generates errors, it is physically defective.2. Verify Secondary Channels:
Repeat this single-stick verification process for all remaining modules in your memory kit.3. Replace Defective Module / Kit:
Replace the failing module. If the RAM was purchased as a multi-channel matched kit, initiate an RMA for the entire matched set to ensure identical DRAM die revisions (e.g., SK Hynix A-die vs. Samsung B-die).# Prevention & Long-Term Monitoring:
Handle unshielded memory modules using anti-static wrist straps to prevent Electrostatic Discharge (ESD) damage.Avoid mixing different RAM kits, even if they share identical rated clock speeds and primary timings.
Decommission Defective Memory Module (Permanent Hardware Failure)
Solution:
Root Cause: Severe DRAM Physical Gate Failure or Substrate Fault
Errors occurring on a single memory module across all physical slots confirm an unrecoverable hardware fault within the module's printed circuit board (PCB), integrated power management IC (PMIC on DDR5), or discrete DRAM silicon dies. Software adjustments, timing alterations, or voltage increases cannot restore damaged physical storage capacitors.
# Diagnostic Verification:
1. Confirm that the module fails MemTest86 in multiple independent motherboard slots (e.g., Slot A2 and Slot B2).
2. Review the MemTest86 error log to confirm consistent failure patterns across different test algorithms (e.g., Test 3 [Address test, own address] and Test 4 [Moving inversions, 8-bit pattern]).
# Step-by-Step Fix:
1. Extract Technical Specifications for Replacement:
Document the module part number, voltage rating (e.g., 1.35V or 1.4V), rated speed (e.g., DDR5-6000 MT/s), and primary CAS Latency (CL) specs.2. Process Vendor Warranty / RMA:
Submit a warranty replacement claim through official vendor documentation channels, such as the PassMark MemTest86 Official Documentation and your memory manufacturer's RMA portal.Provide the raw HTML/PDF diagnostic report generated automatically by MemTest86 as proof of hardware failure.3. Install Matching Hardware:
Install a verified replacement module that matches the motherboard's Qualified Vendor List (QVL).# Prevention & Long-Term Monitoring:
Maintain adequate chassis intake airflow to prevent physical heat degradation of DRAM components.
Diagnose Motherboard DIMM Socket Damage or Socket Pin Bends
Solution:
Root Cause: Motherboard Trace Corruption or CPU Socket Pin Misalignment
When a single, healthy RAM stick passes MemTest86 in Slot A2 but generates errors when moved to Slot B1 or B2, the failure is located on the motherboard or CPU socket interface rather than the RAM module itself. Bent CPU socket pins (LGA) or damaged socket contacts interrupt the direct trace lines connecting the Integrated Memory Controller (IMC) inside the CPU package to the physical DIMM slots.
# Diagnostic Verification:
1. Insert a known-good RAM module into the suspect DIMM slot.
2. Execute MemTest86. Note if errors occur systematically on specific data lines (e.g., Bit 16 or Bit 32).
3. Power down, remove the CPU cooler, and unseat the CPU from the socket.
# Step-by-Step Fix:
1. Inspect CPU Socket Pins:
Use a magnifying glass and strong lighting to inspect the motherboard CPU socket pins for bends, misalignment, or thermal paste contamination.2. Inspect CPU Contact Pads:
Clean the gold contact pads on the underside of the CPU using 99% Isopropyl Alcohol and a lint-free microfiber cloth.3. Correct CPU Cooler Mounting Pressure:
Re-seat the CPU and torque the cooler mounting screws in a cross-pattern to equal tension. Over-tightening the CPU cooler can bow the PCB, severing trace contact with specific DIMM channels.4. Re-test DIMM Slots in MemTest86:
Re-run MemTest86 to verify that channel communication is restored.# Prevention & Long-Term Monitoring:
Always use a torque-limiting driver or manufacturer-recommended turn limits when mounting heavy CPU cooling assemblies.
Which specific MemTest86 test pattern triggers the intermittent error?
- Test 6 [Block Move, 64-bit] or Test 7 [Moving Inversions, 32-bit Pattern]
- Test 13 [Hammer Test / Rowhammer Bit Flips]
Fix Signal Integrity & Memory Bus Timing Drift (Test 6 / 7 Failures)
Solution:
Root Cause: Memory Bus Signal Degradation and Sub-Timing Instability
Failures isolated to Test 6 (Block Move) or Test 7 indicate signal integrity degradation across the memory bus during sustained block transfers. When large blocks of data are shifted rapidly through memory buffers, tight secondary or tertiary timings (such as tRFC, tREFI, or tFAW) cause signal crosstalk, clock skew, or inadequate capacitor refresh cycles.
# Diagnostic Verification:
1. Run MemTest86 and navigate to the Test Selection screen.
2. Deselect all tests except Test 6 and Test 7.
3. Execute 4 consecutive passes to confirm repeatable errors on block movement routines.
# Step-by-Step Fix:
1. Loosen Primary & Secondary Timings in UEFI:
Boot into your motherboard BIOS/UEFI setup menu.Navigate to DRAM Timing Control.Increase tRFC (Refresh Cycle Time) by 30–50 clocks (e.g., from 480 to 530).Decrease tREFI (Refresh Interval) to increase refresh frequency (e.g., lower from 65535 to 32768).2. Adjust Command Rate / Gear Mode:
Change Command Rate from 1T to 2T (or N=2).For high-frequency DDR5, switch memory controller gear mode from Gear 1 to Gear 2 (or 1:2 mode).3. Re-test via MemTest86:
Save BIOS settings and re-run Test 6 to verify that block transfer errors are eliminated.# Prevention & Long-Term Monitoring:
Avoid aggressive auto-tuning features provided by third-party motherboard desktop utilities, which often tighten tRFC dangerously past stability limits.
Mitigate Rowhammer Bit Flips via Refresh Rate & Target Row Refresh (TRR)
Solution:
Root Cause: Electromagnetic Leakage between Adjacent DRAM Storage Cells
Test 13 (Hammer Test) evaluates vulnerability to the Rowhammer effect. By repeatedly accessing (hammering) a specific row of DRAM cells at high frequencies, electrical charges leak into adjacent rows, flipping their bit states (from 1 to 0 or vice versa). While single bit-flips in Test 13 rarely cause immediate OS crashes, they indicate high sensitivity to memory-intensive workloads.
# Diagnostic Verification:
1. Review the MemTest86 report. Check if errors are localized exclusively to Test 13 while Tests 1 through 12 complete with zero errors.
2. Note the target address and bit mask of the flipped bits.
# Step-by-Step Fix:
1. Enable Target Row Refresh (TRR) / pTRR in UEFI:
Boot into BIOS/UEFI and navigate to Advanced Memory Settings.Ensure Target Row Refresh (TRR) or Hardware TRR is set to Enabled.2. Double the DRAM Refresh Rate (2x Refresh Mode):
Locate the tREFI setting or Refresh Rate option in BIOS.Select 2x Refresh (or halve the tREFI numerical value) to charge memory cells twice as frequently, shortening the window for charge leakage.3. Improve Chassis Active Cooling:
High DRAM operating temperatures exacerbate electrical charge leakage. Install or adjust a fan to blow direct airflow across the memory heatsinks.# Prevention & Long-Term Monitoring:
For enterprise server environments or mission-critical workstations, deploy Error-Correcting Code (ECC) memory modules to detect and correct single-bit Rowhammer flips automatically.
Which memory overclock profile type is currently active in your UEFI/BIOS?
- Intel XMP (Extreme Memory Profile) enabled on Intel or AMD platform
- AMD EXPO (Extended Profiles for Overclocking) enabled on AM5 platform
- Manual clock speed and voltage settings manually keyed into BIOS
Calibrate Intel XMP System Agent (VCCSA) & VDDQ Voltages
Solution:
Root Cause: Integrated Memory Controller (IMC) Undervoltage under XMP
Enabling Intel XMP automatically applies the RAM kit's rated frequency, primary timings, and DRAM voltage. However, XMP profiles do not always adjust the motherboard's internal Integrated Memory Controller (IMC) voltages (such as VCCSA / VDD_IMC). When running high-frequency kits (e.g., DDR5-6400+ or DDR4-3600+), default auto voltages result in signal jitter, bit drops, and instant MemTest86 failures.
# Diagnostic Verification:
1. Boot into BIOS/UEFI and confirm XMP Profile 1 is active.
2. Note the default automatic voltages assigned to VCCSA (System Agent) and VDDQ_CPU.
# Step-by-Step Fix:
1. Manually Calibrate Controller Voltages:
Navigate to Extreme Tweaker / OC Overclocking in BIOS.Set VCCSA (System Agent Voltage) manually to 1.20V – 1.25V (for DDR4) or 1.25V – 1.30V (for DDR5).Set VDD_IMC / CPU VDDQ to 1.25V – 1.35V depending on frequency requirements.2. Increment DRAM Voltage:
Increase the main VDD / VDDQ voltage by 0.02V above the XMP rating (e.g., shift from 1.35V to 1.37V).3. Re-evaluate via MemTest86:
Save changes, reboot into MemTest86, and run a complete 4-pass diagnostic sweep.# Prevention & Long-Term Monitoring:
Consult your motherboard manufacturer's Qualified Vendor List (QVL) before purchasing high-frequency XMP kits to confirm supported IMC speed thresholds.
Tune AMD EXPO Fabric Clock (FCLK) & VDDCR_SOC Voltages
Solution:
Root Cause: Infinity Fabric / Memory Controller Asynchronous Misalignment
On AMD Socket AM5 platforms, EXPO profiles configure both the memory clock (MCLK), memory controller clock (UCLK), and Infinity Fabric clock (FCLK). If the FCLK and UCLK ratio becomes unstable (e.g., attempting to run a 1:1 ratio at 6400 MT/s without adequate SOC voltage), the internal bus suffers sync errors that trigger MemTest86 faults.
# Diagnostic Verification:
1. Boot into BIOS and verify EXPO I or EXPO II is active.
2. Check current VSOC (VDDCR_SOC) voltage settings in BIOS health monitoring.
# Step-by-Step Fix:
1. Lock VSOC (VDDCR_SOC) Voltage Safely:
Set VDDCR_SOC manually to 1.20V or 1.25V (Do NOT exceed 1.30V on AM5 platforms to avoid physical processor degradation).2. Enforce 1:1 UCLK:MCLK Ratio:
Set UCLK DIV1 MODE to UCLK = MCLK.Set FCLK Frequency manually to 2000 MHz (for DDR5-6000) or 2100 MHz (for DDR5-6200).3. Reduce Frequency by One Step if Errors Persist:
If errors continue in MemTest86, drop the memory target speed from 6000 MT/s to 5800 MT/s while retaining EXPO timings.# Prevention & Long-Term Monitoring:
Keep your motherboard BIOS updated to the latest AGESA microcode release to benefit from memory training and stability improvements.
Reset JEDEC Baseline & Clear Manual Overclock Parameters
Solution:
Root Cause: Unstable Manual Sub-Timings or Out-of-Spec Sub-System Voltages
Manual memory tuning involves adjusting dozens of primary, secondary, and tertiary timing parameters. Setting values below silicon capabilities causes severe memory corruption, thread crashes, and multi-pass failures in MemTest86.
# Diagnostic Verification:
1. Check BIOS settings to confirm manual timing registers or custom clock dividers are applied.
2. Observe MemTest86 throwing failures instantly across multiple test passes.
# Step-by-Step Fix:
1. Reset UEFI/BIOS to Factory Defaults:
Reboot into BIOS, press F5 (Load Optimized Defaults), and save changes.Alternatively, clear the CMOS by shorting the CLR_CMOS jumper pins or removing the CR2032 coin cell battery for 5 minutes.2. Test Baseline JEDEC Specifications:
Boot MemTest86 with RAM operating at native JEDEC profile speeds (e.g., DDR4-2133 / DDR5-4800 at 1.1V / 1.2V).Complete 4 full passes of MemTest86.3. Incremental Overclock Re-tuning:
Enable stock XMP/EXPO profiles first before making minor manual timing adjustments. Change only one primary timing parameter at a time and re-test stability.# Prevention & Long-Term Monitoring:
Save known-stable BIOS profiles to a USB flash drive before attempting manual memory tuning.
What specific system failure occurs when attempting to launch MemTest86?
- MemTest86 freezes or reboots immediately during multi-threaded CPU testing
- MemTest86 fails to boot, displaying Secure Boot or UEFI binary validation errors
Switch MemTest86 CPU Multithreading Mode to Single-CPU / Parallel
Solution:
Root Cause: UEFI MP (Multi-Processor) Services Protocol Incompatibility
During default execution, MemTest86 uses the UEFI Multi-Processor (MP) Services protocol to test memory concurrently across all available CPU cores and threads. On certain motherboard platforms, buggy UEFI microcode implementations cause core synchronization lockups, resulting in system freezes, black screens, or instant reboots during CPU thread switching.
# Diagnostic Verification:
1. Boot into MemTest86.
2. Observe if the system hangs or reboots precisely when transitioning to multi-core testing modes.
# Step-by-Step Fix:
1. Access Configuration Menu before Test Start:
Press C or click Configuration on the main MemTest86 splash screen.2. Modify CPU Test Selection Mode:
Select CPU Selection Mode.Change the setting from Parallel / Multithreaded to Single or Round Robin.3. Execute Diagnostic Test Sweep:
Start the test. In Single CPU mode, MemTest86 runs on a single core, bypassing buggy UEFI MP thread calls entirely while continuing to test the physical RAM cells.# Prevention & Long-Term Monitoring:
Flash the latest motherboard BIOS update to fix underlying UEFI MP Services protocol bugs.
Configure Secure Boot Certificates for MemTest86 UEFI Execution
Solution:
Root Cause: Secure Boot Public Key Infrastructure (PKI) Validation Failure
MemTest86 is a standalone 64-bit UEFI application (BOOTX64.EFI). While modern versions of MemTest86 are signed with a Microsoft UEFI Third-Party Marketplace CA certificate, custom secure boot policies, outdated motherboard PKI databases, or older MemTest86 releases trigger Secure Boot execution blocks, preventing the image from loading.
# Diagnostic Verification:
1. Select the MemTest86 USB drive from the UEFI Boot Menu (F11 / F12).
2. Observe the system screen displaying Secure Boot Violation, Invalid Signature Detected, or immediately returning to the BIOS setup screen.
# Step-by-Step Fix:
1. Disable Secure Boot Temporarily in UEFI Setup:
Enter BIOS setup (Del / F2).Navigate to the Security or Boot tab -> Secure Boot.Change Secure Boot Mode from Enabled to Disabled (or switch OS Type from Windows UEFI to Other OS).2. Update MemTest86 Boot Media:
Download the latest release of MemTest86 Free/Pro directly from PassMark and re-image the USB drive using ImageUSB to ensure valid binary signing.3. Enable 'Allow Microsoft 3rd Party UEFI CA' in BIOS:
On modern motherboards, enable the option labeled Allow Microsoft 3rd Party UEFI CA under Secure Boot key management, then re-enable Secure Boot.# Prevention & Long-Term Monitoring:
Re-enable Secure Boot before booting back into Windows to preserve system integrity security features like BitLocker and Credential Guard.