[Windows] Desktop app: GPU process crash (exit code 101457950) kills entire app and all running sessions

[J-dev2]

Environment

• App: Claude desktop app 1.24012.9 (MSIX install), Claude Code (CCD) 2.1.219, bundled Node 24.18.0
• OS: Windows 11 Home, build 10.0.26200
• GPU: NVIDIA GeForce RTX 5080 Laptop GPU, driver 610.47
• RAM: 32 GB (~16 GB free at last crash per the app's own process-memory log line)

What happens

The desktop app fully crashes — the window disappears and every running Claude Code session is killed mid-flight. This has happened repeatedly (2026-07-25 and again 2026-07-27), always with the same log signature.

Evidence from %APPDATA%\Claude\logs\main.log

Both crashes have the identical signature — the Electron GPU process dies, and the app goes down with it instead of recovering:

2026-07-25 16:56:17 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

2026-07-27 11:56:26 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

After each GPU process gone line there is no recovery attempt logged — the next line in the log is a fresh app start (Starting app { appVersion: '1.24012.9', ... }) from when I manually relaunched.

Likely trigger: WebGL/WebGPU content

%APPDATA%\Claude\logs\unknown-window.log shows that in the final second before the 2026-07-27 crash, a renderer window emitted a burst of WebGL errors followed by a WebGPU adapter request:

11:56:25 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
(repeated ~20x, some with "when EXT_color_buffer_float is not enabled")
11:56:26 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127

The GPU process crashed at 11:56:26, immediately after.

Not a driver reset

The Windows System event log has no Display/nvlddmkm/Dxgkrnl TDR events at either crash time — the failure is contained to Chromium's GPU process, not a full NVIDIA driver reset.

Possibly related

2026-07-17: MoAppHang WER report on app version 1.22209.0.0 (claude.exe stopped interacting with Windows and was closed). May be a separate issue.

Expected behavior

A GPU-process crash shouldn't take down the whole app (Chromium normally relaunches the GPU process and repaints). At minimum, running Claude Code sessions should survive or auto-resume — losing all in-flight sessions and subagent work on every GPU hiccup is the painful part.

Impact

Repeated total loss of in-flight work: one crash killed multiple active sessions, including parallel subagent runs whose results were lost entirely.

[J-dev2]

4th occurrence — 2026-07-29 23:36:41 EDT, with the clearest trigger trace yet

Environment: app 1.24012.9 (MSIX), Node 24.18.0, Windows 11 Home 26200, RTX 5080 Laptop (driver 610.47), 32 GB RAM.

What happened

The Electron GPU process crashed and the entire app exited with it, killing every in-flight
session. Same exit code as the 2026-07-25 and 2026-07-27 occurrences — this is the 4th.

2026-07-29 23:36:41 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-07-29 23:45:05 [info] Starting app {
  appVersion: '1.24012.9',
  isPackaged: true,
  platform: 'win32',
  arch: 'x64',
  nodeVersion: '24.18.0'
}

No recovery attempt — the next line in main.log is a fresh app start ~8 minutes later (manual
relaunch). There is no renderer-crash or OOM line: [process-memory] sampling showed a flat
~1.4 GB tree RSS against 18.6 GB free system memory, so memory pressure is ruled out.

Not a driver-level TDR either: no nvlddmkm / Dxgkrnl events in the Windows System event log at
the crash time on any of the four occurrences. The fault is contained to Chromium's GPU process.

Trigger — the last second before death (unknown-window.log)

This is the clearest trace of the four. In the final ~1 s a window did WebGL float-buffer work,
then requested a WebGPU adapter, and then the GPU instance was reported gone:

23:36:40 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
                (x19, several specifically "when EXT_color_buffer_float is not enabled"
                 and "when EXT_color_buffer_[half_]float is not enabled")
23:36:41 [warn] The powerPreference option is currently ignored when calling requestAdapter()
                on Windows. See https://crbug.com/369219127
23:36:41 [warn] A valid external Instance reference no longer exists.

A valid external Instance reference no longer exists. is a Dawn/WebGPU message and is the last
line written before the process death — i.e. the WebGPU instance was invalidated at the moment the
GPU process died.

Suspected repro shape: a window doing WebGL float-texture work
(getInternalformatParameter against float internalformats without EXT_color_buffer_float) that
also calls requestAdapter() for WebGPU. On this machine that means an artifact / preview / in-app
browser-pane page rendering canvas or 3D content. Every one of the four crashes was preceded by
WebGL+WebGPU activity in an app window.

Impact: because the app exits rather than restarting the GPU process, every concurrent session
dies. On this machine that is routinely 3–6 sessions of in-flight work.

Requests: (1) treat GPU-process death as recoverable — respawn it instead of taking the app
down; (2) if WebGPU/WebGL content in an app window can destabilise the shared GPU process, isolate
or software-fallback it.

[keihoag]

same crash on totally different hardware, so this isnt a driver thing.

• GPU: RTX 5090 (desktop), driver 610.74
• OS: Windows 10 Pro 19045
• CPU/RAM: Ryzen 7 2700X, 64gb
• App: Claude Desktop 1.24012.9 (MSIX), node 24.18.0

youre on a 5080 laptop / 610.47 / Win11, im on a 5090 desktop / 610.74 / Win10, and we get a byte-identical crash. two cards, two driver branches, two windows versions, so its the app.

crashed 2026-07-30 08:53:29, ~17 min into the session:

2026-07-30 08:53:29 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

unknown-window.log has your exact sequence in the last second, ~16 of these then it dies:

[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
[warn] A valid external Instance reference no longer exists.

main.log goes silent after that until i relaunched 6 min later, so the whole app died, took my running Claude Code session with it.

stuff i ruled out: full DDU wipe + clean 610.74 reinstall (crashed again first launch), older driver branch, and i cant even test with hw accel off since MSIX wont let you launch the exe with --disable-gpu and theres no config toggle (grepped all the json). #81840 says it crashes with it off anyway. clearing the shader caches (GPUCache, DawnGraphiteCache, DawnWebGPUCache, plus the copies under Partitions\launch-preview-static\) cut it from ~7 crashes in 3 days to 1 in 2 days, but doesnt fix it.

the worse half: every time it goes down the package flips to Modified, NeedsRemediation and wont launch, "There's a problem with Claude. Reinstall the application". same as #81992 / #81836. and the obvious fix fails:

0x80073CF9, Install failed.
error 0x80070020: Creating file ...\app\resources\cowork-svc.exe failed.

0x80070020 is a sharing violation, and killing the Claude.exe procs doesnt help because whats holding that file is a service called CoworkVMService (auto start, runs cowork-svc.exe out of the package dir). so nothing looks like its running but the file is locked. took me way too long to find that.

this seems to work, elevated:

1. kill Claude.exe under WindowsApps (if you use the CLI dont kill .local\bin\claude.exe)
2. Stop-Service -Name CoworkVMService -Force, kill any leftover cowork-svc.exe
3. nuke the shader cache dirs above
4. Add-AppxPackage -Path <the ~246mb Claude-*.msix sitting in %TEMP%> -ForceApplicationShutdown -ForceUpdateFromAnyVersion
5. Start-Service CoworkVMService

back to Status: Ok. rebooting does not clear the package state, and reinstalling from claude.ai/download just gets you 1.24012.9 again so thats no help either.

can attach full main.log / unknown-window.log if it helps, theres no tokens in them.

[keihoag]

got a reliable repro, and its not a GPU load thing at all.

had Claude open my project page on itch.io in the in-app Browser pane, that rendered fine. then navigated to the edit page for it (the logged in editor/dashboard) and the whole app died about 45 seconds later. public page fine, edit page fatal, repeated it on purpose.

before that i'd been hammering shadertoy in a few tabs in chrome on the same machine, same 5090, same 610.74 driver, zero problems. so whatever this is its not raw GPU load or the driver, chrome drives the same chromium/ANGLE stack on the same card all day without flinching. its something that specific page does on load.

full sequence, unknown-window.log + main.log interleaved:

09:29:17 [info] [Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-1785428957309-0","name":"Browser...
09:30:01 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
09:30:01 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_[half_]float is not enabled
09:30:01 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
09:30:01 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
09:30:02 [warn] A valid external Instance reference no longer exists.
09:30:02 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
09:30:02 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

two bits i havent seen mentioned in this thread or the related ones:

• the OTS / WOFF 2.0 font parse error right before it goes. "size of decompressed WOFF 2.0 is less than compressed size" is a corrupt/misdecoded webfont, and it lands in the same second as the WebGL errors.
• CONTEXT_LOST_WEBGL: loseContext trailing the crash.

app went from 11 processes to 2, took my running Claude Code session with it again, and the package flipped straight back to Modified, NeedsRemediation so it wouldnt relaunch until i ran the CoworkVMService dance from my earlier comment.

if anyone else wants to try reproducing: point the in-app Browser pane at a logged-in editor/dashboard page on a site rather than a public one. thats the difference that did it for me, and i dont think you need anything GPU heavy at all.

[cmjdev-25]

Adding a data point with forensics that may help: 4 identical crashes in ~24 hours on this machine — desktop 1.24012.9 (MSIX Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), Windows 11 Home 10.0.26200, 32 GB RAM, NVIDIA RTX 4060 Ti. Same signature as OP in %APPDATA%\Claude\logs\main.log every time:

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

with the main process dead the same second (the Cowork VM service log shows the app's RPC pipe EOF within ~250 ms). Each crash killed 3–4 running Claude Code sessions mid-turn, and one killed a 5-agent workflow moments after it spawned (journal: 5 started, 0 results).

Crash timestamps (local, US Central): 2026-07-30 22:40:08, 2026-07-30 22:52:22, 2026-07-31 11:18:00, 2026-07-31 11:50:02.

Trigger correlation — Browser/preview pane. In all four crashes, the pane was being opened or driven seconds before the GPU death (cross-referencing main.log with the session transcripts' tool calls):

preview activity	GPU gone	gap
22:39:56 session calls preview_start; 22:39:58 [PreviewContext] Opened preview user tab + [Preview] Created browser preview	22:40:08	10–12 s
22:52:08 session calls preview_start; 22:52:10 [Preview] Created browser preview	22:52:22	12–14 s
11:17:27 session calls preview_stop, then 11:17:44 navigate + 11:17:55 get_page_text (re-driving the pane; a next build was also running)	11:18:00	5–16 s
11:49:58 [Preview] Created session preview context { totalContexts: 2 } — UI auto-restoring the preview of an already-finished session; no build, light load	11:50:02	4 s

Update — exact repro URL identified. Cross-referencing the session transcripts: in all four crashes the pane was loading https://one.dash.cloudflare.com/ (the Cloudflare Zero Trust dashboard — Turnstile-protected, WebGL/canvas-heavy): preview_start to that URL at 22:39:56 → crash 22:40:08; preview_start again at 22:52:08 → crash 22:52:22; navigate to it at 11:17:44 → crash 11:18:00; and the 11:49:58 event was the UI restoring that session's preview context, whose last URL was that same dashboard → crash 11:50:02. So on this machine, opening one.dash.cloudflare.com in the pane is a 4-for-4 reliable kill, including via session-preview restore. This lines up exactly with the Cloudflare/Turnstile repros in #80483 / #80978. Meanwhile a different session made 175+ Browser-pane tool calls against localhost dev-server pages the same day with no crash landing on its timestamps — plain localhost content seems mostly tolerated. Consistent with #81275 / #81398 / #81578; and #81275's WARP-software-rendering repro suggests GPU vendor/driver is irrelevant.

Nothing reaches telemetry, it seems: no WER Event 1000, no crash dump for claude.exe, no display-driver TDR events at any of the four times, and the local Sentry queue (...\Claude\sentry\queue-v2.json) looks empty afterward.

The operationally worst part — the app can't relaunch after the crash. Microsoft-Windows-AppXDeploymentServer/Operational shows that after each abnormal exit, every launch click starts RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption — ~31 seconds each (incl. "Trying to repair ACLs … repaired successfully") — which finishes "successfully" but the app still never appears; the user just sees the "needs to be repaired / still running" dialog again. On 07-30 Windows escalated by itself to a full RepairPackageOperation (re-downloaded the .msix from downloads.claude.ai), whose final Register step failed with 0x80073D02 (package in use). Settings → Apps → Claude → Repair can never succeed because the packaged service CoworkVMService is StartType=Automatic and is already running from boot, so the package is always "in use" even right after a reboot — this is exactly #73694. There is also no Terminate button on the Advanced options page for this app.

The only recovery that works (verified 3×, ~6 seconds): re-run the installer .msix. Its initial Remove with PreserveApplicationData fails with 0x80073CFA, but the subsequent Add with ForceApplicationShutdownOption, ForceUpdateFromAnyVersion succeeds and the app launches immediately. Stopping the service first (Stop-Service CoworkVMService -Force elevated) should also unblock the Settings-Repair path.

What survives: user data and all session transcripts made it through all four crashes (every session .jsonl ends in valid JSON and resumes cleanly) — the damage is confined to the GPU process and the package registration state.

Happy to provide main.log, C:\ProgramData\Claude\Logs\cowork-service.log, and a Microsoft-Windows-AppXDeploymentServer/Operational export covering all four windows.

[gs-imak]

Same setup here, Claude Desktop 1.24012.9 (MSIX), CCD 2.1.219, Windows 11 Pro 10.0.26200, 32GB RAM.

Got hit twice on 2026-08-02, about 11 minutes apart. Both times main.log shows GPU process gone: {type: 'GPU', reason: 'crashed', exitCode: 101457950} and then the log just ends, whole app gone, no error dialog. First one at 20:22:43, a few minutes after I kicked off 3 background subagents (the session also had a bunch of big screenshots in it). Second one at 20:33:19, six minutes after relaunching, right after dispatching 5 more subagents. The restarts logged two Sentry events, 5b75cdf3cfbf48b68be44d6f65141836 and ec9ac656d95a4e539991f65a2a6fc4e4.

One thing that might help narrow it down. The next day the same machine ran a workflow with 4 subagents for 20+ minutes without any problem, but that UI is the compact progress tree and the transcript had no big images. So I don't think it's the number of subagents. Looks more like rendering load (several streaming panes plus lots of screenshots at once) or some bad GPU/driver state at that moment. Not memory either, the app's own process-memory line showed 17+ GB free seconds before it died.

Can pull more from main.log if that helps.

[cmjdev-25]

Our 4-for-4 turns out to be a third-machine confirmation of @keihoag's repro shape. The page our Browser pane was loading at every one of our four crashes was one.dash.cloudflare.com — the Cloudflare Zero Trust dashboard, i.e. exactly a logged-in dashboard SPA — including one crash where merely viewing an already-finished session auto-restored its preview context onto that URL (dead 4 seconds later). Meanwhile a different session drove 175+ Browser-pane tool calls against plain localhost dev pages the same day with no crash landing on its timestamps. Public/plain pages tolerated, logged-in dashboard fatal — now shown on a third hardware config (RTX 4060 Ti, Windows 11 Home 26200, 1.24012.9 MSIX).

@gs-imak yours is the interesting outlier: no Browser pane at all, just subagent dispatch with big screenshots and several streaming panes. If you're up for one more pull from the logs: unknown-window.log interleaved with main.log at 20:22:43 and 20:33:19 — specifically whether the final second shows the signature @J-dev2 and @keihoag both captured:

WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
The powerPreference option is currently ignored when calling requestAdapter() on Windows.
A valid external Instance reference no longer exists.

(± the OTS/WOFF2 font error keihoag saw). If that trio shows up on your crashes with no pane open, then the same WebGL+WebGPU→Dawn path is reachable from the app's own UI surfaces (streaming panes / large screenshot renders), not just Browser-pane web content — which would considerably widen where the fix needs to sit. If it doesn't show up, you may have found a second, distinct path to the same 101457950 exit.

Two smaller data points for the thread:

• Recovery: we independently converged on the same conclusion as keihoag's step list before reading it — Settings→Repair can never work because CoworkVMService (auto-start, runs cowork-svc.exe out of the package dir) keeps the package "in use" even straight after a reboot, and our AppXDeploymentServer log additionally shows every post-crash launch click burning ~31 s in a silent RepairAppRegistration cycle that "succeeds" without restoring launchability. Re-running the installer .msix recovered in ~6 s every time (its initial Remove fails 0x80073CFA, then the Add with ForceApplicationShutdown/ForceUpdateFromAnyVersion goes through). Third machine confirming that whole failure/recovery chain.
• Telemetry: our local Sentry queue (…\Claude\sentry\queue-v2.json) was empty after all four crashes — so @gs-imak's two Sentry event IDs above may be the only crash handles anyone from the team can actually look up from this thread.

Since keeping the pane closed (and specifically away from that dashboard): zero recurrences here — though usage since Friday has been light, so treat that as weak confirmation only.

[rgreasley]

Hit the identical signature today (2026-08-03) on a Windows Server 2025 VM — adding this since our environment differs from the reports above in a way that points at a possibly distinct trigger path.

Environment

• App: Claude Desktop 1.24012.9 (MSIX), Node 24.18.0
• OS: Windows Server 2025 Standard, build 10.0.26100, x64
• RAM: 8 GB total, ~1.4–1.6 GB free at time of crash
• GPU: none — Get-CimInstance Win32_VideoController returns no video controller at all on this VM, so Chromium has no real graphics hardware to fall back on

Trigger: both crashes happened within 1–2 seconds of opening a new Browser preview tab/session (an additional Chromium renderer + GPU compositing surface) while the system was already under memory pressure. Reproduced twice in a ~6 minute window.

main.log:

2026-08-03 13:00:47 [info] [Preview] Created browser preview { serverId: 'browser-preview-1785776447006-2' }
2026-08-03 13:00:48 [info] [process-memory] ... sys_free=1591MB/8191MB sys_free_raw=1591MB
2026-08-03 13:00:49 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-03 13:03:10 [info] Starting app { appVersion: '1.24012.9', ... }

No recovery attempt between the crash and the cold restart — same as reported above. Repeated identically ~3 minutes later after a manual relaunch, again ~1-2s after opening another Browser preview tab.

Crashpad: Crashpad/reports was empty after both crashes — no dump captured, consistent with what's described in #81836.

Given no-GPU-hardware + low-RAM is a different root condition than the hybrid-GPU-switching or WebGL/WebGPU-probe triggers described elsewhere in this thread and in #81836, it might be worth confirming whether the fix path covers a "no GPU adapter available" fallback (e.g. forcing software compositing rather than letting the GPU process attempt and crash) in addition to the hybrid-GPU and driver-related cases.

[J-dev2]

OP here. Adding a data point that cuts the other way from every report in this thread so far: a GPU-process crash on this same machine that the app survived.

Same environment as my original report — 1.24012.9 (MSIX), Node 24.18.0, Windows 11 Home 26200, RTX 5080 Laptop, driver 610.47, 32 GB.

2026-08-02 02:46:10 local — GPU process gone, but exitCode: 34, not 101457950:

2026-08-02 02:46:00 [info] [WarmLifecycle:preview] Warming up session local_8acca448-...
2026-08-02 02:46:10 [warn] [event-loop-stall] main process blocked for 4055ms (task none, total 33, cumulative 60069ms, rss 363MB)
2026-08-02 02:46:10 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
2026-08-02 02:46:11 [info] [WarmLifecycle:session] Starting idle timeout for local_8acca448-...

The app did not go down, and the GPU process was respawned. The app's own [process-memory] sampling shows the GPU child PID changing across the crash:

02:45:07  top=[... electron_gpu:64020:198MB ...]   <- before
02:46:10  top=[... electron_gpu:64020:206MB ...]   <- at the crash
02:47:07  top=[... electron_gpu:5904:171MB ...]    <- after, new PID

There is no Starting app line anywhere between 2026-08-01 21:14:46 and 2026-08-03 04:43:21, so this was not a relaunch — the same app instance kept running for roughly 26 more hours. No sessions were lost. Memory was not a factor either: 14.2 GB free of 32.5 GB, tree RSS 1.66 GB.

Why I think this is worth having in the thread: it shows the Chromium GPU-process respawn path is present and works in this app. So the "app exits instead of recovering" behavior everyone here is reporting is not a general absence of recovery — something about the 101457950 failure specifically takes the main process with it, while a 34 on the same build, same machine, same driver recovers cleanly. That narrows request (1) from my original post from "add recovery" to "find out why this one exit path bypasses the recovery that already exists."

What I cannot tell you about this one: whether the WebGL/WebGPU trio was present. unknown-window.log on this machine has no entries at all for 2026-08-02 — it jumps straight from 08-01 to 08-03 — so there is no renderer-side trace for this crash. I am not going to claim the trigger matched. The only nearby context in main.log is a [WarmLifecycle:preview] Warming up session 10 seconds prior, and a 4055 ms main-process event-loop stall in the same second as the death.

@cmjdev-25 your logged-in-dashboard repro matches my behavior change: since I stopped pointing the Browser pane at anything but localhost dev servers and moved external pages to a real browser, I have not had another 101457950. Light usage caveat applies to mine too.

Happy to attach main.log for the 08-01 to 08-03 window if the 34 case is useful to compare against; there are no tokens in it.