GPU Driver Stopped Responding and Recovered (TDR)? Timeout Detection, Event Viewer Clues & Driver vs Power vs Hardware Diagnosis

2026-10-23 ｜ GPU Repair ｜ About 21 minutes ｜ HK GPU Fix Editorial Team

Summary

A 'display driver stopped responding and has recovered' message means Windows reset the graphics driver after it stopped answering within a timeout window. This guide explains how that timeout works, what Event Viewer entries reveal, and how to separate driver, power and hardware causes before deciding on repair.

What a TDR Actually Is

Timeout Detection and Recovery, usually shortened to TDR, is a Windows mechanism, not a diagnosis and not a component. When the graphics processing unit (GPU) stops responding to the operating system for longer than a set timeout, Windows assumes the graphics driver is stuck, stops it, and restarts it. The screen may go black for a second or two, the application that was using the GPU may close or freeze, and Windows then shows a message along the lines of "Display driver stopped responding and has recovered."

That sequence matters because it tells you what did and did not happen. A TDR is a driver timeout reset. It is not, on its own, proof of a dead graphics card. A healthy card can trigger a TDR when a driver, a power delivery problem, an overheating condition, or a badly behaved application leaves the GPU unable to answer in time. Equally, a card with a genuine hardware fault can run for days without a TDR and then fail in a completely different way, such as showing visual artefacts or refusing to display anything at all. Treating every TDR as a dead card leads to unnecessary replacement; ignoring repeated TDRs leads to wasted time reinstalling software while a power or cooling problem continues.

The timeout exists because the alternative is worse. Without it, a stuck GPU could freeze the whole display indefinitely and force a hard power-off, with unsaved work lost and no clue left behind. With TDR, Windows recovers the display in most cases, and the event is logged so the pattern can be studied afterwards. The recovery itself is therefore useful evidence, not just an annoyance to dismiss.

How the Timeout Works, Step by Step

In normal operation, Windows hands rendering work to the GPU through the graphics driver, and the GPU reports back as each piece of work finishes. The operating system watches that conversation. If the GPU does not respond within the timeout window, Windows concludes that the driver or the GPU is hung, resets the driver, and re-establishes the display path. Applications that were holding GPU resources may need to restart, because their rendering context was torn down during the reset.

The default timeout is 2 seconds, controlled by the TdrDelay value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers. Microsoft treats these registry settings as test and debugging tools, not routine troubleshooting: back up the registry before changing them, restart after any change for it to take effect, and do not use a longer timeout as a first step.

Several layers sit between the application and the silicon, and a delay at any of them can look the same from the outside. The application may send work the driver cannot schedule cleanly. The driver may be waiting on a resource, such as video memory, that is not available. The GPU may be waiting on power or on a clock change that never completes. The PCIe link may be unstable, so commands or data do not arrive intact. The result in each case is the same visible event: silence past the deadline, followed by a reset.

That is why a single TDR rarely identifies a cause. The useful information is in the pattern around it: what was running, how long the system had been running, whether the card was hot, whether the screen had already flickered or stuttered, and whether the same trigger reproduces the event. A TDR that happens only in one game, only after a driver update, or only when a second monitor wakes from sleep points in a different direction from a TDR that happens at the desktop with nothing demanding running.

Reading Event Viewer Without Over-Reading It

Event Viewer is the first place to look after a TDR, because it records what Windows saw at the time. Open Event Viewer, go to Windows Logs and then System, and look around the time of the black screen. The classic entry is Event ID 4101 from the source Display, with wording close to "Display driver stopped responding and has recovered." The driver name in that entry is also informative: names associated with NVIDIA, AMD, or Intel drivers point to which driver was reset, which matters on a system with more than one graphics device, such as a laptop or a desktop with integrated graphics alongside a discrete card.

Related entries can add context, but they need careful reading. A LiveKernelEvent entry, or a driver-specific warning recorded just before the 4101 entry, may describe the same incident from a different layer. Kernel-Power Event ID 41, by contrast, means the system restarted without a clean shutdown; it is not itself a TDR, and finding it alongside TDRs usually means the machine eventually lost power or was force-restarted, which is a separate clue. The absence of an entry is also information: if the screen goes black and the machine restarts with no 4101 entry, the cause may sit below the driver layer, for example in power delivery, rather than in the driver itself.

Three cautions apply. First, Event Viewer timestamps follow the system clock, so compare them with when the symptom actually happened rather than assuming the newest warning is the cause. Second, a single old 4101 entry from months ago does not explain a new problem; look for a cluster that matches the current symptoms. Third, driver and hardware names vary by vendor and driver version, so do not treat an exact message wording found online as a requirement; the event ID and the timing pattern carry more weight than any single phrase.

Driver Causes: The First to Check, and the Most Reversible

Driver problems are the first thing worth checking because drivers change often and sit directly in the reset path. A driver update can introduce a regression for a particular card, application, or monitor combination. An installation can also be incomplete, leaving mixed files from two versions, especially when an update is interrupted or when a driver is installed over a much older one without a clean step. Corruption from a failing storage drive or an interrupted update can produce the same result.

A disciplined driver test has a clear order. First, note the current driver version and the date the problem started, and check whether the two line up. Second, if the problem began after an update, roll back to the previous driver version that was stable and test under the same trigger that previously caused the TDR. Third, if rolling back does not help, or if no previous version is available, perform a clean installation: remove the driver thoroughly with the standard uninstaller tooling provided for that purpose, restart, and install a single driver package fresh, without layering extra utilities on top during the test. Testing with a clean driver install, and nothing else changed, is what makes the result interpretable; changing the driver, the power plan, and the game settings all at once leaves no way to know which change mattered.

Driver settings also deserve attention. Features such as hardware-accelerated GPU scheduling, variable refresh handling, and aggressive power management change how the driver and GPU interact, and toggling one setting at a time, with a retest after each change, is more informative than resetting everything at once. Overclocking applied through driver-level utilities is another common contributor: a clock speed or voltage curve that is stable in one workload can fail in another, and returning clocks to the manufacturer's default values is a valid diagnostic step, not an admission that the card is faulty. If the TDRs stop at default clocks, the question becomes whether the overclock was ever stable for that workload, not whether the card has died.

Power Causes: When the Card Cannot Get What It Needs, When It Needs It

A graphics card does not draw a flat amount of power. It idles at low draw, spikes sharply when a demanding scene loads, and drops again when the scene changes. If the power supply cannot meet a short spike, or if the delivery path to the card is weak, the GPU can stall long enough to trip the timeout even though the average power draw looks reasonable. This is one reason TDRs that happen at the exact moment a game loads, a video starts, or a second monitor wakes are worth treating as power suspects alongside driver suspects.

The delivery path matters as much as the supply itself. Most mid-range and high-end cards use one or more dedicated PCIe power cables from the power supply. Using a single cable with a split connector to feed a card that expects two separate cables can starve one input during spikes, and a loose or partially seated connector can behave intermittently: fine at idle, unreliable under load, and different from day to day. Reseating both ends of each PCIe power cable, confirming each connector clicks fully home, and using separate cables where the card design provides for them are simple checks that cost nothing and rule out a whole class of faults. Extension cables and adapters add further joints to that path and should be removed during diagnosis, so the test covers the shortest, most direct connection.

Power supply capacity should be judged against the card manufacturer's published recommendation for the whole system, not against the card's idle draw or a single number seen in a monitoring tool. A supply that was adequate for a previous, less demanding card may be marginal for a newer one, and age and heat also reduce a supply's margin over time. No single monitoring reading proves a supply is healthy, because most tools sample too slowly to catch a brief dip, but a pattern of TDRs tied to load transitions, combined with a supply at or below the recommended capacity, is enough reason to test with a known-adequate supply before concluding the card is at fault. Unstable wall power, an overloaded power strip, and a failing uninterruptible supply can also contribute, so testing with the machine connected directly to a known-good outlet, without extra devices sharing the strip, is part of a complete power check.

Hardware Causes: Heat, Memory, Connection, and the Card Itself

When driver and power checks do not resolve repeated TDRs, hardware causes move up the list, but they still need to be separated from each other. Heat is the most accessible to check: a card whose fans are blocked, whose heatsink is clogged with dust, or whose thermal paste has degraded will throttle, and a card that repeatedly hits its thermal limit under load may stall or reset. Monitoring temperature during the same workload that triggers the TDR, rather than at idle, is what matters, because an idle temperature tells almost nothing about behaviour under load. Fan behaviour also matters: a fan that does not spin up under load, or that spins noisily and inconsistently, points to cooling rather than to the graphics chip itself.

Video memory faults produce a different signature from a pure driver timeout. They more often show as visual artefacts, such as coloured blocks, lines, or corrupted textures, or as crashes in memory-heavy scenes, and they may appear alongside TDRs rather than as clean TDRs alone. System memory faults can also masquerade as graphics problems, because corrupted data handed to the GPU can cause the driver to fail. Running a system memory diagnostic, and testing with memory modules reseated or, where the system allows it, tested one at a time, helps separate system memory from graphics memory as a suspect.

The physical connection deserves the same attention. A card that is not fully seated in its PCIe slot, a slot latch that is not engaged, a sagging card pulling on the slot, or a riser cable used in a compact case can all produce intermittent link errors. Reseating the card, confirming the retention bracket and latch, and removing any riser cable during testing are legitimate steps. Trying a different PCIe slot, where the motherboard provides one, and trying a different display cable and port, further narrow whether the fault follows the card, the slot, or the display path. If TDRs follow the card into a different machine with a different supply and driver installation, the evidence points more strongly at the card; if they stay with the original machine after the card is swapped, the evidence points at the machine around it.

Software and Workload Triggers That Look Like Hardware Faults

Not every TDR is caused by the driver, the supply, or the card. Applications can trigger the timeout by sending work the driver handles badly, by holding graphics resources across a display change, or by conflicting with overlays and capture software. A browser with hardware acceleration enabled, a video call application, a screen recording tool, and a game can interact in ways that none of them shows alone. Disabling hardware acceleration in the browser, closing overlay and capture software during a test, and checking whether the TDR happens with only one application running are all useful isolation steps.

Multi-monitor setups add their own triggers. Waking a second monitor, switching inputs on a television, changing refresh rates, or running monitors at mismatched refresh rates can all disturb the display path at the exact moment Windows renegotiates the link. If TDRs cluster around waking, switching, or plugging in a display, test with a single monitor, a single cable, and a standard refresh rate before suspecting the card. Similarly, a TDR that happens only in one title, after a title update, or only with a particular graphics setting such as ray tracing or a specific upscaling mode, points first at that title's interaction with the driver, and the useful evidence is whether other demanding titles behave the same way.

Background software also belongs on the checklist. Antivirus scanning during gameplay, a backup or indexing task starting under load, and a system update installing a driver in the background can all coincide with a TDR and mislead diagnosis. Checking the update history for a driver installed around the time the problem started, and checking whether the problem happens with background tasks paused, prevents a long hardware hunt for what was actually a scheduling collision.

A Diagnostic Sequence That Separates the Three Families

The most reliable way to separate driver, power, and hardware causes is to change one thing at a time and retest with the same trigger. The sequence below is ordered from least disruptive to most disruptive, so early steps do not destroy evidence needed by later ones.

Two rules make this sequence work. First, use the same trigger for every retest: the same application, the same scene or workload, and a similar run time. Testing with a different, lighter workload after each change proves nothing, because a lighter workload may not have triggered the TDR in the first place. Second, keep notes. A short log of what changed, when, and what happened turns a frustrating intermittent fault into a record that either identifies the cause or gives a repair inspection a precise starting point.

What to Record Before Seeking Inspection

If the sequence above does not resolve the problem, the record assembled during diagnosis is valuable. Note the driver version in use and whether rolling back changed anything. Note the Event Viewer entries, including event IDs and driver names, and whether they cluster around a particular trigger. Note temperatures under load, fan behaviour, and whether the card was cleaned recently. Note the power supply model and capacity, how the PCIe cables are connected, and whether adapters or a riser cable are in use. Note whether the fault follows the card or stays with the machine, if that test was possible.

That record also prevents a common waste of effort: repeating the same driver reinstall at the inspection stage. A repair inspection can then focus on what home diagnosis cannot easily confirm, such as power delivery under load, video memory behaviour, and board-level faults, rather than starting again from a blank description of "the screen goes black sometimes." Bringing the pattern, not just the symptom, is what turns an inspection into a diagnosis.

When to Stop and Seek Inspection

Stop home diagnosis and seek inspection when any of the following applies: the card shows physical damage, a burnt smell, or a visibly damaged connector; the machine fails to display anything at all, rather than recovering from a TDR; TDRs are accompanied by persistent visual artefacts that survive a driver reinstall and a cooling clean; the fault follows the card into a different machine; or the diagnostic sequence has been worked through without a change and further steps would require opening the card or testing with parts that are not available. Opening a card, removing its cooler, or replacing components without the right tools and static precautions can turn a diagnosable fault into additional damage, and is not required to establish that inspection is warranted.

For inspection, HK GPU Fix operates a shop at Dali Plaza, Shek Mun. The shop telephone is 2186 8010 and WhatsApp is 6558 6806. Repair pricing follows the site's published three-tier range of HK$400 to HK$2,800. No door-to-door service is offered, and there is no Mong Kok shop, so any visit is to the Shek Mun shop. A clear description of the TDR pattern, the Event Viewer entries, and the steps already tried will help the inspection start from the evidence rather than from scratch.

Observe each diagnostic step for several days to a week of normal use where possible before judging it; a single evening without a reset is weaker evidence than a week without one.

Prevention: Reducing Future TDRs After the Cause Is Found

Prevention depends on which family caused the fault, and generic advice that ignores the cause tends to fail. If the cause was driver-related, the preventive step is restraint: avoid installing every new driver on release day on a stable system, keep a note of the last stable version, and install one change at a time so a regression can be attributed. If the cause was power-related, the preventive step is to keep the delivery path direct and adequate: separate PCIe cables where the card design provides for them, no unnecessary adapters, and a supply matched to the manufacturer's recommendation for the whole system. If the cause was heat-related, the preventive step is regular, gentle cleaning of fans and intake filters, and keeping the case airflow path unobstructed, without blocking intake or exhaust vents.

Across all families, three habits help. Keep the system free of unnecessary overlay and capture software running during demanding work. Keep display connections simple and stable: avoid swapping cables and ports frequently, and settle on a single-monitor test configuration when a new display problem appears, before adding complexity back. And keep a short fault log, even after the problem is fixed, so a recurrence can be compared with the original pattern instead of being diagnosed from memory months later.

Frequently Asked Questions

Does a TDR mean my graphics card is dead?

No. A TDR means Windows reset the driver after a timeout. Driver, power, cooling, software, and hardware causes can all produce that event. A dead card more often fails to display at all, or shows persistent artefacts, rather than recovering cleanly again and again. Repeated TDRs deserve diagnosis, but a single TDR, especially after a driver update or a demanding workload change, is not by itself proof that the card has failed.

Should I reinstall the driver first, or check power first?

Start with the pattern. If the TDRs began immediately after a driver update, test a driver rollback or clean install first. If they began after a hardware change, a new monitor, or a move of the machine, check cables, seating, and power connections first. In either case, change one thing at a time and retest with the same trigger, so the result identifies the cause.

What does Event ID 4101 actually tell me?

It tells you that the display driver stopped responding and was recovered, and it names the driver involved. It does not, on its own, tell you whether the driver, the power supply, or the card was at fault. Its value lies in timing and repetition: a cluster of 4101 entries around one trigger is diagnostic evidence, while an isolated old entry is not.

Can a faulty power supply cause TDRs even if the computer does not shut down?

Yes. A supply that cannot meet a brief power spike can leave the GPU stalled long enough to trip the timeout, while the rest of the system keeps running. That is why TDRs tied to load transitions, such as a game scene loading, are worth treating as power suspects, and why the PCIe cable arrangement matters as well as the supply's rated capacity.

Is it safe to keep using a computer that shows occasional TDRs?

Occasional, isolated TDRs after a known trigger, such as a driver update, are usually recoverable, but repeated TDRs should not be ignored indefinitely. Each reset interrupts work and can corrupt an open file or a rendering task. If TDRs repeat, work through the diagnostic sequence, save work frequently in the meantime, and seek inspection if the pattern does not resolve or if artefacts, overheating, or failure to display appear.

Why do TDRs happen only in one game or application?

Because different applications stress the driver and GPU differently. One title may use a feature, a memory pattern, or a display mode that another title never touches, and a driver weakness may only appear under that combination. Testing other demanding applications helps separate a title-specific interaction from a general card or power problem.

Should I disable TDR to stop the black screens?

Disabling or greatly extending the timeout is not recommended as a fix. The timeout exists to recover the display instead of leaving it frozen indefinitely. Masking the reset hides the symptom while the underlying driver, power, or hardware problem continues, and can turn a recoverable reset into a full system freeze. Diagnose the trigger instead.

What information should I bring to an inspection for TDRs?

Bring the trigger pattern, the driver version and its history, Event Viewer event IDs and driver names, temperatures under load, the power supply model and cable arrangement, and a list of steps already tried with their results. That record lets inspection focus on board-level and load testing rather than repeating home diagnosis from the start.