[BUG] Desktop (Windows): GPU process crashes with identical exitCode 101457950 (0x060C201E) on both NVIDIA and Intel adapters

Confirming this on a second machine, and I think I have the root cause.

Windows Code Integrity rejects the app's own bundled vk_swiftshader.dll
0–1 seconds before every crash. Event ID 3033, log
Microsoft-Windows-CodeIntegrity/Operational:

| Code Integrity 3033 | GPU crash (main.log) | Package version |
|---|---|---|
| 2026-08-01 14:59:33 | 14:59:34 | 1.24012.9.0 |
| 2026-08-01 18:47:10 | 18:47:10 | 1.24012.9.0 |
| 2026-08-01 19:04:17 | 19:04:17 | 1.24012.9.0 |
| 2026-08-04 16:07:51 | 16:07:52 | 1.24012.11.0 |

4 out of 4. Event text:

Code Integrity determined that a process
(...\WindowsApps\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\claude.exe)
attempted to load
(...\WindowsApps\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll)
that did not meet the Microsoft signing level requirements.

The DLL ships inside the package (5,546,320 bytes) alongside
vk_swiftshader_icd.json. Anyone can check their own machine with:

Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 200 -EA 0 |
  ? { $_.Id -eq 3033 } | Select TimeCreated,Message | Format-List

Cross-vendor confirmation. The identical exit code with the identical
Code Integrity 3033 rejection of vk_swiftshader.dll was traced in another
vendor's Electron app: openai/codex#34133. That strongly suggests a signing
or packaging problem with the bundled SwiftShader binary rather than anything
GPU-driver specific.

Consistent with that, on my machine the crash survives every hardware-side fix:

• Updated both GPU drivers (Intel Iris Xe 2025-09 → 2026-06;

NVIDIA RTX 3060 Laptop 2025-11 → 2026-07 Studio, clean install)

• Pinned the app to each adapter in turn via

HKCU\Software\Microsoft\DirectX\UserGpuPreferences — crashes on both,
same exit code

• Cleared GPUCache, ShaderCache, DawnGraphiteCache, DawnWebGPUCache,

Code Cache

• MSIX Repair, and a full uninstall + reinstall

Memory pressure ruled out. I correlated each crash with sys_free from the
preceding [process-memory] line: free RAM at crash time ranged from 101 MB
to 3050 MB (median ~1 GB). Crashes happen with 3 GB free, so this is not OOM.

Timeline — 14 occurrences, deduplicated from main*.log, escalating:

2026-04-10 11:42:08     2026-07-27 13:03:25     2026-08-01 14:59:34
2026-06-22 19:00:18     2026-07-28 02:08:46     2026-08-01 18:47:10
2026-06-28 11:20:33     2026-07-28 10:38:26     2026-08-01 19:04:17
2026-06-29 09:33:38     2026-07-28 18:22:22     2026-08-04 16:07:52
2026-07-18 11:58:21     2026-07-21 13:44:10

1 in April → 3 in June → 7 in July → 3 on Aug 1 alone.

Environment: Claude Desktop 1.24012.11.0 (MSIX), Windows 11, 16 GB RAM,
NVIDIA RTX 3060 Laptop 32.0.16.1088 + Intel Iris Xe 32.0.101.7088.

Crashpad minidumps (~34 MB each) and full log excerpts available on request.

Update: correcting two things I said above, and adding measurements that change the diagnosis.

1. Not a regression, and the commit I named is not the fix.

I recovered this machine's version history from archived main*.log and paired every
crash with the build that was running:

| Period | Node (app startup log) | Crashes | Rate |
|---|---|---|---|
| 2026-04-10 – 2026-07-21 (102 d) | 24.14.0 → 24.17.0 | 6 | ~1 per 17 days |
| 2026-07-22 – 2026-08-04 (13 d) | 24.18.0 | 9 | ~1 per 1.4 days |

Node 24.13.0 ships with Electron 41 (Chromium 146); Node 24.18.0 with Electron 42.7.0
(Chromium 148.0.7778.280, read from <app>\version). The first crash ran on Node
24.14.0 — Chromium 146, two majors before
97b3f5d7800fde085af53b1b7455b730c215a874 (first in 148.0.7734.0). So the crash
predates that change; backporting it is a no-op, and it is already in both 148 and 150.
@pierremorales reaches the same conclusion independently in #83478 — the Browser pane
never worked on his machine either.

Caveat: my agentic workload also intensified in late July, so the rate figures are
confounded. The pre-2026-07-22 occurrences are not — those builds could not contain
the commit.

2. AllowStoreSignedBinaries is a dead end — please don't spend time on it.

Chromium hardcodes policy.MicrosoftSignedOnly = true in
sandbox/win/src/process_mitigations.cc with the comment *"Support not added at the
moment."* There is no switch and no Electron API. And it would not help regardless:
this package is SignatureKind: Developer with ordinary third-party Authenticode DLLs,
so the Store signing level is unreachable — consistent with ValidatedPolicy: 1
against RequestedPolicy: 8.

3. Measured: the preload is not running, and the guard cannot see the path that loads it.

On the live --type=gpu-process child (elevated, app healthy, 26 min uptime, hardware
D3D11 ANGLE):

vk_swiftshader.dll   NOT LOADED
vulkan-1.dll         NOT LOADED
libEGL.dll           LOADED
libGLESv2.dll        LOADED

BinarySignature:
    MicrosoftSignedOnly      : ON
    AllowStoreSignedBinaries : OFF

The preload in gpu/ipc/service/gpu_init.cc is guarded by three conditions that all
read command-line/startup state only (IsSwiftShaderAllowed, use_webgpu_adapter ==
kSwiftShader, DefaultForceFallbackAdapter). The app passes none, so the preload is
correctly skipped.

But gpu/command_buffer/service/webgpu_decoder_impl.cc:1851 sets
forceFallbackAdapter = true with backendType = Vulkan at runtime, on any
requestAdapter() whose preferred-adapter loop finds nothing acceptable. No switch
controls it, so no startup guard can predict it. That loads vk_swiftshader.dll after
MITIGATION_FORCE_MS_SIGNED_BINS — a delayed mitigation — is already live.

My log, the second before the crash:

16:07:50  WebGL: INVALID_ENUM: getInternalformatParameter  (x20)
16:07:51  The powerPreference option is currently ignored when calling requestAdapter()
          on Windows.  (x2)
16:07:52  GPU process gone: { type:'GPU', reason:'crashed', exitCode:101457950 }

This also explains why pinning NVIDIA vs Intel changed nothing: the failure is in
adapter rejection, downstream of which GPU is present.

4. Help > Troubleshooting > Disable Hardware Acceleration does exist (not in
Settings), but it is likely to make this worse: --disable-gpu satisfies no preload
guard, while webgpu_decoder_impl.cc:1235 sets force_fallback_adapter_ = true
whenever WebGPU's feature status is Software — sending every requestAdapter()
straight to SwiftShader.

I have Crashpad minidumps (~34 MB each); @pierremorales reports none on his machine, so
these may be the only ones available. Happy to send them anywhere useful.

Same crash signature, with A/B version data that may help narrow it.

Windows 11 Home 25H2 (26200.8875), Dell laptop, hybrid graphics (Intel Arc
iGPU + RTX 4050 Laptop dGPU), 32 GB RAM. Desktop app 1.25927.0.

• On 1.24012.9: zero GPU crashes in rotated main.log going back to Jul 7,

heavy daily use including Browser pane sessions.

• App auto-updated to 1.25927.0 on Aug 4 ~12:14 PM PT (package folder

creation time). First-ever "GPU process gone" at 7:46 PM that evening.

• 8+ crashes in the 36 hours since, all identical:

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

• Renderer log shows a WebGL INVALID_ENUM burst and a WebGPU

requestAdapter() call seconds before each death.

• Reproduces on NVIDIA 581.95 and 610.88, Intel Arc Sept-2025 and

32.0.101.8860, and with the app pinned to either GPU via Windows per-app
graphics preference. Windows event log clean: no bugchecks, no
Application Error 1000.

• Same MSIX aftermath as #83932 / #81875: Windows shows the "advanced

options -> Repair" dialog, and package removal fails with 0x80073CFA
(PreserveApplicationData), so reinstalls never replace the package.

Testing --disable-gpu as a workaround now; will report back.