For about three months, my computer had a bad crashing habit that I couldn’t fix. Games would crash, but not consistently, and not in a way I could reproduce. I had two blue screens at idle and under load, and since I never experienced a complete Linux crash, I attributed them to a Windows bug. As far as frequency goes, it wasn’t enough to be annoying, even a few weeks ago.
I couldn’t last 10 minutes in a gaming session without a complete crash, and I knew it was time to get to the bottom of it. I presented all my evidence to Claude — game crash logs, Windows logs, and anything else I could find, and the machine confidently diagnosed my pre-owned RTX 5080’s VRAM as the problem. I was halfway through an RMA before I took a closer look at what I found, and the real culprit ended up being my system’s memory configuration, which hadn’t changed since I built my system years ago.
Claude was great in the boring part
I will never look up records myself again
I will give Claude credit where credit is due, because his ability to sort out the problem was incredibly helpful. I was having a breakdown Escape from Tarkovand that game writes detailed crash logs for almost every subsystem in a single session. I handed Claude the entire folder, he analyzed it all and found the important thing in less than a minute.
found a “DXGI_ERROR_DEVICE_REMOVED” Error, which is Windows telling you that the GPU stopped responding and the driver needed to reset it. At best, this crashes the game; In the worst case, this may cause the system to crash. From there, he walked me through PowerShell commands that can search the Windows event log. This led to the discovery of an NVIDIA driver reset that was logged one second before the first Tarkov error, a kernel monitor dump that was written at the same moment, a bunch of graphics exceptions complaining of a corrupt “shader header,” and three other resets dating back to August.
All of these dates fit perfectly with the crashes I experienced, and at least at this point, all signs pointed to the GPU as the culprit.
One inverted piece became the whole diagnosis
Red herring
The next step was to test the GPU memory. Claude pointed me to memtest_vulkan, a free tool that fills the video memory with patterns and makes sure they are read correctly. About 45 seconds into the first round, I picked up one face-down piece, and this became the catalyst for the set of events that followed.
Claude then told me that the upside down piece was evidence of a faulty VRAM and that I should start the RMA process with MSI. When I asked why a card that had been working fine for months suddenly started failing, he claimed that the bug was located about 13GB in the card’s 16GB memory, so perhaps a recent update to the game had pushed Tarkov high enough to start landing in a vulnerable spot. This didn’t make sense to me, since other games that filled the entire buffer weren’t crashing reliably, so I took a closer look at the test results myself, and that opened up a whole new can of worms.
The number that Claude missed indicates the real reason
Speeding was a huge red flag
In the VRAM test I was using the reporting transfer rate while it was running, and the failed runs were transferring data at between 200 and 300 GB/s. The RTX 5080’s memory is rated at 960 GB/s, which has already raised some doubts. A test that actually knocks the card’s VRAM should hit somewhere near that, and in the end it did: a clean run reached nearly 850GB/s and went through about three hours, with the memory overclocked above stock.
This clear turn on for me was a big red flag with the RMA proposal. Claude did detect these huge deltas between tests, but attributed them to clock states, and they were not properly parsed by the test screenshot along with HWiNFO, which showed that the PCIe bus was under significant load with tests failing at low speeds. This should have been a clear sign that the PCIe bus or system RAM was in serious doubt.
When video memory runs out, Windows quietly moves data into system RAM instead of rejecting the request. When I started the initial testing, there were apps that took up a few GB of my VRAM, so part of the memtest buffer ended up in system memory, and that’s likely the problem. I ran the VRAM test overnight, and when it showed no errors, I knew exactly where to look next.
My RAM was the prime suspect
More DDR5 instability
My PC runs a Ryzen 7 7800X3D with four 16GB DDR5-6000 memory modules, which doesn’t sound crazy, but AMD only rates the Ryzen 7000 CPUs for up to 5200 on two modules, and drops that speed to 3600MT/s once all four slots are filled. Raising the speed to 6000 doesn’t seem silly because that’s why AMD has called itself the “sweet spot” for Zen 4 chipsbut going from 5200MT/s to 6000MT/s on two sticks is a completely different request compared to going from 3600MT/s to 6000MT/s.
This was the memory configuration I had run since I assembled this computer in 2024, but the evidence was pointing to this being the culprit, so I ran an overnight memory test.
And so it was: MemTest86+ reported 22 errors after five hours of healthy passes, and that was the smoking gun behind it all.
I didn’t have time to test each set of sticks to see if one of them was defective, but the most likely explanation is that four DIMMs at that speed were demanding too much of my CPU’s memory controller. Instead of dropping speed and sacrificing performance, I took out two sticks, and… Tarkov It has remained stable since then.
Using AI for troubleshooting is not a bad idea, but it may lead to missing small details
For first-line troubleshooting, I still look for an AI model because it is the fastest way to analyze a set of logs to find relevant errors. But for the testing part, I trust my knowledge and intuition. When it comes to errors like this, the cause can be complex and multifaceted, and you’ll never be sure based on just one clue. Before acting on an AI diagnosis with something as drastic as an RMA, getting tested to rule out other components is always a good idea, and I learned that almost the hard way.
