Root cause: app-wide termination is Chromium's 'GPU process isn't usable. Goodbye.' kill switch, amplified by disabled hardware acceleration (minidump analysis)

Summary: root cause found via captured minidump

Follow-up to #89226 (and duplicates #81698, #83478, #82967, #80444, #81836). I captured the minidump that Claude Desktop's own crash pipeline normally uploads and deletes, and it identifies exactly why the whole app terminates:

FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye.

The dump is the browser (main) process (PID matches electron_main in [process-memory] log lines), dying with EXCEPTION_BREAKPOINT (0x80000003) — i.e. Chromium's own LOG(FATAL), not a graphics-driver fault. No driver DLLs are even loaded in the crashing process.

Mechanism (verified against Chromium 148.0.7778.280 sources, the version bundled in Electron 42.9.2)

GpuDataManagerImplPrivate::FallBackToNextGpuMode() walks the fallback chain (hardware GL → software GL → display-compositor-only). When fallback_modes_ is exhausted, it calls:

NOINLINE void IntentionallyCrashBrowserForUnusableGpuProcess() {
  LOG(FATAL) << "GPU process isn't usable. Goodbye.";
}

Why Claude Desktop is hit so much harder than Chrome: the app runs with hardware acceleration disabled (isHardwareAccelerationDisabled: true in config.json — in my case set manually, and the isHardwareAccelerationAutoDisabled config key suggests the app also sets it automatically after crashes). That means the GPU process already starts near the bottom of the fallback chain. When a page in the embedded browser calls navigator.gpu.requestAdapter() and the software GPU process crashes, there is (almost) nothing left to fall back to → Chromium deliberately terminates the browser process → every Claude Code session dies. On a default Chrome/Chromium with hardware acceleration on, the same child-process crash would just drop one fallback level and the browser survives.

So the auto-disable "safety" mechanism plus this kill switch form a feedback loop: each crash pushes users closer to the mode where the next crash is fatal to the whole app.

The GPU child process itself

The GPU process left no crash report at all, although the Crashpad handler demonstrably works (it produced the browser-process dump seconds later). That indicates the GPU child is not raising a normal exception; it is being terminated outright (TerminateProcess-style), consistent with the undocumented exit code 101457950 (0x060C201E) that appears in main.log. Root-causing the child crash needs instrumentation on Anthropic's side (or symbol-resolved Sentry dumps, which you already receive — the browser FATAL dump I captured locally is presumably in your Sentry as well, e.g. events around 2026-08-24 15:17 UTC for this machine).

How the dump was captured (reproducible for your engineers)

sentry-electron consumes and deletes Crashpad reports on the next app start, so the local Crashpad\reports directory is always empty post-mortem. I ran a detached watcher polling %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Crashpad and copying *.dmp out at 200 ms intervals, then triggered the crash by opening webgpureport.org in the in-app browser pane. One 35 MB dump was captured; happy to share it privately on request.

Environment

Claude Desktop 1.34493.1 (MSIX), Electron 42.9.2 / Chromium 148.0.7778.280, Windows 11 Pro 26200, AMD RX 7900 XT (but per #81698 the same signature occurs on NVIDIA; vendor-independent).

Suggested fixes, sharpened by the above

1. Investigate why the software GPU process dies on WebGPU adapter requests (your Sentry should have the child dumps if crash reporting covers the GPU process; if not, that gap is worth closing).
2. Break the fatal chain: when child-process-gone reports repeated GPU crashes, proactively disable WebGPU (--disable-features=WebGPU) instead of letting Chromium exhaust the fallback chain — or consider --disable-gpu-process-crash-limit semantics for a session-critical app.
3. Reconsider auto-disabling hardware acceleration as a crash remedy: it shortens the fallback chain and makes the "Goodbye" kill switch more likely, not less.

Workaround for affected users until then: launch with --disable-features=WebGPU (zero crashes since on this machine).