DXGI_ERROR_DEVICE_HUNG 0x887A0006

DXGI_ERROR_DEVICE_HUNG 0x887A0006 usually means Windows reset your GPU driver after it stopped responding in a game or 3D app.

This crash tends to show up at the worst moment: mid-match, mid-render, right as a cutscene starts, with no warning. One second all’s smooth, the next you’re staring at a desktop and a message that looks like a hex password.

The good news is that this code is usually a stability problem you can pin down. The trick is to work from the outside in: fix the easy “signal noise” first, then clean up the driver layer, then change the workload so the GPU stops timing out.

What the error means and why it appears

DXGI is the Windows layer that sits between DirectX apps and your graphics driver. When an app sends a batch of commands and the GPU doesn’t finish in time, Windows can reset the driver to get your desktop back. That reset is called TDR, Windows’ timeout reset feature.

When TDR kicks in during a game or a heavy viewport, the app often can’t restore its graphics context. That’s when you see a “device hung” message and the program closes.

What you notice	What it often points to	First thing to try
Crash right after loading shaders	Driver cache clash or a bad shader build	Clear shader cache, then verify files
Crash only in one game mode	One renderer path is unstable	Switch DX12 to DX11, or lower RT
Crash after alt-tabbing	Overlay, capture hook, or fullscreen swapchain issue	Turn off overlays, use borderless
Crash during long renders	TDR timeout during a single heavy frame	Lower workload, then review TDR
Black screen plus driver reset in Event Viewer	Driver instability or power/clock swings	Revert GPU to stock clocks

You’ll also see this code paired with other clues: an Event Viewer entry about a display driver restart, a game log that mentions “device removed,” or a crash reporter that points at a DirectX call.

DXGI_ERROR_DEVICE_HUNG 0x887A0006 fix checklist

Start here. These steps remove the most common triggers without touching the registry or swapping hardware.

Revert clocks to stock — Turn off GPU and CPU overclocks, including “factory OC” profiles and undervolt experiments.
Disable overlays — Switch off GeForce overlay, Steam overlay, Discord overlay, Xbox Game Bar, and any FPS counter.
Switch to borderless — Use borderless windowed mode to reduce fullscreen swapchain hiccups during alt-tab.
Cap the frame rate — Set an in-game cap or driver cap to cut power spikes and frame-time swings.
Lower ray tracing first — If the crash starts after turning on RT, drop RT effects before dropping texture quality.
Check temperatures — Watch GPU hot spot and memory junction temps during the crash scene.
Verify game files — Run the launcher’s file check to replace broken assets and shaders.

If you’re on a laptop with dual graphics, also confirm the game is using the discrete GPU. Windows Graphics settings can force a specific app to “High performance.”

Driver cleanup that fixes hidden instability

Driver updates can fix bugs, but a “normal” update can also leave old profiles, shader caches, and registry settings behind. When this error keeps coming back after updates, a clean driver install is worth the effort.

If dxgi_error_device_hung 0x887a0006 appears only after a new driver, rolling back one version is a clean test.

When a clean install is the right move

If the crash started right after a driver update, or if it happens across multiple games, treat the driver layer as the suspect. A full cleanup also helps when you’ve swapped GPUs or moved between driver branches.

Download two driver versions — Grab the newest stable driver and one older version that was solid for you.
Disconnect from the internet — This stops Windows Update from racing you with its own driver.
Use DDU in Safe Mode — Display Driver Uninstaller removes leftover files and profiles that normal uninstallers miss.
Install the driver with minimal extras — Skip optional overlays and add-ons at first; add them back only after the crash is gone.
Restart twice — One reboot after install, then another after Windows finishes device setup.

After the reinstall, test before you change any in-game settings. If stability returns, you’ve confirmed it was a driver state problem, not the game.

Two driver settings that often calm crashes

Set a steady power profile — In your GPU control panel, pick a mode that avoids aggressive clock bouncing during short loads.
Turn off experimental features — Disable driver beta toggles and testing switches until the system is stable.

Fixing dxgi_error_device_hung 0x887a0006 in games and editors

This code often shows up in DirectX 12 paths, ray tracing workloads, and scenes with heavy shader compilation. You’re not “making graphics worse” by adjusting these settings. You’re shaping the workload so the GPU finishes frames before Windows pulls the plug.

Renderer switches that change the crash rate

Switch DX12 to DX11 — Many titles let you pick the API in settings or via a launch option.
Toggle ray tracing off — Test with RT fully off, then add one effect back at a time.
Drop resolution scale — A small cut in internal resolution can remove a single heavy frame that triggers the timeout.
Lower shadows and volumetrics — These two settings can spike GPU time in dense scenes.

Cache resets that stop repeat crashes

Shader and pipeline caches can get stuck in a bad state after a driver swap or a game update. Clearing them forces a clean rebuild.

Clear DirectX shader cache — In Windows Storage settings, use the temporary files cleaner for the DirectX cache.
Clear the game’s shader cache — Many games store it under Documents or AppData; check the game’s own folder names.
Delete config files once — If settings migrations keep breaking, removing the config can reset the renderer path.

In Unreal Engine and other editors, the crash can be linked to a single viewport feature. Turn off real-time rendering, drop preview quality, then re-enable features one by one. Start with ray tracing features, since they can create long frames that push the driver into a timeout.

Windows settings that reduce driver timeouts

Windows can be part of this story in two ways: background load that steals GPU time, or timeout rules that are too tight for a given workload. Start with the safe system steps, then treat registry edits as a last resort.

System checks that take minutes

Install Windows updates — Restart after updates so graphics components and drivers load cleanly.
Turn off background recorders — Disable capture apps, browser GPU acceleration for testing, and game recording tools.
Run system file checks — Use built-in tools like SFC and DISM if crashes started after a system glitch.
Try a clean boot — Start Windows with non-Microsoft startup items disabled to rule out hooks.

Last-resort TDR changes for long workloads

Microsoft documents TDR registry entries and notes they’re meant for testing and driver work, not as a routine tweak. Vendors also warn that registry edits can break a system if done wrong. If you’re doing long GPU renders or heavy baking jobs and you understand the risk, increasing the timeout can stop Windows from resetting the driver mid-task.

Create a restore point — Do this before any registry change so you have a rollback path.
Open Registry Editor — Go to HKLM\System\CurrentControlSet\Control\GraphicsDrivers.
Add TdrDelay — Create a DWORD (32-bit) value named TdrDelay and set a decimal value like 10 or 15.
Add TdrDdiDelay — Create TdrDdiDelay and set it to the same value.
Reboot and test — Run the exact workload that used to crash.

If the system becomes unstable, delete the added values to return to defaults. If games stop crashing only after raising TDR, you still want to hunt the root cause later, since timeouts are often a symptom.

Power, heat, and hardware checks that matter

When fixes above don’t change the crash rate, start treating this as a stability signal. A GPU can pass light games and still fail under a specific mix of load, heat, and power draw.

Quick hardware sanity checks

Reseat the GPU and power leads — Loose PCIe power plugs can trigger momentary dropouts under load.
Check PSU headroom — Sudden load spikes can trip a weak power supply even when averages look fine.
Test one RAM profile — Turn off XMP/EXPO for a test run to rule out memory instability.
Watch for hot spot spikes — A “normal” GPU temp can hide a high hot spot value that causes throttling.

Stability tests without chasing numbers

Run one stress test at a time and stop if you see artifacts, black screens, or driver resets. The goal is not a score. The goal is to reproduce the hang in a controlled way.

Run a GPU stress test — Use a known test app for 10–15 minutes, then repeat with a lighter load.
Log clocks and temps — Use a monitor tool to capture the moment of failure.
Try a small underclock — A minor core and memory reduction can confirm marginal stability fast.

If a tiny underclock stops the crash, treat that as a sign to check cooling, power wiring, or the card’s factory boost behavior. You can keep the underclock as a workaround while you sort out the root cause.

How to know you fixed it and keep it from returning

Once the crash is gone, keep notes on what you changed so you can repeat it later.

Retest the same scene — Use the same map, save file, or render that used to fail.
Add changes one at a time — Re-enable overlays, higher settings, or RT one switch at a time.
Keep a stable driver note — Write down the driver version that works so you can return to it.
Save a known-good config — Back up the game’s config folder after you confirm stability.
Watch after big updates — Major Windows updates and game engine updates can reset caches and profiles.

If the code returns months later, start again at the top of this page. Many repeats come from a new driver branch, a new overlay, or a new graphics feature toggle. Running the checklist in order keeps the process fast and keeps you from changing ten things at once.

If you still hit the crash across multiple games after a clean driver install and stock clocks, it may be time to test another GPU or power supply. At that point you’re no longer chasing settings. You’re checking stability at the hardware layer.

You’ll see the name of this code written in logs as dxgi_error_device_hung 0x887a0006. If you’ve made it this far, you now have a clean path to pin down why it’s firing on your system.