Reseating RAM Stopped Repeated, Corrupted Blue Screens on an RX 6800 XT

GPU and VRAM#

Because the crash occurred under GPU load and the display was corrupted, the graphics card was the first candidate. However, the OCCT VRAM test detected no errors.

Passing a VRAM test does not establish that the graphics card as a whole is functioning normally. Problems with the GPU core, power delivery, PCIe path, or driver could still remain. Conversely, VRAM failure cannot be confirmed merely because the blue screen appears corrupted. The cause of a crash and the process that renders the crash screen need to be distinguished.

Graphics driver#

I tried switching to an AMD PRO Edition driver, but the symptoms stayed the same. That attempt was not the solution; it does not rule out every other driver problem.

SSD, page file, and I/O path#

I found the following records in the event logs.

• 0x3B — SYSTEM_SERVICE_EXCEPTION
• 0x154 — UNEXPECTED_STORE_EXCEPTION
• 0xEF — CRITICAL_PROCESS_DIED
• First parameter 0xC0000006 in some 0x3B records — STATUS_IN_PAGE_ERROR
• volmgr 161 — dump-creation failure

Because of the in-page error in particular, I also suspected the I/O path, including the storage device and page file. Windows and the game were on different drive letters, but they were partitions on the same NVMe SSD.

CrystalDiskInfo showed no critical warnings or media/data-integrity errors. The system logs I examined also contained no direct disk or NVMe errors. The page file and small-memory-dump settings were enabled.

I could not establish an SSD failure. Also, the fact that the system improved after reseating the RAM does not mean that all the causes of the earlier I/O-related records have been explained. The original logs may contain device-identifying information, so this article reproduces only the error codes.

System RAM and the remaining paths#

The OCCT Memory test ran for about four minutes without a blue screen. At first, it was hard to see why RAM would be involved if the PC only failed during the GPU test.

However, passing a short test does not rule out memory instability under specific workloads. Since the failure reproduced immediately under GPU load, the power supply, auxiliary power connections, and PCIe path were also candidates. I did not, however, complete a cross-check using a known-good power supply or another PC.

1. I removed one RAM module and moved the other to a different slot#

I removed one of the two RAM modules and changed the position of the remaining module. At the same time, I also changed the graphics card’s dual-BIOS switch.

I changed the number of RAM modules, the slot, the reseating state, and the GPU BIOS at the same time. It was not a good test design, so I could not tell immediately which change mattered.

Even so, the change was clear. The OCCT GPU test, which had failed after about two minutes, ran for more than five minutes, and I was able to play about five games of Overwatch, which had previously produced an error after one game. These times and game counts are the results from the single-module checking stage.

2. I also checked the other RAM module by itself#

I replaced the installed module with the other one and checked it. The other RAM module also booted by itself and allowed the GPU test to run.

It was not the case that one particular RAM module consistently failed. That said, I did not test every address and operating condition of both modules.

3. Reseating also allowed the previously failing slot to boot#

At one point, the PC booted in one position but not the other. I suspected a slot failure, but when I reinserted the module in the position that had failed, it booted normally.

The contact or seating condition may have changed, but I did not record the boot-wait time or memory-training state, so I cannot distinguish that from initialization behavior. This is a two-slot ITX board, not the A2/B2 placement issue found on typical four-slot boards.

4. I returned the GPU BIOS to its original position#

While using one RAM module, I returned the GPU BIOS switch to the position it had been in when the blue screens occurred. The test still ran normally in that state.

Therefore, within what I checked, changing the GPU BIOS was not necessary for the symptoms to improve. I did not record the exact P/Q mode, so there is no basis to blame a particular mode.

5. I reseated both RAM modules#

Finally, I reseated both RAM modules. At present, the original crashes have not reproduced even with the two-module configuration.

The “more than five minutes of OCCT and about five games” result from the single-module installation cannot be carried over as a long-term test result for the final two-module configuration. Extended testing and multiple cold-boot checks after reseating both modules are still outstanding.

Contact is not simply ON or OFF#

Even when the RAM contacts are connected, there may not be enough margin to transmit high-speed signals reliably. Insertion depth, pressure from the spring contacts, and contamination on the contact surfaces can affect the connection.

Memory reads voltage within a specified short time window. If a signal settles late or becomes distorted, it may be read incorrectly under certain conditions. “Able to boot” and “stable under every workload” do not mean the same thing.

Reseating can change the contact position and pressure and improve the condition of the contact surfaces. I did not directly measure this phenomenon on my PC, so it should be understood as a possible mechanism.

GPU workloads also use the system-memory path#

Even with a discrete GPU, game state, driver-management information, and command or transfer buffers can reside in system RAM. A GPU can also exchange data with system memory over PCIe as needed.

If information in this path is corrupted, the problem may appear as a crash during graphics work. Failures can depend not only on total usage but also on addresses, data patterns, and access order. Therefore, it is possible for a short RAM test to pass while a GPU workload fails.

However, heavy GPU load does not necessarily mean that RAM or page-file load also becomes heavy. This explanation alone cannot establish that RAM caused the problem.

Retraining or a change in settings is also possible#

When the RAM configuration changes, the board and firmware may perform memory-signal retraining depending on their design. After an initialization failure, the system may also operate at more conservative speeds or timings.

Because I did not compare memory speed, timings, or XMP/DOCP status before and after reseating, this possibility remains open. The fact that I did not manually overclock the system is separate from having verified the actual firmware settings.