[Windows Desktop] GPU process crashes with exitCode 101457950 (0x060C201E) - reproduces with --disable-gpu, across 1.26832/1.28929

Summary

The Windows desktop app's Chromium GPU process crashes repeatedly with the same exit code 101457950 (0x060C201E), taking down the app window. 8 fatal occurrences over 5 days, across two app versions (1.26832.0 and 1.28929.0). The crash reproduces even with --disable-gpu verified on the main process, so it is not the NVIDIA/hardware acceleration path. Long multi-agent Workflow runs (with the in-app Browser pane active) are the most common trigger, but one crash happened 3 minutes after a cold start. The user has had to abandon their workflow because of this.

Environment

• Claude Desktop (MSIX): 1.26832.0 → 1.28929.0 (crash persists on both), bundled CCD 2.1.222
• Windows 10 Pro 19045, 32 GB RAM
• NVIDIA GeForce RTX 3070, driver 32.0.16.1047 → updated to 32.0.16.1088 (2026-07-22) — no change
• A "Meta Virtual Monitor" virtual display driver (Quest Link) is present — untested suspect, since display enumeration passes through display drivers even in software rendering mode

Crash timeline (from %APPDATA%\Claude\logs\main.log)

Fatal crashes, all identical:

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

| # | Time | App version | Notes |
|---|------|-------------|-------|
| 1 | 2026-08-09 14:49:48 | 1.26832.0 | during 6h multi-agent Workflow run |
| 2 | 2026-08-10 15:43:58 | 1.26832.0 | during Workflow run |
| 3 | 2026-08-10 17:49:30 | 1.26832.0 | during Workflow run |
| 4 | 2026-08-10 18:35:24 | 1.26832.0 | during Workflow run |
| 5 | 2026-08-10 21:22:18 | 1.26832.0 | --disable-gpu verified active on main process |
| 6 | 2026-08-12 17:48:21 | 1.28929.0 | |
| 7 | 2026-08-12 19:24:06 | 1.28929.0 | |
| 8 | 2026-08-13 12:14:05 | 1.28929.0 | 3 minutes after app start |

Non-fatal GPU process crashes also logged: 2026-08-10 16:08:17 and 16:11:48 with exitCode: 34 (GPU process respawned, app survived).

A crash dump was uploaded via Crashpad; report ID from the crash dialog: a3cfa3b9-27e1-436c-9972-5ff7a32fdb4c (local Crashpad store is empty — dumps uploaded and purged, nothing in WER/Event Log because Crashpad intercepts).

Ruled out locally

• Hardware GPU / NVIDIA driver path: crash #5 occurred in an instance whose main process command line was verified to contain --disable-gpu (launched via IApplicationActivationManager because direct launch of the WindowsApps exe is ACL-blocked). Same exit code in software rendering mode.
• Driver version: updated 32.0.16.1047 → 32.0.16.1088, no change.
• System-level GPU failure: zero TDR events (nvlddmkm, Event 4101/4113) in the System event log across all crash times.
• OOM: 7–13 GB system RAM free at every crash (per the app's own [process-memory] log lines seconds before each crash).
• Third-party DLL injection: module list of the running GPU process contains only DLLs from C:\Windows and the app package.
• App version: persists across 1.26832.0 → 1.28929.0.

Related updater defect observed (compounded the impact)

While diagnosing, we also found the built-in updater repeatedly failed to apply 1.28929 for 2+ days and force-closed the running app on each retry (AppXDeploymentServer log):

603: deployment Add started (Claude-*.msix, ForceApplicationShutdownOption, ForceUpdateFromAnyVersion)
462: error 0x80070020: could not create file ...\Claude_1.26832.0.0_...\app\resources\cowork-svc.exe

cowork-svc.exe is registered as the always-running Windows service CoworkVMService (StartType Automatic). ForceApplicationShutdownOption closes the app but not the service, so the service holds a lock on its own exe, the update fails mid-stage, the package is left Modified / NeedsRemediation, and the updater retries the whole cycle (force-closing the app again) on every check — 2026-08-10 15:26 / 15:30 / 15:53 / 17:55 / 18:38, each followed ~7 s later by an app relaunch, killing in-flight sessions. The updater should stop CoworkVMService before staging the package. (The update eventually applied on 2026-08-12 14:34.)

---

Report compiled from local logs by Claude Code on behalf of the user; timestamps are KST.