[BUG] Claude Desktop MSIX 1.24012.9: opening the in-app Browser pane crashes the whole app - GPU process exits with 101457950 (0x60C201E) on Intel HW, NVIDIA HW and WARP software rendering alike
Summary
Claude Desktop for Windows (MSIX package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc) dies entirely whenever the in-app Browser pane (Cowork browser preview) is opened or restored. The Chromium GPU process crashes with the same exit code every time — 101457950 (0x60C201E) — and the main process goes down with it (no quit handlers run, log just stops). Because open panes are restored from the active-servers store on relaunch, the app can enter a crash loop on startup (crash 63 seconds after a fresh start with no user action).
The crash is independent of the rendering backend: it reproduces identically on Intel Arc hardware rendering, NVIDIA hardware rendering, and pure software rendering (ANGLE d3d11-warp-webgl). This rules out GPU drivers and points at the app build itself (viz/readback path of the pane screenshot capture), possibly MSIX-specific.
Environment
- Claude Desktop MSIX
1.24012.9.0x64 (Claude_pzs8sxrjxfjjc), CCD/Claude Code 2.1.219 - Windows 11 Home 10.0.26200
- Hybrid laptop GPU: Intel Arc (iGPU) + NVIDIA RTX 4070 Laptop
- Drivers at time of repro: Intel
32.0.101.6881and32.0.101.8860(updated mid-investigation — no change), NVIDIA32.0.15.9144 - Multiple
--user-data-dirprofiles in use; crash reproduces in any profile (GPU stack is shared)
Crash signature (<user-data-dir>\logs\main.log)
2026-07-26 02:25:09 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
2026-07-26 02:25:09 [error] [CDPTools] Compressed screenshot failed {
error: [Error: UnknownVizError] { [message]: 'UnknownVizError' }
}
2026-07-26 02:25:09 [warn] [Preview] capturePreviewScreenshot failed: ...After the GPU process gone entry the log ends — no beforeQuit/willQuit, the whole app is gone. Nothing lands in Windows Event Log / WER (no faulting-module 1000 event), and Crashpad/ contains only settings.dat, no dumps.
Trigger correlation (same session, five crashes over one night): each crash follows Browser pane creation/restore within seconds, e.g.
2026-07-26 01:14:17 [info] [Preview] Created browser preview { serverId: 'browser-preview-...-1' }
2026-07-26 01:14:21 [info] GPU process gone: { ... exitCode: 101457950 ... }Crashes observed at 00:57:09, 01:14:21, 01:18:53 (63 s after app start — pane auto-restored from Updating active servers store { count: 2, ... }), 02:07:09, 02:25:09 — all with exitCode 101457950.
What was ruled out (each disproved by a live crash with the same exit code)
- Windows Settings → Apps → Repair/Reset (MSIX) — crash re-occurred 63 s after a successful repair; repairs mostly fail with
0x80073D02while any instance is running anyway. - Intel driver age — updated
32.0.101.6881 → 32.0.101.8860, rebooted twice: crash unchanged. - GPU adapter — forced the package onto NVIDIA via
HKCU\Software\Microsoft\DirectX\UserGpuPreferences→Claude_pzs8sxrjxfjjc!Claude = GpuPreference=2;. Verified applied (gpu-process loadednvwgf2umx.dllinstead ofigd10iumd64.dll): crash unchanged. - Hardware acceleration entirely — set the (hidden, not exposed in UI) config key
"isHardwareAccelerationDisabled": trueinclaude_desktop_config.json; verified the gpu-process now runs--use-gl=angle --use-angle=d3d11-warp-webglwith zero vendor driver DLLs loaded: crash unchanged — same101457950in pure WARP software rendering, 12 s after start, again right at pane screenshot capture. - Third-party injection — the WARP-mode gpu-process contains no non-Microsoft modules at all (no AV/overlay hooks present).
Same-code crash on Intel HW + NVIDIA HW + WARP + clean module list ⇒ not a driver/machine issue.
Expected behavior
- GPU process crash should not take down the whole app (renderer/main should survive, pane should fall back or reload).
- Browser pane creation /
capturePreviewScreenshot(CDP screenshot of the pane) should not crash the GPU process. - A crash on pane restore should not create a startup crash loop; after N failures the pane restore should be skipped.
- Related: MSIX packaging ignores
ELECTRON_EXTRA_LAUNCH_ARGS(#45031), so affected users have no flag-level escape hatch, and there is no hardware-acceleration toggle in the Settings UI (the config key exists but is undocumented).
Notes
wingetclassic (non-MSIX) buildAnthropic.Claude 1.24012.1is being tested as a workaround; will report whether the crash reproduces outside MSIX.- Happy to provide full logs / run a debug build. Diagnostics in this report were gathered with Claude Code on the affected machine.
Showing cached comments. Read the full discussion on GitHub ↗
8 Comments
Update — confirmed MSIX-specific.
Installed the classic (non-MSIX) Squirrel build 1.24012.1 (
winget install Anthropic.Claude) on the same machine, same--user-data-dirprofiles. Opened the in-app Browser pane and exercised it (page load + DOM reads): no crash.[Preview] Created browser previewat 02:41:03, the GPU process (started 02:39:18) is still alive minutes later, zeroGPU process goneentries. On MSIX 1.24012.9 the exact same action killed the whole app within 4-12 seconds, 5 out of 5 times over one night.So the
101457950(0x60C201E) GPU-process crash reproduces only under the MSIX packaging (Desktop AppX container), not in the classic build of effectively the same app version.Caveat: this classic-build test ran with hardware acceleration off (hidden
isHardwareAccelerationDisabledconfig key was still set from earlier debugging); on MSIX the crash reproduced on hardware AND software rendering alike, so packaging remains the differentiator. I have re-enabled hardware acceleration and will follow up only if the classic build regresses.Workaround for affected users: install the classic build from downloads.claude.ai / winget - it picks up existing
%APPDATA%\Claudeand custom--user-data-dirdata as-is.Confirming on AMD hardware — same signature, MSIX 1.24012.9.0, Windows 11 Pro 10.0.26200:
GPU process gone: { reason: 'crashed', exitCode: 101457950 }— 6 crashes today, each killing and restarting the whole app; one earlier occurrence froze the app hard enough for Windows to log an Application Hang (Event 1002)getInternalformatParameterwarnings inunknown-window.log, then the GPU process dies one second later--disable-direct-compositionThis adds AMD to the Intel/NVIDIA/WARP matrix, further confirming the crash is driver-independent and lives in the app's browser-pane path.
Same crash on AMD hardware — adds a fourth rendering stack to the Intel HW / NVIDIA HW / WARP set already covered in this report.
Environment
Claude_pzs8sxrjxfjjc), CCD/Claude Code 2.1.219HwSchModeunsetTrigger: open a link from chat in the Browser pane, then close the pane with the ✕ button. The app dies 7–11 s after pane creation, every time.
Signature — identical exit code:
Log ends at
GPU process gone— nobeforeQuit/willQuit, main process dies with it.Occurrences in this machine's
main.log:| pane created | GPU crash | exitCode |
|---|---|---|
| 2026-07-25 23:01:03 | 23:01:12 | 101457950 |
| 2026-07-27 22:22:51 | 22:23:00 | 101457950 |
| 2026-07-27 22:39:49 | 22:39:57 | 101457950 |
| 2026-07-27 22:49:30 | 22:49:41 | 101457950 |
| 2026-07-27 22:51:58 | 22:52:05 | 101457950 |
Matches the OP:
Crashpad/contains onlysettings.dat(no dumps), no WER faulting-module event, and no TDR / display-driver-reset events in the System log — the AMD driver is not resetting, only the Electron GPU process dies.Differs from the OP:
[CDPTools] Compressed screenshot failed/UnknownVizErrorline here — the log simply stops atGPU process gone.Created session preview context, notCreated browser preview.Intel + NVIDIA + AMD + WARP all producing the same exit code supports the app-build hypothesis over anything driver-side.
Below is drafted by Opus 5
---
Reproducing on AMD, with a trigger path that I don't think is covered yet: the pane persists against the session and is re-created by the app itself, with no user or agent action.
Environment
Claude_pzs8sxrjxfjjc(confirmed viaGet-AppxPackage)isHardwareAccelerationDisabledkey setSame driver build as @DidierVN's Radeon 780M (32.0.31021.5001), but since the OP reproduced this under pure WARP with no vendor DLLs loaded, I read that as coincidence rather than signal.
The trigger: one agent-initiated pane creation poisons the session for its whole life
My trigger is not a user opening the pane. It is an agent (Claude Code inside Claude Desktop) reaching for the Browser pane on its own to read a JS-rendered page — after which that session re-creates the pane by itself on later resumes, crashing every time.
Two crashes in one session:
| Pane created | GPU crash | Δ | What I did |
|---|---|---|---|
| 16:29:04 | 16:29:09 | 5 s | Agent called
preview_startto read a JS-rendered page || 17:06:00 | 17:06:05 | 5 s | Nothing. No browser tool call at all |
The second is the interesting one:
The
serverIdis new each time (it embeds a timestamp), but thepreviewIdandtabId: "seed"are identical to the pane created at 16:29 — the app is re-creating the same pane, bound to the same session, on its own initiative. By then I had deliberately stopped using the browser tools entirely, having already lost the app once.This is not the startup crash-loop from the OP: the app started at 16:44:18 and ran fine for 22 minutes before this. The re-creation tracks resuming/refocusing the affected session, not launch.
Practical consequence worth calling out: "don't open the pane again" is not a usable workaround, because the user isn't the one opening it the second time. The record lives in
Local Storage/leveldb(binary, log-structured), not in the session JSON underclaude-code-sessions/, so there's no user-editable file to clear it from either.That strengthens the OP's third Expected behavior bullet — the "after N failures, skip the pane" guard is needed on any re-creation path, not just restore-on-launch. Otherwise the session stays unusable until the pane is closed through the UI, which other reporters say is itself a trigger.
Confirming @DidierVN's WebGL precursor — and it's exactly 19, not ~19
@DidierVN reported "a burst of ~19 WebGL
getInternalformatParameterwarnings inunknown-window.log, then the GPU process dies one second later". Confirmed precisely, on different hardware:Exactly 19 every time, across three variants:
A fixed count of 19 suggests a deterministic capability-probe loop enumerating internal formats, hitting invalid enums, with the GPU process dying at or immediately after the end of it. That seems a far more specific lead than "GPU crash" — it should be reproducible directly from whatever performs that probe.
Caveat: the 16:23:08 burst predates the start of my current
main.log(16:26:31), so I can't say whether it also ended in a crash. Two of three bursts definitely align with crashes; the third is unknown, not a counter-example.Negative findings — all match the OP
Crashpad/reports/is empty;Crashpad/holds onlysettings.dat. No dumps.Get-WinEventfor Application IDs 1000/1001/1002 across the crash window returns nothing.main.logends atGPU process gone, nobeforeQuit/willQuit.[CDPTools] Compressed screenshot failed/UnknownVizErrorline — matching @winter1hydrogen5712hmsan-cell. The log just stops.A logging artifact others may want to check before quoting counts
Every event in my
main.logis written twice — the updater check (fires once per launch), the[process-memory]interval sampler, and[EventLogging] Flushingall appear exactly 2×:3215 lines, 1253 unique. So a
GPU process goneblock appearing twice at the same timestamp is one crash logged twice, not two crashes — worth verifying before anyone (including me) reports duplicate-event counts from this file.Repro recipe
WebFetch— it will reach for the Browser pane on its own.[Preview] Created browser preview.serverIdbut the samepreviewId, and the app dies ~5 s later again — with no user or agent browser action.Happy to run a debug build or pull anything else from this machine.
Another Intel data point, plus two things I haven't seen covered yet: the newest Xe-branch driver does not help, and reinstalling the MSIX silently removes the classic-build workaround.
Environment
Claude_pzs8sxrjxfjjc), Node 24.18.0Same signature as the report:
exitCode 101457950, 7–8 s after[Preview] Created browser preview, log ends right there — nobeforeQuit, no Crashpad dump, noApplication Hang/WER entry, and no TDR or display-driver event anywhere in the Windows System log (7-day sweep).Six crashes in one day, all
101457950:| Browser preview created | GPU crash | Δ |
|---|---|---|
| 2026-07-22 15:50:44 | 15:50:51 | 7 s |
| 2026-07-22 16:31:54 | 16:32:01 | 7 s |
| 2026-07-27 17:09:54 | 17:10:01 | 7 s |
| 2026-07-27 17:35:36 | 17:35:44 | 8 s |
(One further crash at 17:17:56 followed
[claude-in-chrome] Chrome extension connected to bridgeby 57 s.)1. Newest Iris Xe driver does not fix it
The thread already covers Intel Arc, NVIDIA, AMD and WARP. Adding Iris Xe on the latest driver of its branch:
32.0.101.7082(2026-01-19) — crashed32.0.101.7088(2026-06-22 WHQL, newest in the 11th–14th Gen Processor Graphics branch) — still crashesWorth noting because 7088's release notes explicitly list, for Core Processors with Iris Xe and UHD Graphics, the fixes "WebGL based applications may not behave as expected" and "crash when rendering offscreen" — both sound directly on point for the pane's offscreen/readback path, and neither made any difference.
A BIOS update in the same session (Lenovo
JKCN53WW) also changed nothing. Consistent with your conclusion that this is packaging-side, not driver-side.2. Reinstalling the MSIX removes the classic-build workaround
This one cost several hours. The crash-on-relaunch behaviour (pane restored from the active-servers store) reads as a corrupted install, so users reinstall from the Store. That reinstall wipes
%LOCALAPPDATA%\AnthropicClaude, silently putting them back on the broken MSIX build with no indication the workaround is gone. I hit this loop four times in six days before spotting it.Two practical notes for anyone applying the classic-build workaround:
winget install Anthropic.Claudeexits 43 ("package already installed / no applicable update") because winget resolves the ID to the installed MSIX1.24012.9.0, while the manifest offers1.24012.1.--forceis required:``
winget install Anthropic.Claude --force
Confirming the workaround itself works here: with the classic build the Browser pane does not take the app down.
Suggestion
Independent of the GPU fix, the restore-on-launch behaviour is what turns a single crash into a reinstall loop. Not restoring Browser panes automatically after an abnormal exit — or dropping them from the active-servers store when the previous session ended in a GPU crash — would contain the blast radius considerably while the viz/readback path is being fixed.
Authored by Claude (Opus 5 on UltraCode), approved by me - a human 😊
---
Additional data from another affected machine on the same build. Same
exitCode: 101457950(0x060C201E), same Browser-pane trigger — but with a couple of differences from the original report that I think narrow the cause.Environment: Windows 11 Pro 10.0.26200 · MSIX
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc---
1. The crash is on a deterministic 5-second timer from preview creation
Both occurrences in my log are identical in shape, to the second:
Exactly 5.0s from
Created browser previewto GPU death, both times. The app takes the whole process down with it — the next log line in each case is a freshStarting app.5s is not arbitrary: it's the app's own screenshot deadline. From an earlier entry on the same machine:
So the GPU is dying at the capture deadline rather than the capture timing out.
2.
UnknownVizErroris not required for this crash — it never appears hereThis is where my logs diverge from the original report. Across both log files (2026-06-20 → present):
| Signature | Occurrences |
|---|---|
|
UnknownVizError| 0 ||
Compressed screenshot failed| 0 ||
capturePreviewScreenshot failed| 52 — but none at either crash |At the moment of both crashes, no screenshot error was logged at all. The GPU is killed at the 5s mark before any capture failure gets a chance to be reported.
The screenshot-failure chain does exist on this machine historically (114 total screenshot warn/error lines, including one
[CDPTools] CDP compressed screenshot failedon 07-26), just never coinciding with a crash. That suggestsUnknownVizErrorin the original report is a race variant of the same underlying kill — whichever of the two paths loses the race gets logged — rather than the cause of it.3. No crash dumps are being generated at all
Probably the most actionable item here, because it likely means no Sentry minidump exists for this crash from any affected user:
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Crashpad\reports\— emptyApplication Error/ WER entries for Claude across the whole affected periodCrashpad is initialising fine (
settings.datandmetadataare rewritten every launch), it just never captures anything. A GPU process that faulted would leave a dump; one terminated externally would not — which is what the exit codes below say is happening.4. The GPU isn't the only child process being killed — the Network Service goes the same way
Not mentioned in the original report, and no Browser pane involved. Four occurrences on 2026-07-28:
1073807364=0x40010004=DBG_TERMINATE_PROCESS.Full exit-code inventory since 2026-07-27:
| When | Code | Decoded |
|---|---|---|
| 07-27 16:29, 17:06 |
101457950=0x060C201E| GPU — the Browser pane crash || 07-28 00:45, 21:55, 23:46 ×2 |
1073807364=0x40010004| Network Service —DBG_TERMINATE_PROCESS|| 07-29 14:19 |
34| GPU || 07-29 14:33 ×8 |
-1073741205=0xC000026B|STATUS_DLL_INIT_FAILED_LOGOFF— session shutdown, benign |Taken together (1–4): the Browser pane is unambiguously the most reliable trigger, but the screenshot/readback path looks like the victim rather than the fault — the crash fires on the capture deadline with no capture error, produces no dump, and a completely unrelated child process (Network Service) dies with an explicitly externally-terminated status. That pattern reads more like MSIX child-process lifetime/termination than a viz bug — something is killing utility processes, and the preview path is simply the one that reliably provokes it.
5. Two MSIX event-log errors that look damning but are red herrings
If anyone is chasing these in
Microsoft-Windows-AppXDeploymentServer/Operational, they're a dead end:Expected for a sideloaded MSIX.
Get-AppxPackagereportsSignatureKind : Developer— Anthropic's own EV cert, not the Store cert — so Windows has no Store/AppInstaller provenance to attach a trust label to. It logs and continues. Unrelated to the crash.6. Why "MSIX Repair" doesn't fix anything
Worth flagging since Repair is everyone's first move. All three attempts (16:25, 16:43, 17:06 on 07-27) failed identically:
The Add step succeeds, then Register fails with
0x80073D02because Claude is still running — leaving the package re-staged but never re-registered. That half-applied state is likely why Repair can feel like it makes things worse.To actually repair: exit from the tray, confirm no
claude.exe/cowork-svc.exeremain, stop theCoworkVMServiceservice, then Repair. (CoworkVMServicerestarts itself alongside each attempt.)7. Release status for anyone waiting on a fix
No fix has shipped yet. The app's own update feed can be queried directly:
As of 2026-07-31 both Windows channels still return 1.24012.9, published
2026-07-24T16:16:22Z:(Swap
msix→squirrelfor the classic channel — same build.) Releases had been landing every 1–4 days since late June; this is now a 7-day gap beginning exactly at the build that introduced the regression.---
Happy to capture an ETW or Process Monitor trace of the child-process termination to pin down what's issuing the terminate, run a debug build, or attach full
main.log.Adding another reproduction with four identical crash traces, on Intel Iris Xe — which together with the NVIDIA/AMD/WARP reports here further rules out a vendor-driver cause.
Environment
Claude_pzs8sxrjxfjjc), Windows 11 Pro build 26200node server.mjs) of a marketing site whose only WebGL/WebGPU content is a Cloudflare Turnstile widget (challenges.cloudflare.com/turnstile/v0/api.js). Zero first-party canvas/WebGL/three.js on the page (verified by repo-wide grep). Same class as #80689.Four crashes, identical signature, across two clean installs
| # | Preview "Server ready" | GPU process gone | Delta |
|---|---|---|---|
| 1 | 2026-07-27 23:20:41 | 23:20:56 | 15 s |
| 2 | 2026-07-27 23:46:14 | 23:46:19 | 5 s |
| 3 | 2026-07-27 23:49:38 | 23:49:42 | 4 s |
| 4 | 2026-07-28 08:24:05 (fresh reinstall of 1.24012.9.0, first launch) | 08:24:09 | 4 s |
Every crash logs the same record in
main.log:Renderer log sequence immediately before every crash (
unknown-window.log, identical all four times): Turnstile's fingerprint probe, then a burst of ~19 WebGL2 format-probe warnings, then WebGPUrequestAdapter(), then death:The WebGPU
requestAdapter()warning is the last GPU-service operation logged before death in all four crashes; the Dawn "A valid external Instance reference no longer exists." line appears at the death instant (crashes 2 and 3).Additional observations
MoAppHang— the hang report is an effect of the GPU death, not a cause.ptype=browserwith exception 0x80000003 (STATUS_BREAKPOINT) in Claude.exe — a hang capture of the wedged browser process. Its module list contains no vendor driver DLLs (noigd*), no ANGLE/Dawn modules. NoDisplay/DxgkrnlTDR events (4101/4102) in the System log at any crash time.101457950=0x060C201E: severity bits rule out an NTSTATUS exception, and it is not Chromium's watchdogRESULT_CODE_HUNG— it looks like an app-defined deliberate termination. Would appreciate Anthropic decoding it.Happy to provide the full
main.log/unknown-window.logexcerpts or run a diagnostic build if useful. Workaround that held up here: keep Turnstile-bearing pages out of the embedded Preview (external browser preview works fine on the same machine).Reproduced today (2026-08-01) on
Claude_pzs8sxrjxfjjcMSIX1.24012.9— same exit code, and mymain.logpins the trigger to a page containing a Cloudflare Turnstile widget, which lines up with @CR1SR's finding above.Two crashes in one session, both from opening the embedded Browser Preview on the same page (a marketing site with a Turnstile "I'm human" challenge on it):
Delta from pane-open to crash: 7s and 4s — matches the 4-15s window reported above. Third independent data point for the Turnstile/WebGPU theory, different site than CR1SR's, identical signature.
Downstream effect worth flagging: the app didn't come back cleanly after the crash — the next launch's auto-updater (
ClaudeSetup.log) hitAddPackage failed with HRESULT 0x80073CF6(package servicing conflict), consistent with a leftover process/handle from the crashed instance still holding the MSIX registration. A retry a few minutes later succeeded with no other change. So this crash can cascade into a failed auto-update on next launch — likely what's behind reports elsewhere of having to reinstall multiple times.Workaround in the meantime: keep the embedded Browser Preview away from any page with Turnstile (or WebGL/WebGPU content generally) — same as noted above.