Start Building

Unreal Engine 5.5 GPU Crash DXGI_ERROR_DEVICE_REMOVED - Driver and RHI Stability Fix

You are editing, playing in editor, or running a packaged build when the viewport freezes, the screen blinks, or Unreal closes with a log line similar to:

  • DXGI_ERROR_DEVICE_REMOVED
  • D3D device lost
  • GPU crash / Render thread exception
  • Windows Display driver stopped responding and has recovered

This pattern means the GPU driver reset the device or Windows stopped the graphics stack long enough for Unreal to lose the D3D12 or Vulkan device. It is not always a bad GPU—often it is timeout, VRAM, driver bugs, or settings that push the card past what the driver allows.

Why this happens

Typical causes, alone or combined:

  1. TDR (Timeout Detection and Recovery) – A single frame or dispatch runs too long; Windows resets the GPU. Common with heavy shaders, Lumen, Nanite, or ray tracing on first compile or big view changes.
  2. Driver quality – A specific Game Ready / Studio build may regress Unreal; the next hotfix fixes it.
  3. VRAM exhaustion – Editor plus high-res viewport, path tracer experiments, or too many 4K textures can allocate past stable limits.
  4. Overclock / undervolt – Unreal is sensitive; stock clocks are the sanity baseline.
  5. RHI mismatch – D3D12 default path hits a driver bug that D3D11 or Vulkan avoids, or the opposite on some laptops.
  6. Multi-GPU / hybrid graphics – Wrong GPU selected for Unreal, or optimus handing off mid-frame.

Fix 1 - Update or roll back the GPU driver (do this first)

  1. Note your GPU model and whether you use NVIDIA, AMD, or Intel Arc.
  2. Install the latest Studio or Game Ready build from the vendor clean install option when offered (removes old profiles).
  3. If the crash started right after an update, roll back one version and retest the same map and PIE session.

Verification: Launch Unreal, open the problem level, run 30 minutes of PIE or Sequencer scrubbing without a device-lost dialog.

Fix 2 - Reduce GPU load before touching the registry

In Unreal Editor:

  1. Engine - Rendering scalability: drop to Medium or Low temporarily.
  2. Disable Ray Tracing in Project Settings - Platforms - Windows - Default RHI / rendering if you do not need RT for this project.
  3. Turn off Path Tracer and experimental MegaLights tests while debugging.
  4. Close second monitors, browser with hardware decode, and GPU screen recorders—they share VRAM and scheduling.

Pro tip: If crashes happen only on first Lumen or Nanite warmup, let the level sit once after load; if they repeat forever, it is not a one-time shader compile—it is sustained pressure. See Unreal Engine 5.5 Nanite and Lumen Stutter in Large Open Levels - How to Fix for related scalability moves.

Fix 3 - Try a different default RHI

  1. Edit - Project Settings - Platforms - Windows - Default RHI (or use -d3d11 / -vulkan on the editor shortcut for a quick test).
  2. D3D11 is slower on some features but can eliminate a D3D12-only driver path crash.
  3. Vulkan helps on some AMD setups; test packaged builds too, not only editor.

Verification: Same repro steps; if only one RHI crashes, document that for your team and ship with the stable RHI until drivers catch up.

Fix 4 - Address VRAM and texture pressure

  1. Open a memory view if you use PIX or your vendor overlay—watch dedicated VRAM during PIE.
  2. Reduce texture max size on hero assets, use streaming budgets, and avoid uncooked 8K experiments in editor viewport.
  3. For virtual production or cinematics, consider lower render resolution while iterating.

Fix 5 - TDR delay (Windows, advanced)

If logs show long GPU work before device removed and you cannot reduce load yet (e.g. offline movie render):

  1. Research TdrDelay and TdrDdiDelay under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers.
  2. Backup the registry; incorrect edits can affect stability. Many studios use modest increases only on dedicated workstations, not player machines.

Prevention: Prefer splitting renders and lowering quality over relying on long TDR delays on end-user PCs.

Fix 6 - Laptop and hybrid graphics

  1. Windows - Graphics settings - set UnrealEditor.exe and your game .exe to High performance (discrete GPU).
  2. Disable MPO-related issues are rare but if external monitor crashes only, search for known vendor issues with your dock / cable.

Alternative fixes

  • Disable third-party overlays (Discord, FPS tools) for isolation.
  • Verify files on Epic Launcher if engine binaries corrupt after a bad update.
  • Create a blank 5.5 project with same RHI—if only your project crashes, merge binary search plugins and content heavy levels.

Verification checklist

  • [ ] 30+ minute editor or packaged session without device removed
  • [ ] Output log free of repeating D3D errors after warmup
  • [ ] Same repro on stock GPU clocks
  • [ ] Stable on the RHI you plan to ship

Prevention

  • Pin a known-good driver version in team docs for production milestones.
  • Automate light GPU sanity tests on CI machines if you have headless cook farms (different issue, but same discipline).
  • Budget Nanite, Lumen, and RT per Performance Optimization and Profiling in the Unreal guide.

FAQ

Does this mean my GPU is dying?
Not necessarily. Verify with other D3D12 apps and vendor diagnostics. Persistent artifacts or crashes everywhere point hardware; Unreal-only points software path.

Should players edit TdrDelay?
No for shipping games. Fix content and scalability defaults instead.

Does Vulkan fix all AMD issues?
Sometimes. Test your content; no single RHI wins on every driver.

Related links

If this stopped the random GPU resets, bookmark it for your team wiki and share it with anyone else hitting DEVICE_REMOVED on 5.5.