| Previous | Next |
| WU_E_REPORTER_UNEXPECTED | DWM_E_COMPOSITIONDISABLED |
ERROR_HUNG_DISPLAY_DRIVER_THREAD
Display driver thread stopped responding
ERROR_HUNG_DISPLAY_DRIVER_THREAD is HRESULT 0x80260001 (signed decimal -2144993279, unsigned decimal 2149974017). AllStat, using the text from winerror.h, describes a display driver that stopped working normally and advises preserving work and restarting to restore full display functionality. The value has failure severity and belongs to the Windows graphics facility.
This result is evidence of a stalled graphics execution path, not proof that a particular application, GPU, driver module, power supply, or piece of hardware is the sole cause. It can be surfaced after Windows detects that progress is no longer being made in a display-driver thread. The useful investigation therefore starts with the preceding graphics workload and the operating system's recovery evidence rather than with the final HRESULT alone.
Where the failure appears
- A graphics application or system component waits for the display stack and receives the failure after the driver ceases to make expected progress.
- The desktop may freeze, blank, recover with a driver-reset notification, or remain degraded until restart, depending on whether timeout detection and recovery succeeds.
- A support layer may preserve only this HRESULT even though the System event log, WER report, live dump, or kernel dump contains the earlier and more useful cause.
Evidence to collect first
- Record the exact UTC time, foreground application, graphics API, adapter name, driver package version, Windows build, display topology, and whether the failure happened during startup, presentation, video decode, compute, sleep/resume, docking, or mode change.
- Export nearby System events from providers such as Display and
Microsoft-Windows-DxgKrnl. Preserve the original event IDs and messages instead of copying only a screenshot of the user notification. - Check for WER reports, live kernel reports, minidumps, or full dumps associated with the same timestamp. A dump can distinguish a stuck driver thread from a later application failure caused by device removal.
- Capture GPU workload and resource pressure immediately before the incident when reproduction is safe. Include temperature, power state, video-memory pressure, overclocking or undervolting, remote-session state, and recent driver or firmware changes.
How to interpret neighboring outcomes
A successful timeout-detection-and-recovery cycle can invalidate devices and allocations while allowing the desktop to continue. Applications may then report device-removed or adapter-reset results rather than ERROR_HUNG_DISPLAY_DRIVER_THREAD. Conversely, a bug check such as VIDEO_TDR_FAILURE or THREAD_STUCK_IN_DEVICE_DRIVER represents a system-level termination path and must be diagnosed from the dump parameters. Do not treat these outcomes as interchangeable merely because all involve the display driver.
Diagnostic sequence
- Reproduce with the smallest known workload and note whether the hang follows one application, one API path, one display output, or any GPU load.
- Return clocks, voltage, power limits, and driver tuning to vendor defaults before comparing results. A stable result at defaults is useful isolation evidence, not by itself proof of defective hardware.
- Test a clean vendor-supported driver package appropriate for the exact adapter and Windows version. Record the before-and-after package versions; avoid repeatedly replacing drivers without preserving the failing evidence.
- For developers, enable the relevant Direct3D debug layer where supported, validate resource lifetime and synchronization, and inspect long-running GPU work, fence waits, shader loops, residency pressure, and present behavior.
- If the failure occurs after sleep, docking, monitor hot-plug, HDR changes, or remote-session transitions, test that transition independently of the main workload.
Retry and recovery
Do not immediately resubmit the identical graphics workload in a tight loop. After a successful adapter reset, recreate the graphics device, swap chains, queues, synchronization objects, and GPU resources according to the API's device-loss contract. If Windows reports degraded display functionality or recovery does not complete, a controlled restart may be required. Repeated incidents require root-cause analysis; increasing timeout registry values can hide symptoms and should not replace investigation of the workload, driver, firmware, thermals, or hardware stability.
Telemetry and support guidance
Log the raw HRESULT, operation phase, adapter LUID or stable adapter identifier, driver version, device-removal reason when available, queue or fence associated with the last completed work, display configuration, and identifiers of related event-log or dump artifacts. Avoid collecting screen contents or user documents unless the diagnostic workflow explicitly requires them and has appropriate consent.
Practical scenario
A rendering application freezes while switching a video pipeline to fullscreen. Windows later reports ERROR_HUNG_DISPLAY_DRIVER_THREAD. The useful comparison is not simply “fullscreen failed”: the engineer correlates the timestamp with a DxgKrnl recovery event, finds that the last submitted queue never advanced its fence, reproduces only with one driver package and HDR output mode, and then validates the corrected presentation path. A blind application retry would merely trigger the same stalled work again.
References
- Microsoft: COM, filter, and graphics error codes
- Microsoft: WDDM timeout detection and recovery
- Microsoft: VIDEO_TDR_FAILURE bug check
- Microsoft: THREAD_STUCK_IN_DEVICE_DRIVER bug check
Looking for a different code? Search another status or error code.