You just saw STATUS_GRAPHICS_SESSION_TYPE_CHANGE_IN_PROGRESS (0xC01E05E8) and something on screen — usually a game, a remote desktop client, or a video app — froze or threw a DXGI error. This isn't a corruption error. It's Windows telling you: "I'm busy switching this session's display type, try again in a second."
The common real-world trigger: you clicked a UAC prompt, locked the workstation, or RDP'd in while a full-screen DirectX app was running. Windows has to tear down the console session's graphics context and rebuild it for the secure desktop. If anything tries to grab the display adapter during that window, you get 0xC01E05E8.
Step 1 — The 30-second fix: Wait, then retry
Seriously. Just wait. The session type change finishes in under a second on healthy systems. If you're seeing this because an app popped a dialog, close the dialog, wait three seconds, and try the action again.
If the app hard-locked, don't force-kill it yet. Killing it mid-transition can leave the display adapter in a weird state and you'll get this error on every subsequent launch until you reboot. Give it ten seconds first.
When this works: you saw it once, right after a UAC prompt or lock/unlock, and nothing has happened since. Done. Move on with your day.
Step 2 — The 5-minute fix: Reset the graphics driver
If the error keeps firing or the screen is still frozen, the display stack is wedged. There's a keyboard shortcut for this that Microsoft never advertises — it restarts the graphics driver without rebooting.
Win + Ctrl + Shift + B
You'll hear a beep, the screen flashes black for a second, and the driver reloads. Any full-screen DirectX app will likely crash (that's expected — you're yanking the rug out from under it). Close it, relaunch, and see if you're back in business.
This is the single most useful thing to know about GPU driver hangs on Windows 10 and 11. It works on NVIDIA, AMD, and Intel. Yes, it also carries over to Windows Server 2022 if you're running a workstation-class GPU there.
If you're on RDP
Disconnect the RDP session cleanly — don't just close the window. Use logoff from the remote session, or disconnect via the Start menu. Abrupt RDP drops leave the session in a half-switched state and the next connection hits the same error.
logoff
Then reconnect. If it still fails, restart the Remote Desktop Services service on the target:
Restart-Service TermService -Force
Heads up: that kills every active RDP session on the box. Do it from a console session or a second RDP connection if others are using it.
Step 3 — The 15-minute fix: Kill the stuck session owner
Still broken? Something is holding the display adapter open and refusing to release it. Nine times out of ten it's one of these three processes:
dwm.exe— Desktop Window Manager, the compositorwinlogon.exe— handles the secure desktop / UAC transition- Your actual GPU driver helper (e.g.,
nvcontainer.exe,atiesrxx.exe)
Open Task Manager (Ctrl+Shift+Esc), hit the Details tab, and find dwm.exe. Right-click, End Task. Windows will immediately respawn it — you'll see the screen flicker and the taskbar redraw. That's normal. Now try your app again.
Don't kill winlogon.exe unless you want a bugcheck. Literally. It'll bluescreen the box.
Check the Event Log for the real story
Open Event Viewer and look under Windows Logs > System for Event ID 4101 from source Display. That's the "display driver stopped responding and has recovered" event — a TDR timeout. If you see a cluster of those, you've got a deeper driver problem, not a one-off session switch.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Display'} -MaxEvents 20
Step 4 — The nuclear option: TDR delay registry tweak
If you're hitting 0xC01E05E8 repeatedly on the same machine, and Event ID 4101 shows up alongside it, your GPU is timing out during the session switch. Windows has a default Timeout Detection and Recovery window of 2 seconds. On busy VMs or underpowered GPUs (looking at you, Intel UHD 620 on a KVM guest), 2 seconds isn't enough.
Bump it. Edit this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
Add a DWORD called TdrDelay, set it to 10 (decimal). If you're on a VM or a RemoteFX host, also add TdrDdiDelay and set it to 10. Reboot.
Don't go higher than 10. Anything above that and you're hiding a real driver bug — a hung GPU that never recovers is worse than one that resets.
Undo this if it doesn't help. It doesn't fix anything on its own; it just buys the driver time to finish what it's doing.
What doesn't help (skip these)
- Reinstalling Windows. Overkill. This error is a timing issue, not corruption.
- SFC / DISM. Won't touch it. The system files aren't the problem.
- "Clean" driver reinstall with DDU. Only worth it if Event ID 4101 is flooding your log. Otherwise you're just burning an hour.
- Disabling hardware acceleration in every app. Treats the symptom, tanks performance everywhere, and the underlying session switch will still fail.
When to escalate
If you've done all of the above and 0xC01E05E8 is still appearing daily, you probably have one of these:
- A known-bad driver version. Roll back one or two releases — the newest isn't always the best, especially on NVIDIA 5xx series and AMD Adrenalin point releases.
- A failing GPU. Run
dxdiag, check the Display tab for driver timeout entries, and watch GPU temps under load. - A virtualization host with the wrong GPU passthrough config. Check your hypervisor's display adapter settings — RemoteFX and GPU-P both have specific driver requirements.
Nine times out of ten, though, it's step 1. Wait, retry, and it's gone. The rest of this article exists for the tenth time.