Display 4101 Display driver stopped responding and has successfully recovered
Your screen went black for a second and came back. Windows recorded it, and if you go looking you will find either a Display 4101, or a cluster of nvlddmkm 153 entries with no description at all, or both. Almost everything written about these gets at least one thing wrong - the bugcheck they relate to, how to count them, or which sibling event actually matters.
What you are looking at
In Event Viewer the matching entries look like this:
Log Name: System
Source: Display
Event ID: 4101
Level: Warning
Display driver nvlddmkm stopped responding and has successfully recovered.Log Name: System
Source: nvlddmkm
Event ID: 153
Level: Error
The description for Event ID 153 from source nvlddmkm cannot be found...
\Device\00000104
Reset TDR occurred on GPUID:100What the error actually means
Windows gives the graphics card a deadline. When the GPU scheduler in Dxgkrnl.sys finds a task running past its budget, it tries to preempt it; if that wait expires - two seconds by default - it calls the display driver's reset routine, purges video memory, resets the GPU and redraws the desktop. The visible symptom is a flicker.
Event 4101 is the record of that succeeding. The name in the message is the display miniport driver, not your graphics card model: nvlddmkm for NVIDIA, amdkmdag or atikmpag for AMD, igfx for Intel.
Most write-ups say 4101 is the non-fatal version of 0x116 VIDEO_TDR_FAILURE. That is the wrong code.
Each recovered hang generates a 0x117 VIDEO_TDR_TIMEOUT_DETECTED live dump - a code Microsoft documents as one that can never be used for a real bug check, existing only to tag live dumps. 0x116 is the failure case: either the reset itself did not complete in time, or the rate limit was hit.
That rate limit is documented and worth knowing: six or more GPU hangs within one minute promotes the situation to a real bugcheck.
Reading the parameters
Event 4101 carries only the driver name. The useful detail is in which sibling event you have, because the Display provider defines a severity ladder that almost nobody catalogues.
| Parameter | What it holds |
|---|---|
| 4097 | "Display driver [name] detected and recovered from a failure. Some graphics operations may have failed." A partial recovery - an engine reset rather than a full adapter reset. Least severe rung. |
| 4101 | "...stopped responding and has successfully recovered." Full adapter TDR, recovery worked. The common one. |
| 4109 | "Application [name] has been blocked from accessing Graphics hardware." Windows cut off one process rather than resetting everything. The log counterpart of bugcheck 0x142. |
| 4113 | "...stopped responding and has been successfully disabled." Recovery gave up and the adapter was disabled. This is the alarming one, and it is routinely mistaken for 4101 because the first half of the sentence is identical. If you have 4113, stop treating this as background noise. |
| 4115 | "Display driver failed to start; using Microsoft Basic Display Driver instead." The driver will not load at all. |
| nvlddmkm 153 fields | Two insertion strings: a device object path such as \Device\00000104, and a status string such as Reset TDR occurred on GPUID:100. The device path is an object index, not a GPU identifier - and note that modern Windows uses that numeric form rather than the \Device\Video3 style quoted in older guides. |
What actually triggers it
A single NVIDIA recovery typically writes four Event 153 records in a few seconds - one each for ForcedReset, Resetting, Reset and Restarting. These are phases of one recovery, not four separate faults.
Anyone grouping by event ID and reporting the count is inflating their incident total roughly fourfold. Cluster by timestamp - records within a few seconds of each other are one event - and count clusters.
What actually causes the hang:
| Cause | How often | Detail |
|---|---|---|
| Driver bug or a damaged driver installation | Common | Either a regression in a specific release, or leftovers from upgrading in place across several versions. The most common cause and the cheapest to eliminate. |
| Windows Multi-Plane Overlay | Common | A compositing optimisation with a long history of causing flicker and timeouts on multi-monitor and mixed-refresh-rate setups. Under-known because the symptoms look like failing hardware. |
| Thermals, especially memory junction temperature | Common | Core temperature can look fine while VRAM runs far hotter. Aged thermal pads are a frequent cause on older cards. |
| Power delivery and transient spikes | Occasional | Modern GPUs draw brief spikes well above their rated power. A supply that is adequate on paper can dip on those transients. |
| Unstable overclock or undervolt | Occasional | Applies to factory overclocks too. An undervolt stable in benchmarks often is not stable at the low-load, high-clock states the desktop actually uses. |
| Failing VRAM or GPU silicon | Occasional | Produces artefacts alongside the timeouts, or timeouts that follow the card into another machine. |
| Physical link problems | Occasional | A poorly seated card, a marginal riser, a degrading slot. Check for WHEA-Logger entries in the same window. |
Narrowing it down
Establish the real incident count first, then decide whether this needs attention at all.
Pull both event sources with correct provider scoping
Event ID 153 is not unique - Microsoft-Windows-Kernel-Boot also uses it, and on a typical machine most ID-153 hits in the System log are boot telemetry, not GPU events. Always name the provider.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Display'} -EA SilentlyContinue |
Select-Object TimeCreated, Id, Message | Format-Table -AutoSize -Wrap
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='nvlddmkm'; Id=153} -EA SilentlyContinue |
ForEach-Object {
[pscustomobject]@{
Time = $_.TimeCreated
Device = $_.Properties[0].Value
Status = $_.Properties[1].Value
}
} | Format-Table -AutoSizeRead the timestamps and group anything within a few seconds into one incident. That gives you the number that actually matters.
Check whether you have a 4113
Look specifically for Event 4113 - "stopped responding and has been disabled" - among the Display entries.
4101 means recovery worked. 4113 means it did not and the adapter was shut off. The two read almost identically at a glance and mean completely different things. A single 4113 deserves more attention than a dozen 4101s.
Correlate against WHEA-Logger
Pull hardware errors from the same window and compare timestamps.
This is the strongest discriminator available in the log, because it is corroboration from an independent subsystem. Display timeouts alongside WHEA PCIe errors point at the physical link or the card, not at the driver.
Check what the card was doing
Log core temperature, memory junction temperature, board power draw and clocks with HWiNFO64, then check the readings at the timestamp of an incident.
Memory junction near its limit, or power draw hitting a hard ceiling at the moment of failure, identifies the cause immediately and saves a week of driver reinstalls.
Fixes, cheapest first
An isolated timeout after a driver install, a resume, or a crashing game is unremarkable and needs nothing. These apply when there is a pattern.
Clean-install the display driver
Remove rather than upgrade. Download from the vendor directly, boot into Safe Mode, run Display Driver Uninstaller with Clean and restart, then install. If the problem began after an update, install the previous release instead.
Disable Multi-Plane Overlay
Free, reversible, and it resolves a category of case that otherwise looks exactly like failing hardware.
reg add "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayTestMode /t REG_DWORD /d 5 /fTo undo:
reg delete "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayTestMode /fWatch outVideo playback may use slightly more power afterwards. That is the entire downside. Remove the value again if it makes no difference.
Address temperatures
Clean dust from the heatsink and case filters, and confirm the case has genuine through-flow. If memory junction temperature is the problem on an older card, replacing the thermal pads is the real fix - but check warranty status first, since it usually voids it.
Test the card elsewhere
The most conclusive test available. If the timeouts follow the card into another machine, the card is faulty. If it behaves elsewhere while a different card misbehaves in yours, the fault is in the board, slot or power supply.
When it is the hardware, not Windows
Signals that the card is genuinely failing:
- Event 4113 appears - recovery failed and the adapter was disabled.
- Visual artefacts before or during the timeout.
- The timeouts follow the card into a different computer.
WHEA-Loggerentries appear at the same timestamps.- Incidents cluster toward the documented five-in-sixty-seconds threshold that promotes this to a bugcheck.
- It persists after a clean driver install, at stock clocks, with good temperatures.
The only documented threshold anywhere in this area is the five-hangs-in-one-minute rule that turns recovered timeouts into bugcheck 0x116. Everything else is judgement. A reasonable escalation ladder: an isolated incident is noise, repeatable-per-session is worth investigating, daily-at-idle is a problem, and any 4113 means stop guessing and start substituting hardware.
Frequently asked
Why does Event Viewer say the description for Event 153 cannot be found?
Because NVIDIA never ships one. The registry key for the nvlddmkm event source exists but contains no message-file value at all, so Windows has nothing to render and falls back to printing the raw insertion strings.
This is not corruption, not a failed driver install, and not fixable by reinstalling. Every guide that treats that message as a symptom to be repaired is wrong. The information you want - the device path and the status string - is displayed underneath it regardless.
What does GPUID:100 mean?
Nothing you can act on. The widely-repeated claim that it identifies the 3D engine traces to forum posts rather than any NVIDIA documentation, and the value appears as 100 across essentially every report, on unrelated cards with unrelated faults - which is what a constant handle looks like, not a variable error code. Treat it as an identifier you cannot decode rather than a clue.
I have nvlddmkm 153 but no Display 4101. Is that a problem?
No, and it is more common than guidance suggests. A reset handled inside the NVIDIA driver can be logged by nvlddmkm without the graphics kernel ever logging a user-visible recovery. Advice to "check for a matching 4101" produces false negatives. Treat either source as sufficient evidence that a timeout happened.
Should I increase TdrDelay to stop these?
No. Microsoft is explicit that those registry keys exist for driver development and that end users should not manipulate them. Raising the timeout does not stop the GPU hanging - it just makes the freeze last longer before Windows intervenes, and it hides the evidence. If the card is hanging because it is overheating or losing power, the hang still happens.
How many of these are normal?
Microsoft's only documented number is the threshold that turns them into a crash: more than five hangs within one minute. Below that there is no official figure, and Microsoft's own guidance on 4101 says the event is informational and typically needs no action.
Practically: after a driver update or a game crash, one is fine. Several a day at idle is not. And remember to cluster NVIDIA's records before you count, or you will scare yourself with a number four times too large.
Related errors
- 0x00000116VIDEO_TDR_FAILUREThe GPU stopped answering and Windows gave up waiting. Driver, heat, power, or a dying card.
- GuideLiveKernelEvent Codes Explained (117, 141, 124 and the rest)Reliability Monitor's 'Hardware error' entries. No crash, real dump file, poorly documented codes.
- WHEA-Logger 17A corrected hardware error has occurredHardware reported an error and recovered. One is noise. A burst of them is a warning.