GPU & graphics cards — artifacts, no signal and driver resets: card vs cable vs driver

Most GPU troubleshooting goes wrong because people pick a fix before they've picked a layer. "It's artifacting, so I'll reinstall the driver" or "it says no signal, so I need a new card" both assume a cause from a symptom. The symptom is only an observation; the cause is one of four suspects: the card, the display path, the driver/OS, or stability/thermal/power (overclock, temperature, power delivery, PSU).

Why they overlap so badly is worth understanding. A cable doesn't know the GPU is under load, so a cable-caused problem tends to be random with respect to what you're doing. A driver problem tends to show up after the OS loads, and often after an update. A thermal or power problem tends to show up under load, because that's when the card draws full current and runs hot. A genuinely degrading card can show up anywhere — in POST, at idle, or under load — which is exactly why it's the last thing you conclude, not the first.

So the skill isn't knowing 40 fixes; it's knowing which test moves the probability where, and running them from cheapest and most reversible to most expensive and most irreversible. If you keep that order, you'll almost never buy a new card when the culprit was a display cable.

Treat every symptom as an observation that narrows where to look, not as a verdict. "No Signal" tells you the monitor is powered and watching its input but receiving nothing valid — it says nothing about whether the card, the cable, the port, or the monitor failed to deliver. Artifacts tell you an image is being produced but is corrupted somewhere between the card and the screen. A driver reset message tells you the OS asked the GPU to stop and restart its driver because it stopped responding. Each of these has several possible causes, and the value of the symptom is that it makes a specific test meaningful.

The context around the symptom is as important as the symptom itself. When does it appear — during POST/BIOS, only after the OS loads, at idle, or only under load? Is it constant or intermittent? What did you change just before it started? These details are what let you interpret a test: a problem that appears only under load makes the display path a weaker suspect and power/thermal stronger; a problem that started the day after a driver update makes the driver the first thing to check. Write these down before you start, because you'll need them to read the results.

A useful habit is to classify the symptom into one of five buckets up front: artifacts, no signal, black screen, flicker/signal drops, or crash/driver timeout. They're related but they point at different first tests, and mixing them up is how people end up running the wrong diagnostic. The next sections cover the first three in detail.

Artifacts are structured corruption: colored lines, blocks, checkerboards, repeated geometric shapes, color smearing, or ghosting that doesn't match what any application is drawing. Ordinary glitches are different — a one-off screen tear, a momentary flicker, a dropped frame. The distinction matters because it changes the suspect list. A single tear is often nothing; artifacts that persist across different applications are a real signal that something in the image pipeline is corrupting the data.

The single most informative artifact test is also the cheapest: reproduce the artifacts, then change one thing at a time — first the cable, then the monitor, then the output port on the card — and watch where the artifacts go. If they move with the monitor, the monitor is the cause. If they move with the cable, the cable is the cause. If they stay with the card no matter what you plug in, the card is the leading suspect. This "follow the symptom to the component" move is the core of the whole guide, and it's reversible and free.

One nuance: artifacts that appear only in certain conditions (only in one game, only at a high refresh rate, only after a driver update) are more likely to be settings, bandwidth, or driver-related than a dead card. Artifacts that are present everywhere, including on the desktop and in POST, are more likely to be the card or its memory. The table below maps common artifact patterns to when they appear, what they can mean, and the next test to run — as starting points, not verdicts.

These two look similar from the chair but mean different things, and the difference changes how you read the tests. "No Signal" is the monitor actively telling you it's on, it's watching that input, and it's receiving nothing valid. A plain black screen (the monitor stays connected, power LED on, but no "no signal" text) is a different situation: it can mean the source is sending a signal the monitor won't accept, a dead input, or a source that's powered but not outputting an image at all.

For "No Signal," the display path is the natural first suspect, because that is literally what the message is about — the monitor isn't getting a signal, so test the things that carry it (cable, port, adapter, monitor, input). For a plain black screen, the source side (card, power, driver) becomes a bit more plausible, but you still test the path first, because it's the cheapest thing to eliminate and a bad cable is a common cause of a black screen too.

The table below walks the common no-signal/black-screen scenarios, the test to run, and what each result implies. The pattern to internalize: every "it still does it with a different X" is a point against the path and toward the source; every "it works with a different X" is a point for the path.

Operating systems can reset a GPU driver when the GPU stops responding within a timeout. In Windows this is the "display driver stopped responding and has recovered" message (a TDR — Timeout Detection and Recovery — in the event log); Linux has its own GPU reset paths. The important reframe is that a reset is a recovery, not a death: the OS detected the GPU hanging and restarted the driver to keep going. A single occasional reset can be harmless. Repeated resets mean something is regularly hanging the GPU, and your job is to find out what.

The causes again span all the layers, and the timing is what separates them. Resets that began right after a driver update point strongly at the driver. Resets that happen only under load and track with high temperatures or power draw point at thermal or power delivery. Resets that happen even in Safe Mode, or that survive a clean driver install and a different OS, push suspicion toward the hardware. The reset message by itself doesn't say which — the when does.

The method is "follow the symptom to the layer." You have four suspects and a small set of cheap, reversible tests, each of which moves the probability in one direction. The fastest order goes from cheapest to most expensive, so you never spend money before you've ruled out the things that cost nothing.

1. Does it survive a different cable, port, and monitor? If the symptom follows the cable or monitor, the display path is your cause and you're done. If it survives all of them, the path is out.
2. Does it survive a different driver/OS state? Safe Mode, a driver rollback, a clean install, or a Linux live environment. If the problem disappears, the driver/OS stack was the cause.
3. Does it change with clocks, temperatures, and power? Return to stock, confirm every power connector is seated, check temps under load. If it stabilizes, it was a stability/thermal/power issue.
4. Does it survive a different card in a different system? This is the decisive isolation. If the suspect card fails elsewhere and a known-good card works here, the card is the cause.

Each step is a decision point: "it disappears" is a point for the layer you just changed, and "it persists" is a point against it. By the end you have a short evidence log that either points clearly at one layer or tells you honestly that you don't have enough signal yet. The schematic below shows the three main branches — card, display path, and driver — and the diagnostic process checking each one in turn.

If you'd rather have a guided route than a map, answer the questions and the agent will weigh each answer, show the evidence as you go, and point you at the leading layer with a confidence level and the reasoning behind it. It's deterministic and transparent — it doesn't pretend to read your hardware, and it will tell you when the evidence is insufficient rather than guessing.

When a symptom appears during POST or in the BIOS — before any operating-system driver is loaded — it's significant, because the OS and its driver are simply not involved yet. The GPU is being driven by the firmware's basic display mode. So artifacts that show up there can't be blamed on a Windows or Linux driver; they point at the card (its core or VRAM) or the display path. Conversely, a clean POST followed by artifacts only after the OS loads is the classic signature of a driver or a display setting, not the hardware.

The reverse is equally useful. If the POST screen is clean but the desktop corrupts the moment the full driver takes over, that's a strong hint the driver, a resolution/refresh configuration, or a specific application is the cause. If artifacts are present in POST and persist after the OS loads, the card is the leading suspect, because the problem predates the driver.

One caution: the firmware display mode is basic, so a card that is fine in POST can still fail under a full driver at high clocks and load. A clean POST doesn't prove the card is healthy — it only rules out the driver for that moment. That's why the after-OS and under-load tests still matter even when the BIOS looks fine.

This is the cheapest layer to eliminate, so it comes first. The move is always the same: change one element at a time and watch the symptom. A different cable. A different output port on the card. A different monitor. And if there's an active adapter, extender, or a long run of cable in between, remove it and connect directly. Each swap either moves the symptom (pointing at the thing you changed) or doesn't (removing it from suspicion).

DisplayPort deserves a specific mention because it's a common source of phantom "failing card" reports. DP is sensitive to cable quality and length (each version has a bandwidth limit), can be affected by a poor EDID handshake, and some long or thin DP cables drop to a lower mode or fail intermittently. That produces exactly the symptoms people misread as a dying GPU: intermittent no-signal, flicker, or a drop to a low resolution. A short, known-good, correctly-rated cable eliminates a surprising amount of noise.

What to expect: if the problem follows the monitor, the monitor (or that input) is the cause. If it follows the cable, the cable is the cause. If it follows a specific port on the card, that output may be dead — which is a card problem, but a single dead output doesn't mean the whole card is bad. If the problem survives all of it, the display path is ruled out and you move on to the driver and power layers.

Two physical checks are cheap, reversible, and catch a lot of false "dead card" conclusions. The first is seating: a GPU that isn't fully seated in the PCIe slot — or whose retention clip isn't engaged — can lose the link, giving no-signal, a POST failure, or intermittent drops. The second is power connectors: modern cards need one or more 6/8-pin (or 12VHPWR/16-pin) connectors fully and correctly seated. A partially seated or marginal power connection is the classic cause of "fine on the desktop, dead the moment I start a game," because the card only draws full current when it's actually working.

Do these safely and deliberately: power the machine off, unplug it, ground yourself, reseat the card firmly until the clip engages, and press each power connector until it clicks and sits flush. Then power up and re-test. What the result tells you: if reseating and firm power connections fix it, it was a connection, not a component. If under-load failures persist with seating and power confirmed solid, the power-delivery layer — PSU capacity, PSU health, or the cable run — becomes the suspect before you start blaming the card. Under-load-only failures should make you check power first, because that's where a weak supply shows its face.

The driver stack is the most common cause of after-OS display problems, and the most common reason to act before you touch hardware — but the order matters. Roll back before you clean-install, and clean-install before you conclude the card is bad. If the problem started right after a driver update, reverting to the previous driver is the fastest test of the driver hypothesis, and it's reversible. If rollbacks don't help, a clean install (removing the old driver's configuration) tests whether a corrupted driver state is the cause. If the problem appears in POST (where no OS driver is loaded) or survives a clean install and a different OS, the driver isn't the whole story and further reinstalling is a waste of time.

To separate "Windows/config" from "hardware," use a clean boot (disable non-Microsoft startup items), a different user profile, and — the strongest test — a different operating system, such as booting a Linux live USB on the same card. If the display is stable under a Linux live environment on the same card, the hardware is less likely and the Windows/driver side is more likely. Each of these is a controlled change to the software layer, and each result narrows the field.

A few safe, read-only commands help you gather evidence from the GPU itself. They report status, temperatures, power, and driver messages — they don't change anything.

Safe Mode loads a minimal, generic display driver instead of the full vendor driver. That makes it a clean test of the driver hypothesis. If the display is stable in Safe Mode but not in normal mode, the problem lives in the full driver/OS stack, not (necessarily) in the card — and you can work on the driver from a stable environment. If the problem persists in Safe Mode, the generic driver isn't saving you, which pushes suspicion toward the card, power, or a deeper OS issue. Either outcome is useful because it splits the problem cleanly in half.

Where a clean driver install fits: after a rollback fails, when the driver state looks corrupted, or before running diagnostics that assume a clean driver. Where it doesn't fit: when the problem appears in POST (a driver can't be the cause yet) or when it survives a clean install and a different OS. A practical rule is to avoid looping on clean installs — if a genuinely clean install hasn't fixed it, the driver is probably not the whole story, and the next variable is power, clocks, or the card.

This is the single most decisive isolation, because it changes the most important variable. There are two directions to run it. Put the suspect card in another known-good system: if it misbehaves there, the card is the leading suspect; if it's fine there, the problem is in your original system (PSU, slot, motherboard, or power). Put a known-good card in your system: if it's fine, your system is the problem; if it also misbehaves, your system is the problem, not the card.

Read the four-way result carefully, because it's the cleanest logic in the whole guide: if the suspect card is bad in another PC, the card is implicated. If the suspect card is fine in another PC, your system is implicated. If a known-good card is bad in your PC, your system is implicated. If a known-good card is fine in your PC while the suspect card is bad in your PC, the card is isolated. This is why arranging a borrowed or known-good card is worth it before any RMA — it converts a guess into a conclusion.

One caveat: test in a system with adequate power and a working slot, or you'll create a false negative (a good card that "fails" because the second system can't power it).

Temperature is a frequent contributor but an easy one to over-attribute. High or throttling temperatures can cause instability and resets, but many healthy cards run hot and fine — so high temperature alone isn't proof of failure. What matters is correlation: does the symptom track with temperature and load? If it does, and returning the card to stock makes it stable, thermal/power is a strong candidate. Check temperatures under a real load and note whether the card is throttling; the commands in the previous section give you the numbers.

Overclocking and undervolting are the great mimics of a dying card. An unstable overclock — or an undervolt that's been pushed too far — produces artifacts and crashes under load that look exactly like hardware failure. The decisive test is to return the card to stock and re-test. If stock is stable, the "failure" was the settings, and this is one of the most common false alarms in GPU troubleshooting. This is why the stability layer deserves its own step before you ever consider the card dead.

Power belongs in this same bucket for the same reason: a marginal supply shows up under load, the only time the card draws full current. The read on this layer is consistent — under-load-only failures should make you check clocks, temperatures, and power before the card.

Some artifact patterns — repeated blocks, checkerboards, or corruption that persists or worsens — can point at the card's VRAM. But software tests are limited tools for proving it. A GPU or memory stress test can produce a false positive (an aggressive test pushes a healthy card past its normal envelope until it crashes) and a false negative (a card with a marginal, intermittent fault can pass a short test and then fail in real use). So a stress result is evidence to weigh, not proof on its own — read it relative to the card's rated clocks and to whether you can reproduce the symptom in normal use.

This is the key intellectual move of the whole guide: no single test proves a component is defective. You build a conclusion from a pattern — the symptom across cables, monitors, OS states, clocks, and systems. A card that artifacts only in a maxed benchmark but is fine everywhere else is a very different (and much less serious) situation than one that artifacts in POST, at idle, and across two different systems.

Integrated graphics are a useful diagnostic here. If your system has an iGPU, moving the display output to it in the BIOS isolates the discrete card from the display path and the OS. A system that runs fine on the iGPU but not on the discrete GPU points at the discrete card or its connection.

At the motherboard level, a few signs point at the slot or link rather than the card: a GPU that isn't detected at all, a GPU detected at a degraded link (for example x1 instead of x16, which can cause poor performance or instability), or a card that only works in one slot. Some GPUs use a PCIe cable to reach a secondary slot, and a loose or faulty cable there produces exactly these symptoms. Testing in another slot — and, decisively, another system — separates a slot/cable problem from a card problem.

So when does the evidence actually point at the card? It's the accumulation, not any single test: artifacts that follow the card across different cables, monitors, and OS states; under-load failures with power confirmed solid; failures in another system; and a known-good card working in yours. No one of these is proof. Together, they form a strong case. If you can point to that pattern, you've earned the right to move on from troubleshooting the card to dealing with it.

And to be explicit about what not to do prematurely: don't flash GPU firmware or BIOS (it's rarely the cause and a bad flash can brick the card; don't loop on repeated "repairs" or clean installs; don't RMA based on a single stress-test failure; and don't replace before you've ruled out cable, driver, power, and seating. Every one of those is expensive or irreversible, and the cheap tests above rule out the common causes first.

There's a point where further troubleshooting stops paying for itself, and it's a good idea to recognize it. The stopping criterion is that you've isolated the layer to the card with reasonable evidence: it misbehaves across different cables, ports, monitors, and OS states, ideally in another system, with power confirmed solid and clocks at stock, while a known-good card works in your machine. At that point the rational next step is repair, RMA, or replacement — not another hour of tests. Continuing past that point usually just confirms what the evidence already says, at increasing cost to your time.

For RMA versus replacement: pursue RMA if the card is under warranty, and bring your evidence log — dates, the symptoms, and what you tested — because a documented pattern speeds up the process and strengthens the case. Choose replacement if it's out of warranty or the card is old enough that a new one is the better value. Either way, back up before you swap or ship the card, and note that a replacement card can itself be defective (a "DOA"), which is why a quick re-test on arrival is worth it.

Remember the standard you're meeting: you're not claiming one test proved the card dead. You're showing a consistent pattern that the card is the most likely remaining cause after everything cheaper and more reversible has been ruled out.

The whole method, as tickable steps in the right order. Work top to bottom; each step either identifies a cause or rules a layer out. Your progress is saved in this browser, so you can work through it across sessions.

GPU problems often overlap with broader stability, crash, and hardware topics. These guides from the wider library naturally follow on from here.