What causes TDR driver resets while playing your game?

The GPU exceeded Windows' timeout and the driver reset — extreme GPU workloads (long draws, heavy compute), driver bugs, overclocks and thermals on player machines; the game often crashes or hangs with the reset.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix “Display driver stopped responding and has recovered” (TDR) Crashes During Your Game

Quick answer: Reduce worst-case GPU work per frame, survive device-loss where the engine supports it, and use hardware-clustered telemetry to separate your workload from their hardware.

TDR is Windows killing a GPU job that ran too long — the generic sibling of engine-specific device-lost errors. Your levers are workload, recovery, and diagnosis at fleet scale. Here they are.

How to fix it

1. Bound the worst frame

Split massive draws/dispatches, cap extreme effect settings, and precompile shaders — a frame that takes 100ms on your card takes multiple seconds on a low-end one, and 2 seconds is the default TDR line.

2. Handle device-loss when possible

Modern engines can recreate the device and resources after a reset — enabling/testing that path turns a hard crash into a hitch for driver-side flukes.

3. Read the fleet pattern

Telemetry by GPU model, driver version, and scene: your bug clusters by scene; their problem clusters by hardware — overclock/thermal cases show as single-machine repeat offenders.

4. Publish the player-side checklist

Driver updates, stock clocks, temperature checks (and the registry TdrDelay only as a last-resort diagnostic) — a good support article for the cases that are genuinely their rig.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Most of the time the fix is small. Seeing the failure clearly is the part that actually costs you.