About a year ago I upgraded from an RTX 2060 SUPER to a Gigabyte RTX 5090 Gaming OC 32G. Since then, the card has intermittently caused a black screen followed by a hard reboot. There is no BSOD or useful crash dump, and audio often continues briefly in the background.
The crashes are highly workload-dependent. World of Warcraft, Hitman with an 80% power limit, Kingdom Come: Deliverance II, Starfield, and Crimson Desert with DLSS Quality can run normally. However, STALKER 2 consistently crashes during loading, Dispatch crashes at startup, and Crimson Desert crashes when using DLAA instead of DLSS. Unreal Engine games seem especially likely to trigger the problem.
I have already tried lowering the power limit, applying a -200 MHz core offset, forcing PCIe Gen 5, Gen 4, and Gen 3, replacing the PSU with a Corsair HX1500i, using several different 12V-2x6 cables and a cable adapter, monitoring the connector with a WireView, updating the motherboard BIOS, and testing many NVIDIA driver versions. I also rebuilt the entire system around the card using a Gigabyte Z890 AORUS ELITE WIFI7 and an Intel Core Ultra 7 265K. The problem remained under both Windows 11 and Linux. The same slot, PSU, and cable work perfectly with my old RTX 2060 SUPER. The RAM has also passed memory testing.
The card was sent back under warranty, but the retailer only replaced the thermal paste and returned the same card with the same serial number. The fault appeared immediately afterward.
My current system has 32 GB of DDR5-4800 memory with XMP disabled, the RTX 5090, a 1500 W Corsair HX1500i, and a 2560x1440 display. On Linux, I logged NVIDIA telemetry every 250 ms and captured the final readings before the crash. During GPU initialization or a workload using relatively little power, the card's reported thermal-limit headroom can collapse from around 40 degrees to nearly zero within a fraction of a second. This is followed by an AER receiver error and Xid 79, meaning the GPU has fallen off the PCIe bus.
The behavior is reproducible with different memory and core-clock limits. Keeping the memory at a very low speed allows some tests to survive, while normal core workloads can drive the reported thermal limit to zero or below even though the ordinary GPU temperature is only around 40–66°C. Capping the core below roughly 900–1200 MHz can keep the card alive, although higher caps eventually cause permanent throttling or a shutdown. The pattern suggests either a defective internal hotspot or sensor path, a package/VRM problem, or a cooler contact issue that thermal-paste replacement did not resolve.
Given that the problem follows the card across two systems, operating systems, driver versions, power supplies, cables, PCIe generations, and workloads—and that another GPU works in the same setup—what should I test or document next? Does this evidence point strongly enough to a defective card for another warranty replacement or refund?
5 Answers
At this point, the GPU itself is the overwhelmingly likely culprit. You have reproduced the failure on different operating systems, drivers, motherboards, CPUs, PCIe generations, power cables, and a second complete build. The old card works in the same slot and power path, which makes the rest of the system very unlikely to be responsible.
The sudden thermal-limit collapse followed by AER and Xid 79 is especially useful evidence. A normal GPU temperature reading does not rule out a localized die, package, VRM, or sensor problem. I would make a concise timeline of the tests, save the Linux logs showing the final telemetry and Xid 79, and submit another warranty claim requesting a replacement or refund rather than another repaste.
The hotspot data is concerning. A card can report a reasonable average GPU temperature while one small area of the die or package reaches its protection threshold. That could come from poor cooler contact, a damaged heat-transfer interface, a defective sensor path, or an internal silicon/package fault.
Because the retailer already replaced the paste and the exact failure returned immediately, I would not open the card or attempt a reflow yourself. Those actions could complicate the warranty and may not help if the fault is inside the package. Ask for a full replacement or refund first. A different cooler or water block would only be worth considering after the card is out of warranty, and even then it would not fix an electrical or sensor defect.
For the warranty claim, keep the wording simple and reproducible: install the card in a known-good system, launch one of the affected games or run the Linux GPU test, and record the black screen, reboot, AER receiver error, and Xid 79. Include a comparison showing that the RTX 2060 SUPER works in the same system with the same PSU, cable, slot, and display.
Request an actual replacement or refund and point out that the previous service only replaced thermal paste without resolving the documented fault. Avoid modifying the card or paying for board-level repair while consumer protection and the manufacturer warranty are still available.
The fact that some games work does not make the card healthy. Different engines and rendering paths exercise different parts of the GPU, and DLAA versus DLSS can change the resolution, shader, memory, and compute workload enough to expose a marginal component. Unreal Engine is probably not the root cause; it may simply be triggering the particular workload that makes the card fail.
You have already gone far beyond the usual driver-cleanup checklist. DDU, reinstalling Windows, flashing firmware, or changing RAM slots would be reasonable early tests, but they are very unlikely to explain an identical failure on Linux and on a freshly rebuilt machine.
I also checked the card firmware situation and found no newer BIOS for this model. Since the same issue occurs with an older Linux installation and older NVIDIA drivers, a driver conflict seems especially unlikely.
A missing BSOD or minidump is expected here because this is a GPU or PCIe-level reset rather than a normal Windows software crash. The audio continuing for a moment also fits the GPU disappearing while the rest of the system has not yet fully locked up. The logs you captured are more relevant than Windows minidumps in this case.
That is what I am hoping to establish. I have kept logs from both operating systems and plan to include the reproducible low-clock and low-power tests so it cannot be dismissed as a random game crash.