### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Summary The GPU process crashes and the entire app dies with it — the window disappears with no error dialog. It is not a startup crash: in one case th

[BUG] GPU process crashes with exitCode 101457950, taking down the whole app (MSIX 1.24012.9, Win11 26200)

Status Closed — duplicate

Maintainer reply None cached

Activity 5 comments · opened Jul 28, 2026 · closed Aug 15, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Summary

The GPU process crashes and the entire app dies with it — the window
disappears with no error dialog. It is not a startup crash: in one case
the app had been running for over 3 hours.

Environment

Claude Desktop 1.24012.9.0 (MSIX / Microsoft Store install)
Windows 11 Home, build 26200.8894
AMD Ryzen 7 7840HS, 31 GB RAM
Hybrid graphics: AMD Radeon 780M (driver 32.0.11034.1002, 2024-08-19)
NVIDIA RTX 4060 Laptop (driver 32.0.15.9636, 2026-04-22)
Display: internal, 1440x900 @ 120 Hz, scaleFactor 2, colorDepth 30,

colorSpace {primaries:P3, transfer:SRGB, matrix:RGB, range:FULL}

What happens

Last line in main.log before the process tree disappears, identical in
all three occurrences (exit code is byte-for-byte the same every time):

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

The cowork service observes the app dying at the same second:

[Server] Persistent RPC: connection ended: failed to read length: EOF

Occurrences

2026-07-26 16:31:37
2026-07-26 16:46:05
2026-07-27 18:52:25 (app had been up since 15:33:02)

No occurrence of "GPU process gone" exists anywhere in the retained logs
(main.log through main3.log, going back to early June) before 2026-07-26.
The onset is sudden.

What I ruled out

Not the Preview/Browser pane. "capturePreviewScreenshot failed" appears

immediately before all three crashes, but it also appears 240+ times
since 2026-06-11 without any crash, so it is background noise rather
than a trigger.

Not GPU selection. I set GpuPreference=2 for the package

(Claude_pzs8sxrjxfjjc!Claude) to force the NVIDIA dGPU; it crashed
again afterwards with the identical exit code.

Not the install. Reinstalling on 2026-07-26 did not prevent the

2026-07-27 crash.

No display driver TDR events (IDs 4101/4102) in the Windows System log.

Notes

No crash dumps were produced: the Crashpad folder contains only

settings.dat, no reports.

Autoupdate is disabled on this install ("[CCD-autoupdate] Disabled:

MSIX install"), so I cannot self-update to test a newer build.

No reliable reproduction. It happens during normal use, minutes to

hours after launch.

What Should Happen?

Expected behavior

A GPU process crash should be recoverable and should not terminate the
application. Chromium normally restarts the GPU process, and falls back
to software rendering if crashes repeat. Expected outcome: the window
stays open (possibly with a brief visual glitch or degraded rendering)
and the session continues.

Actual behavior

The entire process tree exits immediately. No error dialog, no crash
report prompt, no automatic restart — the window simply vanishes, and
any in-flight conversation state is lost. "GPU process gone" is the last
line written to main.log; the next line is a manual "Starting app" from
the user relaunching it.

Error Messages/Logs

Steps to Reproduce

No reliable reproduction — the crash occurs during normal use, minutes to
hours after launch, with no action on my part that I can correlate to it.
Below is everything I have instead.

WHAT I WAS DOING WHEN IT HAPPENED

Launch Claude Desktop (MSIX build, launched normally from the Start menu).
Use the app normally, with a local agent session open on a project

directory (a Next.js repo) and a dev server running on port 3000 via
the Preview feature.

At an unpredictable point — 47 seconds after launch in one case, 3h19m

after launch in another — the GPU process crashes and the whole app
exits with no dialog.

Time from launch to crash, for the three occurrences:
2026-07-26 16:31:37 — app launched 16:29 (~2 min)
2026-07-26 16:46:05 — app launched 16:45:19 (~47 s)
2026-07-27 18:52:25 — app launched 15:33:02 (~3 h 19 min)

The spread from 47 seconds to over 3 hours is why I cannot tie it to any
specific user action.

HOW TO CONFIRM IT HAPPENED (rather than how to trigger it)
Search main.log for "GPU process gone". The crash writes:

exitCode: 101457950

This exit code is byte-for-byte identical across all three occurrences,
which suggests a deterministic fault rather than random memory corruption.
It is the last line written before the process tree disappears.

Log path (MSIX install):
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log

NEGATIVE RESULTS — things that do NOT reproduce it

Forcing the discrete GPU does not prevent it. I set

GpuPreference=2 for Claude_pzs8sxrjxfjjc!Claude under
HKCU\Software\Microsoft\DirectX\UserGpuPreferences and it crashed again
afterwards with the identical exit code.

The Preview/Browser pane is not the trigger. "capturePreviewScreenshot

failed" precedes all three crashes, but it also appears 240+ times since
2026-06-11 with no crash — roughly a 1% correlation, i.e. background noise.

Reinstalling does not prevent it (reinstalled 2026-07-26, crashed 2026-07-27).
Rebooting does not prevent it (rebooted 2026-07-26 16:40, crashed 16:46).

WHAT MIGHT NARROW IT DOWN
The onset is sudden and recent: "GPU process gone" does not appear anywhere
in my retained logs (main.log through main3.log, back to early June) before
2026-07-26. Same app build, same machine, no driver update on that date.
If a server-side flag or a GPU-related feature gate changed around
2026-07-26, that would be the first place I would look.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.24012.9.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

4 Comments

bars-sekler · 1 month ago

Adding another data point — same version, same exit code, and I have logs pinpointing the exact crash moments.

Environment: Claude Desktop 1.24012.9.0 (MSIX), Windows 11 Pro, build 26200

Frequency: 3 crashes in one day, requiring a full cache clear + reinstall to get a stable session.

%APPDATA%\Claude\logs\main.log shows a GPU process crash at each incident:

2026-07-30 14:09:01 [info] GPU process gone: {
2026-07-30 14:16:21 [info] GPU process gone: {

(a third, earlier crash around 11:56 AM predates the log rotation from that restart, so the exact line wasn't preserved — but the same restart pattern shows up below)

Corroborating evidence from C:\ProgramData\Claude\Logs\cowork-service.log — the persistent RPC connection from claude.exe to the Cowork VM service dies with failed to read length: EOF at the same three timestamps, then the service is stopped and a fresh client reconnects minutes later:

| Disconnect (EOF) | Service restarted | Client reconnected |
|---|---|---|
| 11:56:18 AM | 12:24:37 PM | 12:25:39 PM |
| 2:09:01 PM | 2:14:07 PM | 2:14:18 PM |
| 2:16:22 PM | 2:17:59 PM | 2:18:04 PM |

Notably, the third crash happened only ~2 minutes after reconnecting from the second — a tight crash loop, not an isolated event. At both 2:09 PM and 2:16 PM, system free memory was healthy (~12GB free), so this doesn't look like an OOM condition on my end.

Possible trigger: was doing image-generation-heavy work at the time (building a presentation deck cover illustration), so GPU-accelerated rendering (Canvas/WebGL/image preview) triggering a driver crash seems plausible.

bjdiss · 29 days ago

Same fault here, and I think I have the trigger you couldn't isolate.

Matching your report exactly: exitCode: 101457950, app 1.24012.9 (MSIX), Windows 11
build 26200, no Crashpad minidump (only settings.dat), whole process tree exits rather than
the GPU process restarting. Different hardware — GTX 1660 SUPER + Intel UHD 770 on a desktop,
vs your 780M + RTX 4060 laptop — so this isn't vendor-specific.

The trigger: Cloudflare interstitials in the browser pane

You wrote that preview/browser pane use didn't appear to be the trigger, since
capturePreviewScreenshot failed appears 240+ times without a crash. I'd suggest that's correct
but too broad — ordinary browser pane use is fine; a Cloudflare bot-check page is not.

I hit this six times in one session, and every single crash was the browser pane loading a
Cloudflare "Performing security verification" interstitial. Ordinary pages in the same session —
Micro Center, Newegg, a vendor store, GitHub — never crashed it.

Reproduction, 6/6:

Open the browser pane at https://www.guru3d.com/review/review-bosgame-m5-ai-mini-desktop-ryzen-ai-395/page-18/

(any Cloudflare-interstitial URL should work; this one serves the challenge reliably)

The pane renders "Performing security verification"
Within ~10–60 s the GPU process dies and the app goes down

No interaction with the page is needed — loading it is enough. That would explain your variable
47-second-to-3-hour timings: it's not elapsed time, it's whenever a challenge page happens to
get loaded.

Crash times (2026-08-01, local): 10:28:17, 10:32:32, 11:08:18, 11:20:33, 11:22:51, 11:35:15

It is not the GPU — four configurations, all crash

I tested the same URL across four rendering configurations. All four crashed with the identical
exit code:

| # | Configuration | Verified by | Result |
|---|---|---|---|
| 1 | NVIDIA renders, NVIDIA drives display | baseline | crash |
| 2 | Intel iGPU preferred (Windows Graphics Settings), NVIDIA still drives display | GPU Engine perf counters — 23.41% 3D on the Intel LUID vs 13.75% on the NVIDIA LUID | crash |
| 3 | --disable-gpu, software rendering | nvidia-smi lists no Claude process; app moved to the Microsoft Basic Render Driver LUID, all 3D engines ~0 | crash |
| 4 | Monitor physically moved to the motherboard/iGPU output — NVIDIA entirely out of the display and presentation path | Win32_VideoController: Intel UHD 770 at 2560x1440@59, NVIDIA reporting no resolution | crash |

I also updated the NVIDIA driver mid-investigation, 32.0.15.9186 (2026-01-19) →
32.0.16.1088 (2026-07-21), six months newer. Reproduced identically on both.

Configuration 3 is worth dwelling on: it crashes with GPU rendering disabled entirely. The
GPU process still exists and still composites under --disable-gpu, so a fault there is
consistent — but it rules out the 3D/driver path completely. Configuration 4 rules out the
discrete GPU even being in the presentation chain.

Sentry event IDs

Eight captured during the crash windows, all logged as
type: 'Unknown', value: 'No message', stack: undefined. The queue at
%APPDATA%\Claude\sentry\queue\queue-v2.json is empty, so they uploaded:

0b06b9ae4c934acdbae024e889abaacf
3d163e283cb14f25af8df514eb017689
6177e6f4bc11476e9ef77829e6a0f9ce
7e08dff90edd42f1b16e74d59bf77152
8217b22140d84e06b3833c94061b35b0
9121e35fb5b44a1abd2373c390d228c9
a07382154f604fe984f1c5364a5e6082
aff9f6bcc88c47cfac306e55a323ace4

On the regression window

You noted GPU process gone doesn't appear in your logs before 2026-07-26. My first occurrence
is 2026-07-29 14:26:42, with nothing earlier in a log going back to May — consistent with your
onset estimate.

Possibly the same root cause

Several other open reports look like they may be this bug seen from different angles, all
involving the browser pane: #83117, #83028, #82967 (UnknownVizError on Browser tools), #82962
(RADAR_PRE_LEAK_64 on the built-in browser). If the Cloudflare-interstitial trigger holds, it
may unify them.

Speculation, clearly labelled

Cloudflare interstitials do aggressive canvas and WebGL fingerprinting to identify the renderer.
A plausible reading is that the probe reaches a path in the GPU process that faults regardless of
backing renderer. That's a guess. The observation worth acting on is the identical exit code
across four completely different rendering backends, which points at one failing code path rather
than anything driver-level.

damonpkuml · 28 days ago

Mine is : navigation to https://claude.ai/ failed with status code 403, then webgl show gpu process crashed 101457950.