The setup: crashes that wouldn't behave
Ty Sherback, writing for XDA Developers, described a PC that had been crashing for about three months. Games crashed inconsistently, and there were a couple of blue screens at idle and under load. He had no total crashes on Linux, so he put the blame on Windows. That inference is understandable, though it turned out to be misleading. Things got bad a couple of weeks before publication, when he couldn't get through ten minutes of gaming without a crash.
He gave Claude his game crash logs and Windows logs. Claude diagnosed the VRAM on his pre-owned RTX 5080, and he was partway into an RMA before he looked more closely at what it had found.
What the logs actually showed
Claude did well on the tedious first step. Escape from Tarkov writes detailed crash logs, and Claude pulled out a DXGI_ERROR_DEVICE_REMOVED error. It then suggested PowerShell queries against Windows' event history. According to the account, those queries turned up:
- An NVIDIA driver reset logged about one second before Tarkov's first error.
- A kernel watchdog dump written at the same moment.
- Graphics exceptions mentioning a corrupt "shader program header".
- Three earlier resets going back to August, which matched crashes he remembered.
Those findings point at the graphics stack, so the GPU suspicion was reasonable at this stage. It still isn't proof of bad VRAM, and Microsoft's documentation explains why.
What DXGI_ERROR_DEVICE_REMOVED means
Microsoft's DXGI error reference describes this code as meaning the video card was physically removed or a driver upgrade occurred. It says the application should destroy and recreate the device... actually, the wording in Microsoft's table is that the application should destroy and recreate the device, and it points developers to GetDeviceRemovedReason for debugging. The same table lists a separate DXGI_ERROR_DRIVER_INTERNAL_ERROR for a driver problem that put the device into the removed state.
In practice the code says the graphics device went away. It does not say why. Bad VRAM, an unstable GPU overclock, a driver fault, a power problem and memory-subsystem trouble elsewhere in the machine can all end in the same error.
The test result that misled everyone
Claude next recommended memtest_vulkan. The project's readme describes it as an open-source, cross-platform tool written in Vulkan compute to stress-test video memory. It needs a Vulkan 1.1 driver and recommends running for at least six minutes. About 45 seconds into the first run, it reported a single flipped bit.
Claude read that as a VRAM defect and suggested an RMA through MSI. When asked why a card that had been fine for months would suddenly fail, Claude reportedly suggested the error sat about 13GB into the 16GB of memory. Its idea was that a recent game update had pushed Tarkov onto a weak spot. That was a hypothesis, not a finding. The author doubted it because other games that fill the buffer weren't reliably crashing.
The throughput clue
The tool reports throughput as it runs, and the author's failing runs moved data at roughly 200 to 300GB/s. NVIDIA lists the RTX 5080's memory bandwidth at 960GB/s. Eventually a clean run reached about 850GB/s and passed for around three hours, with the memory overclocked above stock.
Claude noticed the gap but attributed it to clock states. It reportedly also missed that HWiNFO showed heavy PCIe bus activity during the slow, failing runs. Heavy PCIe traffic suggests the test may have been using system memory rather than only the card's own memory.
The author's explanation was that other apps were holding a few gigabytes of VRAM, so part of the test buffer ended up in system RAM. That is plausible, but it is an inference. He did not directly measure where the buffer was placed.
A caution on the paging claim. The article says Windows quietly pages video memory out to system RAM when VRAM runs out. Microsoft's WDDM documentation is more nuanced. It describes a segmentation model where the video memory manager handles dedicated memory segments and system memory segments, with paging operations between them. Where an allocation lives depends on the graphics stack and the driver, so the blanket statement is a simplification. The mechanism is real, but "always" is too strong.
Even so, a GPU memory test that apparently touches system RAM is a weak basis for blaming the card. An overnight VRAM test then produced no errors.
The real culprit: four DIMMs at DDR5-6000
The system uses a Ryzen 7 7800X3D with four 16GB sticks of DDR5-6000, in place since the build in 2024. That is outside AMD's published limits for this CPU. AMD's 7800X3D specification lists maximum memory speeds of 2x1R DDR5-5200, 2x2R DDR5-5200, 4x1R DDR5-3600 and 4x2R DDR5-3600. Two sticks at DDR5-5200 is the supported maximum, and four sticks drop to DDR5-3600.
Running EXPO or XMP profiles above those figures is common and often works. But AMD does not guarantee it. One enthusiast guide notes that populating all four slots places a significantly higher electrical load on the CPU's memory controller. Going from 5200 to 6000 on two sticks is a smaller ask than going from 3600 to 6000 on four.
MemTest86+ run overnight reported 22 errors after five hours of clean passes. That detail matters. A short memory test could easily have passed and sent him back to the GPU.
His fix was to pull two sticks. He did not lower the speed, and Tarkov has been stable since.
What the evidence does and doesn't prove
This is a strong anecdote, but it has limits:
- He did not test each DIMM individually, so a faulty stick is not ruled out.
- Removing two sticks changed both the DIMM count and the electrical load. The account doesn't isolate which factor mattered.
- There is no performance comparison between configurations.
- The earlier blue screens may or may not share the same root cause.
His conclusion that the four-DIMM configuration overtaxed the memory controller is well supported, but it is still his working diagnosis, not a lab finding.
A practical checklist if your GPU "fails"
- Treat DXGI device-removed errors as a symptom. They mean the graphics device went away, not that VRAM is bad.
- Line up timestamps. Check driver resets, watchdog events and game errors against your crash times. PowerShell queries of the Windows event log can help here.
- Compare test conditions. If a GPU memory test reports throughput far below the card's rating, find out why before trusting the result. Close apps that hold VRAM and watch for unexpected PCIe traffic in a monitoring tool.
- Run long tests. The memtest_vulkan readme says errors near the limit can need two to three hours of testing to show up. This case shows system RAM faults can also take hours.
- Test system RAM too. Run MemTest86+ overnight before starting an RMA.
- Check memory against the CPU's supported speeds. If you have four DIMMs on a Ryzen 7000 chip, try the supported speed or two sticks as a diagnostic step.
- Change one variable at a time. That is the step this case lacked.
The AI lesson
Claude was fast at the log triage, and the author still plans to use AI for that. Where it went wrong was in sticking to a single clean story after the evidence got messier. It explained away the throughput gap and appeared to skim the HWiNFO screenshot. This is a common failure for AI assistants: they commit to a confident answer, and the commitment can be costly if it leads to an RMA.
The sensible split is to let AI sift logs and propose hypotheses, then check those hypotheses with tests that could prove them wrong. As the author puts it, don't take drastic action on one piece of evidence.
An RMA would have cost time and possibly money, and the crashes would have remained.