[BUG] Claude Desktop 1.24012.11.0 (Windows) — GPU process crash (exitCode 101457950) kills the whole app

Confirming on Windows 11 / MSIX 1.24012.11.0, with the Code Integrity fields and
what looks like the actual defect.

Event 3033 fields, measured locally (4/4 crashes, 0–1 s before each):

ProcessNameBuffer : ...\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\claude.exe
FileNameBuffer    : ...\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
RequestedPolicy   : 8
ValidatedPolicy   : 1
Status            : 3221226536  (0xC0000428)

Identical to the fields reported in openai/codex#34133.

The DLL is correctly signed — that is not the defect. Authenticode on the
shipped files:

| DLL | Status | Signer |
|---|---|---|
| vk_swiftshader.dll | Valid | CN="Anthropic, PBC" |
| libEGL.dll, libGLESv2.dll, vulkan-1.dll, ffmpeg.dll | Valid | CN="Anthropic, PBC" |
| d3dcompiler_47.dll, dxil.dll | Valid | CN=Microsoft Windows |

The defect looks like a preload gap. Chromium's Windows GPU startup
(gpu/ipc/service/gpu_init.cc) preloads vk_swiftshader.dll specifically because
MITIGATION_FORCE_MS_SIGNED_BINS will later block non-Microsoft DLLs in that
process. A 3033 means the load was attempted after the mitigation was applied —
i.e. the preload did not cover this path.

Upstream Chromium change 963206a961a7992b048d07f756f87f11fa2e5420 (surfaced in
codex#34133) makes the SwiftShader preload conditional on the load being permitted,
and otherwise takes the Windows fallback path. That looks like the relevant fix to
verify or backport. Alternatives noted there: create the GPU child with a policy
that accepts Store/catalog-signed binaries, or ship vk_swiftshader.dll at a
signing level that child policy accepts.

Machine policy is not the cause. Smart App Control is OFF
(VerifiedAndReputablePolicyState = 0) and
Win32_DeviceGuard.UsermodeCodeIntegrityPolicyEnforcementStatus = 0. The block is
per-process, from the mitigation the GPU child opts into — which is why this
reproduces on machines with no special security configuration.

Also ruled out here: both GPU vendors (crashes on NVIDIA RTX 3060 and, after
pinning via UserGpuPreferences, on Intel Iris Xe — same exit code); both drivers
updated; all GPU/shader caches cleared; MSIX Repair; full uninstall + reinstall.
Memory pressure ruled out — free RAM at crash time ranged 101 MB to 3050 MB across
occurrences.

14 occurrences since 2026-04-10, escalating: 1 in April, 3 in June, 7 in July,
3 on Aug 1, 1 on Aug 4. The app currently fails to launch entirely.

Please don't fix this by asking users to disable Code Integrity.

Follow-up: after the 2026-08-04 16:07:52 crash the app stopped launching
entirely, and Get-AppxPackage reports Status : Modified, NeedsRemediation.
main.log ends at the crash line with nothing after it, so activation is
failing at the package level before Electron starts. This independently
reproduces the package-corruption behaviour reported in #81159 — the GPU
crash is not just killing the session, it is leaving the MSIX package in a
state that requires Repair.

Cross-reference: posted measurements in #83835 showing the preload is skipped at
runtime, the webgpu_decoder_impl.cc:1851 fallback path the startup guard cannot see,
and a version timeline indicating this is not a regression — which matches
@pierremorales's finding here that the pane never worked. Also killing the
AllowStoreSignedBinaries line of inquiry: Chromium never implemented it, and the
package is Developer-signed so the Store signing level is unreachable anyway.

Confirmed fix: switch from the MSIX package to the non-MSIX (.exe) build

Same crash on Windows 11 Pro (26200): preview_start killed the GPU process and
took the whole app down. exitCode: 101457950 / 0x060C201E, 31/31 reproducible.

Root cause. MSIX runs the GPU process under Code Integrity Guard with
MicrosoftSignedOnly. vk_swiftshader.dll is signed by Anthropic, PBC, so CIG
refuses it and MSIX escalates the load failure to a process kill via
ntdll!LdrAppxHandleIntegrityFailure. Chrome hits the same rejection but survives
it because it isn't MSIX.

Note the DLL is still Anthropic-signed after the fix and CIG still rejects it —
what changes is that outside the MSIX container the rejection is non-fatal.
Reinstall the MSIX package and the crash returns.

Steps

1. Back up your config first — this is the step that bites. MSIX virtualizes
paths, so the real file isn't in %APPDATA%, and its folder is deleted on uninstall:

Copy-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json" "$env:USERPROFILE\Desktop\claude_desktop_config.backup.json"
2. Uninstall Claude from Settings → Apps.

3. Install the non-MSIX build. Download the installer from
https://claude.ai/download, then run it from PowerShell with the --exe flag — this
is the flag that gets you the non-MSIX build:

& "$env:USERPROFILE\Downloads\Claude Setup.exe" --exe
The leading & (call operator) is required because the path contains a space.
Adjust the path if you saved the installer elsewhere. It installs to
%LOCALAPPDATA%\AnthropicClaude\. Verify you're off MSIX — this should return
nothing:

Get-AppxPackage -Name *Claude*
4. Restore the config, and verify by hash — not by existence. On first launch the
new build writes its own default config to %APPDATA%\Claude\ (1211 bytes here vs
3314 in my backup):

Get-FileHash "$env:USERPROFILE\Desktop\claude_desktop_config.backup.json","$env:APPDATA\Claude\claude_desktop_config.json" -Algorithm SHA256 | Format-Table Hash,Path -AutoSize
5. If the hashes differ: quit Claude Desktop completely, then copy. The app
rewrites this file on exit, so copying while it runs gets clobbered when you quit.
Order matters: quit → copy → relaunch, then re-check the hash.

Copy-Item "$env:USERPROFILE\Desktop\claude_desktop_config.backup.json" "$env:APPDATA\Claude\claude_desktop_config.json" -Force
Skipping step 4 cost me the Chrome extension pairing, trusted folders, per-folder
permission modes and starred sessions. Keep the backup until you've verified.

Result
preview_start and read_page now work with no crash. One quirk that isn't a
failure: computer{action:"screenshot"} errors with "the Browser pane is not
displayed, so the page is not compositing frames" when the pane is hidden.
read_page bypasses the compositor and works regardless.

Still reproducing on 1.25927.0.0, which is a good deal newer than the 1.24012.11.0 in the original report — so this is not fixed.

Four crashes in a 23-minute window today, all with the identical exitCode 101457950:

2026-08-05 17:48:41 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-05 17:54:24 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-05 17:58:34 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-05 18:11:36 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Data point against the hybrid-GPU theory in #81836: this machine has a single discrete adapter, nothing to switch between.

• GPU: NVIDIA GeForce RTX 3090, driver 32.0.16.1088, dated 2026-07-21 (current)
• OS: Windows 10 Pro 19045, 32 GB RAM
• App: 1.25927.0.0, MSIX Claude_1.25927.0.0_x64__pzs8sxrjxfjjc

This lines up with #83835 already reporting it on both NVIDIA and Intel. Whatever the trigger is, it doesn't appear to be adapter switching.

On recovery, which seems to have changed between builds. After the 18:11:36 crash the app showed the Windows "This app can't open — There's a problem with Claude. Reinstall the application from its original install location" dialog, then recovered on its own and relaunched at 18:19:36, roughly 8 minutes later. Get-AppxPackage *Claude* reads Ok afterward — it never went to Modified, NeedsRemediation.

That is a real improvement over the older build. On 1.24012.9 the same failure required a full Remove-AppxPackage + reinstall three separate times, matching what #82967 describes. So the package-corruption half may be fixed while the GPU crash itself is not. Worth separating the two in triage.

Possibly related, possibly not: on 1.24012.9 this machine logged GPU crashes with a different exit code, 34, on 2026-07-30, 08-03 (x2), and 08-04. Same reason: 'crashed', same whole-app death. I can't tell whether that's the same defect with a different code or a separate one, but flagging it in case the code changed across builds.

Adding a 12-day dataset from another affected machine — 4 occurrences of this exact signature, with a consistent trigger correlation that may help narrow it down.

Occurrences (all same machine: Windows 10 Pro 10.0.19045, GTX 1660 SUPER, driver 610.62 / 32.0.16.1062)

| # | Local time (KST) | UTC | exitCode | App version | User state |
|---|---|---|---|---|---|
| 1 | 2026-07-26 13:15:59 | 04:15:59 | 101457950 | 1.24012.9.0 | active |
| 2 | 2026-08-05 14:19:43 | 05:19:43 | 101457950 | 1.25927.0.0 | active |
| 3 | 2026-08-06 14:00:32 | 05:00:32 | 101457950 | 1.25927.0.0 | idle, user away |
| 4 | 2026-08-07 13:23:38 | 04:23:38 | 101457950 | 1.25927.0.0+ | active |

Every time: GPU process gone: { reason: 'crashed', exitCode: 101457950 } → main process dies instantly with no shutdown logging (main.log jumps straight to the next "Starting app").

Since Crashpad uploads crash reports server-side and prunes them locally (Crashpad\reports is empty on disk), Anthropic should already have the crash dumps for these four timestamps — the UTC times above should let you look them up.

Trigger correlation: Cloudflare challenge seconds before every crash

All 4 crashes were immediately preceded (3–120 s) by challenge_redirect 403 responses + 429s from claude.ai, often for background sessions (session IDs in the redirect URL were not the foreground session). This machine keeps 17–30 Claude Code sessions resident 24/7; each session reconnects after a 900 s idle timeout (WarmLifecycle disconnect/reconnect), so background re-auth → Turnstile challenge happens constantly. Occurrence #3 is the clean case: machine idle, user physically away — the crash needs no user interaction at all. Working hypothesis on our side: an off-screen challenge/Turnstile render hitting the NVIDIA GPU path kills the GPU process, and the GPU-process death takes the whole app down instead of being recovered (which matches the OP's report of image-fetch triggering it — anything that renders web content off-screen would go down the same path).

Cross-machine contrast supporting the render-path angle: a laptop where the display is driven by an iGPU (Radeon 780M, NVIDIA dGPU asleep in D3cold) runs similar workloads with zero crashes in the same period.

Ruled out on our side (measured, not guessed)

• OOM: independent 30 s memory sampler shows 4–5 GB physical free at every crash instant; free memory rises as the app dies.
• GPU hardware/driver TDR: zero Event Log 4101/WHEA/display errors across the whole period; adapter Status=OK.
• Physical network: an independent LAN monitor (per-second samples, external ping + gateway + switch uplink) shows the network healthy at all four crash instants — the net::ERR_CONNECTION_TIMED_OUT / ERR_NAME_NOT_RESOLVED bursts we see in main1.log before crash #4 are at the app↔claude.ai/Cloudflare layer, not the LAN.
• Scheduled tasks / heavy jobs: crash times don't line up with any local scheduled work; #3 happened with nothing running.

Timing note: all 4 crashes fall in a 13:15–14:20 KST window, and the three consecutive weekdays advanced daily (14:19 → 14:00 → 13:23), which smells like a daily session-auth/cookie expiry wave causing synchronized re-auth challenges. Unverified.

Recovery quirk (reproducible 4/4)

After the crash the app cannot be reinstalled/relaunched until CoworkVMService is stopped and zombie processes are killed — MSIX reinstall fails with 0x80073D02 (and once 0x80070020 on cowork-svc.exe). A crash of the GPU process ends up requiring service-level cleanup, which suggests the death is not being handled at all.

We've now registered WER LocalDumps for Claude.exe (Crashpad leaves nothing locally) and will attach a minidump + faulting module on the next occurrence.