[BUG] Claude Desktop (Windows) — GPU process crash leaves main process hung, requires 'Repair' to relaunch

Built from direct inspection of Windows Event Viewer + the app's own main.log, not from memory/self-report.

Environment

• App: Claude desktop app, version 1.24012.9 (MSIX package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), Electron/Node 24.18.0
• OS: Windows 11 Pro, build 10.0.26200 (26200), 64-bit
• Machine: ASUS TUF Gaming A16 (FA617NT), 16 GB RAM
• GPU: hybrid/switchable graphics, confirmed via Win32_VideoController — dedicated AMD Radeon RX 7700S (~4 GB VRAM) + integrated AMD Radeon(TM) Graphics (~512 MB), driver 32.0.11036.4002 (dated 2025-01-23 — no driver update in ~18 months). Worth flagging explicitly: hybrid-GPU switching between the dedicated and integrated adapter is a known trigger class for Chromium/Electron GPU-process crashes, and is directly relevant to what's below.

Summary

The Claude desktop app has become completely unresponsive twice in three days — 2026-07-25 and 2026-07-27 — both times with the identical failure signature: Electron's GPU process crashes, and instead of recovering (which Chromium normally does automatically), the main process goes silent and never comes back on its own. Both times, killing and relaunching wasn't enough on its own — the app needed Settings → Apps → Claude → Repair before it would launch successfully again. No Windows-level crash report (Application Error / Windows Error Reporting) is ever generated for Claude.exe — confirmed via Get-WinEvent across the full 14-day retention window, zero matches — so whatever is happening is entirely inside Electron's own process management, invisible to Windows' standard unhandled-exception path. That also explains the inconsistent Task Manager behavior across the two incidents (a genuinely wedged process with no crash dump doesn't always present the same way).

The bug: GPU process crash → main process hangs silently, no recovery, no further logging

Both occurrences, identical signature, from %APPDATA%\Claude\logs\main.log:

Incident 1 — 2026-07-25, 18:56:56 ("it needed to be terminated in Task Manager and then repaired"):

GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Log goes completely silent immediately after — no further output of any kind, not even the ~30-60s periodic process-memory heartbeat that runs continuously the rest of the time — until the next Starting app entry at 19:05:26: an 8.5-minute gap with zero logging, no beforeQuit/onQuitCleanup sequence, i.e. not a clean exit.

Incident 2 — 2026-07-27, 18:08:09 ("it didn't appear in Task Manager, so I had to restart the computer"):

GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Same signature, same exact exit code. Log again goes completely silent — until Starting app at 18:26:15, an 18-minute gap. Windows' own record shows LastBootUpTime = 2026-07-27 18:21:44 — I restarted the whole computer roughly 13 minutes into the hang, and Claude auto-relaunched ~5 minutes after that reboot completed. No Windows-level Display/TDR event (Get-WinEvent -ProviderName Display) fired in this window, so this doesn't read as a driver-level timeout/reset that Windows itself detected — it reads as Chromium's GPU process dying and the main process failing to recover or exit cleanly, rather than a full graphics-driver crash reaching the OS.

Read: a GPU-process crash is normally recoverable in Electron/Chromium (it respawns the GPU process automatically). Here, on both occasions the main process instead went completely unresponsive with zero further activity logged — a genuine hang, not a clean exit — consistent with the app being gone/unresponsive with nothing usable to interact with.

The compounding problem: recovery requires an OS-level "Repair," not just a relaunch

In both incidents, a plain relaunch after the hang wasn't sufficient — it took Settings → Apps → Claude → Repair (which resets the MSIX package's local cache/registration) before the app would start cleanly again. That's arguably the more important half of this report independent of the GPU root cause: whatever local state (lock file, IPC socket, session-restore cache under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\...) survives an ungraceful exit is leaving the app unable to start normally, rather than degrading to "start fresh."

Suggested areas to investigate

1. GPU process crash recovery on hybrid-graphics systems. exitCode: 101457950, identical both times, on a laptop with a dedicated AMD Radeon RX 7700S + integrated AMD graphics — worth checking whether Chromium's GPU-process auto-restart is failing to fire, or firing into a deadlock, specifically around GPU switching on this class of hardware. Graphics driver is 18 months old (32.0.11036.4002, 2025-01-23); not confirmed as the cause, but worth ruling in/out given how directly hybrid-GPU switching maps to this crash class.
2. Main-process watchdog. In both incidents, the main process produced zero further log output for 8-18 minutes after the GPU crash — no heartbeat, no exit. A watchdog that detects "no event loop activity for N seconds" and force-restarts the renderer/GPU pipeline (rather than leaving the whole app silently wedged) would turn this into a visible, recoverable failure instead of one requiring a full OS reboot.
3. Why no Windows crash report is ever generated. Confirmed zero Application Error/Windows Error Reporting events for Claude.exe across 14 days despite two genuine hangs — if the main process is truly wedged rather than exited, it should be crash-dumpable (Electron supports this); right now there's no artifact at all to hand to support beyond main.log.
4. Recovery from ungraceful exit shouldn't require an OS-level Repair. Whatever local state gates a clean relaunch after an abrupt termination should degrade gracefully (clear/rebuild automatically) rather than needing the user to go through Settings → Apps → Repair.

Evidence basis

• Get-WinEvent sweep of Windows Application, System, Microsoft-Windows-Kernel-Power, Microsoft-Windows-WER-SystemErrorReporting, Microsoft-Windows-Windows Defender/Operational, Microsoft-Windows-AppModel-Runtime/Admin, Microsoft-Windows-TWinUI/Operational, Display — 14-day window, 2026-07-13 through 2026-07-27.
• %APPDATA%\Claude\logs\main.log — direct grep for Starting app, GPU process gone, beforeQuit, timestamps around both reported incidents.
• Get-CimInstance Win32_VideoController / Win32_OperatingSystem / Win32_ComputerSystem for GPU, OS build, and machine model; Win32_OperatingSystem.LastBootUpTime to pin the 7/27 restart.

Note — a third, unrelated event ruled out

A separate event on 2026-07-26, 07:19 AM was initially mistaken for one of the two reported incidents but doesn't match either — worth naming so it isn't confused for a third occurrence if the raw logs are shared. That morning, the app logged a completely orderly shutdown (Electron's before-quit fired, every cleanup step completed normally) one second before Windows' own log shows a system-level reboot beginning (Kernel-Power event 109, "Power Action Reboot, Reason: Kernel API"). This looks like the app correctly responding to something rebooting the machine — not a crash. What triggered that reboot is unconfirmed (no Windows Update task fired in that window, so it isn't clearly attributable to an update). Two unrelated third-party services (Hotspot Shield's cmw_srv.exe, Razer's GameManagerService3.exe) also crashed in KERNELBASE.dll at that same timestamp and again at the 7/27 reboot — this looks like generic post-boot service-race noise on this machine (both crash identically at every full boot) and isn't Claude-specific.

2026-08-07 13:51:12   GPU process gone: { type:'GPU', reason:'crashed', exitCode: 101457950 }
2026-08-07 14:02:09   ... same
2026-08-07 17:01:28   ... same
2026-08-08 12:03:58   ... same
2026-08-08 12:24:41   ... same
2026-08-08 12:43:58   ... same

14:02:06  [Preview] Process spawned { pid: 34440 }            ->  crash  3 s later
17:01:10  [Launch] ... html-preview-...                        ->  crash 18 s later
12:03:33  [WarmLifecycle:preview] Warming up session ...       ->  crash 25 s later