Repository navigation
[Windows] Desktop app 1.24012.1: fatal GPU-process crash (0x060C201E) via in-app Browser tab; crash leaves MSIX package unlaunchable (appxState=2) until Repair #80444
Description
Activity
Environment
- Claude desktop app 1.24012.1.0 (MSIX
Claude_pzs8sxrjxfjjc,build_type: windows-store), Electron 42.7.0 / Chrome 148.0.7778.280 / Node 24.18.0 - Windows 11 Home 26200, de-AT locale, 32 GB RAM
- GPU: NVIDIA GeForce RTX 2080 — reproduced on two driver versions (32.0.15.9595 and 32.0.16.1074), so not driver-specific
- Regression: zero GPU-process crashes in app logs on any earlier build (log history back to 1.22209.3); the app auto-updated to 1.24012.1 on 2026-07-22 at 15:28 UTC and crashed fatally 4 times within the following ~14 hours
Bug 1 — fatal GPU-process crash kills the whole app
Four identical fatal crashes (local time UTC+2): 2026-07-22 21:08:47 and 21:22:21, 2026-07-23 04:20:40 and 07:03:56 (= 19:08:47Z, 19:22:21Z, 02:20:40Z, 05:03:56Z).
Signature, every time, in
%APPDATA%\Claude\logs\unknown-window.log— a page loaded in the in-app Browser preview tab runs a WebGL/WebGPU capability-probe suite (looks like standard bot-detection/fingerprinting code; several probed sites use it):[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat (~19x, incl. "when EXT_color_buffer_[half_]float is not enabled" variants) [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size [error] %c%d font-size:0;color:transparent NaN A valid external Instance reference no longer exists. [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lostthen immediately in
main.log:[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }…and the entire app dies instantly with the GPU process (
main.logstops mid-write, no shutdown path,window-state.jsonnever re-saved). Exit code is101457950=0x060C201Ein all four crashes.Repro chain observed 4/4 times: a Claude Code session opens an in-app Browser preview tab (
[PreviewContext] Opened preview user tab/[Preview] Created browser previewinmain.log) → 15–36 seconds later the loaded page runs the WebGL probe burst → GPU process dies → app dies.Notably, a GPU-process crash with a different exit code (34, during a driver install) was recovered gracefully — the GPU process just relaunched. Only the
0x060C201Epath takes the app down.One of the four crashes happened fully unattended at 04:20 (an overnight workflow re-opened its Browser tab), so this also kills long-running/autonomous sessions.
Minidumps: Crashpad wrote dumps for all four crashes and the Sentry integration uploaded them at the subsequent app startups (local Crashpad db swept clean each time).
- Crashpad
client_id:c022cf05-35e3-4f4e-9b4a-c4c68f176905 - Sentry
did:e6db0749-fa5b-4a66-900d-313bdbe10bd4
The four events should be findable under those IDs around the UTC timestamps above. One captured Sentry event id from the 2026-07-22 19:14:57Z restart:
1a18be03af2243a38b279cd0adca2e8d.Bug 2 — every fatal crash leaves the package unlaunchable until manual Repair
This is arguably the worse bug for ordinary users. After every fatal crash, Windows flags the MSIX package
Modified(appxState=2) and refuses to activate the app — launch attempts die before any app code runs (zero log lines).The OS then loops into Microsoft Store remediation, which cannot service the Developer-signed non-Store package (AppXDeploymentServer errors 8107 "invalid integrity check for a non-AppStore package" and 8104 /
0x80070057), and logsTrying to repair ACLs for C:\Program Files\WindowsApps\Claude_…→ACLs repaired successfullyover and over (15+ times observed).The only reliable fix is Settings → Apps → Claude → Advanced options → Repair, which re-downloads the full
.msixfromdownloads.claude.aiand re-registers it — needed after every single crash.Two aggravating factors observed in the AppX/AppModel event logs:
- The packaged CoworkVMService (
cowork-svc.exe) survives the app crash and holds a file lock, so the automatic repair fails with0x80070020(sharing violation creatingapp\resources\cowork-svc.exe) until aForceTargetApplicationShutdownregister kills it (cost: ~3 extra minutes of outage). - Repair's Register step reports
0x80073D02 ERROR_PACKAGES_IN_USEwhen the app relaunches mid-repair — cosmetic, but alarming to users.
Windows Error Reporting captures none of this (no Event 1000/1001 — Crashpad intercepts the fault), so from the OS's perspective the app just refuses to start with no diagnosable error. A non-technical user would plausibly conclude the app is broken and reinstall.
Ruled out during diagnosis
- Driver: reproduced identically before and after an NVIDIA driver update; zero
nvlddmkm/TDR/dxgkrnl/WHEA events in the System log across all four crashes - Memory: 10–12 GB system RAM free at every crash instant (app's own
[process-memory]telemetry); no Resource-Exhaustion-Detector events; pagefile peak 219 MB - Disk/package corruption prior to the crashes: the 1.24012.1 update staged and registered cleanly;
Get-AppxPackageStatus: Okbetween episodes
Workarounds found (for other users hitting this)
- After a crash: Settings → Apps → Claude → Advanced options → Repair (kill leftover Claude processes incl.
cowork-svc.exefirst to speed it up) - Prevention: avoid the in-app Browser pane on this build, or launch with GPU acceleration disabled (identity-preserving):
Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude -Command 'app\Claude.exe' -Args '--disable-gpu'
🤖 Diagnosed and drafted with [Claude Code](https://claude.com/claude-code) (forensics: app logs, Crashpad/Sentry state, WER + AppXDeployment/AppModel event logs)
- Claude desktop app 1.24012.1.0 (MSIX
Adding an independent reproduction with the same exit code, on Windows 10 — the other reports in this cluster (#80999, #81159) are all Win11 26200, so this may rule out an OS-build-specific cause.
Environment
- Claude Desktop 1.24012.9 (MSIX), Windows 10 Pro 19045
- NVIDIA GeForce RTX 3050 Ti Laptop (driver 32.0.15.7247) + AMD Radeon iGPU (hybrid laptop)
Crash
Single occurrence. The in-app Browser pane was loading a heavy web app (WASM SQLite + SharedWorker + IndexedDB). The pane was being driven programmatically by the in-app agent session at the time (same pattern as #81159), and a screenshot/capture was attempted while the pane was not displayed ("not compositing frames" state — the hidden-pane angle of #80999) ~1 second before the crash:17:29:03 [warn] [Preview] capturePreviewScreenshot failed 17:29:04 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } // = 0x060C201Emain.log stops mid-session at that line — the whole app died instantly. System was otherwise healthy: Chrome with multiple tabs + YouTube playback unaffected, no TDR/display events in the System log. (Earlier GPU
crashedevents on this same machine — e.g. exitCode 34 on an older build — did not kill the app, matching the regression framing here.)Package corruption aftermath (same as OP)
8 seconds after the crash, Windows flagged the package Modified and started an automaticRegisterByPackageFullNamerepair, which failed repeatedly with0x80073D02. Manual reinstall then failed with0x80073CF9, inner error:0x80070020: could not create ...\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exeCoworkVMServicekept running through all of this and could not be removed by the installer ("Access is denied"), so every repair/reinstall hit the file lock (same family as #46179 / #57221).Recovery
Reboot (released the service lock) → fresh MSIX install of the same 1.24012.9 succeeded. The Settings → Apps → Repair path was not tried, so I can't confirm whether it would have worked without a reboot in this state.Confirming this on a completely different configuration — Windows 10 instead of 11, Quadro instead of GeForce, but the same NVIDIA driver 32.0.16.1074 you tested. Strong signal the fault is in the app, not the setup.
Environment
Claude desktop 1.24012.9.0 (MSIX Claude_pzs8sxrjxfjjc, x64)
Windows 10 Pro 22H2, build 19045.6456, 32 GB RAM
GPU: NVIDIA Quadro RTX 5000, driver 32.0.16.1074 (2026-07-02), WDDM 2.7, dual monitor
No GPU or driver faults in the system log; dxdiag reports no problemsCrash — identical signature
The app dies during the Cloudflare Turnstile challenge on the sign-in screen, before any account access. Last lines of main.log:
[warn] Blocked permission check { permission: 'notifications',
requestingOrigin: 'https://challenges.cloudflare.com/', ... topFrameUrl: 'https://claude.ai/' }
[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Same exitCode: 101457950 (0x060C201E). Worth noting the trigger isn't limited to the in-app Browser pane — Turnstile's WebGL fingerprinting on the login screen hits it too, so the user never reaches the app at all.
Bug 2 is worse on Windows 10: Repair does not fix it
On Windows 10 the "Repair" button (Settings → Apps → Claude → Advanced options) performs a Register from AppxManifest.xml only — it does not re-download the .msix. AppXDeploymentServer log:RegisterByPackageFullName ... RepairAppRegistrationOption
Register ... completed successfully
Overall time: 438 ms438 ms, no download, result 0x0 — yet (Get-AppxPackage Claude).Status still returns Modified, NeedsRemediation. Only a full Add (running Claude Setup.exe) clears the flag, and the installer auto-launches the app immediately after install, which crashes on Turnstile and re-flags the package within seconds.
The documented workaround is therefore unreachable on Windows 10:
Invoke-CommandInDesktopPackage ... -Args '--disable-gpu' fails with 0x80073CFC while the package is flagged — and it cannot be un-flagged.
Attempts to register while processes remain fail with 0x80073D02 ERROR_PACKAGES_IN_USE / 0x80004004 deployment aborted due to active service Claude_pzs8sxrjxfjjc!Claude — CoworkVMService survives the crash and cannot be disabled (Set-Service → Access Denied, packaged service).
Killing the app in a tight loop during install to prevent the first launch also failed; the package is flagged before the process is reachable.Ruled out: WMI repository (winmgmt /verifyrepository → consistent), system files (sfc and DISM both clean), WindowsApps ACLs untouched, MSIX SHA256 matches a fresh download from claude.com.
Net effect: on Windows 10 the app is permanently unusable after the first launch, with no user-accessible recovery path. A hardware-acceleration toggle that persists before first render — or simply not letting a GPU crash flag the package — would make this survivable.
Follow-up with two stronger data points collected since my previous comment.
- Second machine, no NVIDIA hardware at all — identical crash
Claude desktop 1.24012.9.0, Windows 11 Pro build 26200, 32 GB RAM
GPU: Intel UHD Graphics 770 (32.0.101.7082) + AMD Radeon RX 6800 XT (32.0.21037.1004)
Same exitCode: 101457950 on the Turnstile challenge, same getInternalformatParameter probe burst in claude.ai-web.log, same Modified, NeedsRemediation flag afterwards.That makes three GPU vendors across two Windows versions: GeForce RTX 2080 (yours), Quadro RTX 5000, and AMD/Intel. The driver-version overlap I flagged earlier is a coincidence — this is not driver-specific.
- Same-engine control test rules out the GPU stack entirely
I replicated the crashing probe pattern in a Chromium 148 browser on the same machine, same GPU, same ANGLE D3D11 path as the crashing app (app reports Chrome 148.0.7778.280): 42 getInternalformatParameter calls with invalid internalformats, plus WEBGL_lose_context loseContext/restoreContext.
Renderer: ANGLE (AMD, AMD Radeon RX 6800 XT (0x000073BF) Direct3D11 vs_5_0 ps_5_0, D3D11)
42 probes run, 12 rejected by the driver, context lost and successfully restored
Result: browser survived the entire set, no GPU process crashSame Chromium major, same driver, same adapter — the browser is fine, the app dies.
- Forensics on the affected machine
All 9 package binaries carry valid Authenticode signatures (CN="Anthropic, PBC" for claude.exe, cowork-svc.exe, chrome-native-host.exe; Microsoft for the bundled runtime DLLs). So Modified is a deployment bookkeeping state, not on-disk tampering.
Zero display-driver events (TDR / WHEA / amdkmdag / dxgkrnl) in the System log over 14 days.
Zero WER 1000/1001 records — Crashpad intercepts the fault, so the OS sees nothing.
No other MSIX package on the system is in a Modified state; deployment machinery is otherwise healthy.
--disable-gpu does not prevent the crash: the GPU process is still spawned and dies, then GPU process launch failed: error_code=18 repeats 5×, followed by FATAL: GPU process isn't usable. Goodbye. The app kills itself. Escalating flag sets (--in-process-gpu, --use-gl=swiftshader --use-angle=swiftshader, --disable-webgl) were also tried without success.Net: the crash is reachable from the login screen alone, survives every user-side mitigation, and permanently bricks the package on Windows 10. Not letting a GPU-process crash flag the package would by itself make this recoverable.
Same bug here, with some additional diagnostics that narrow down where the crash lives.
Environment: Claude Desktop 1.24012.9 (MSIX), Windows 11 Home 22631, NVIDIA RTX 4070 Ti SUPER (driver 32.0.15.9186, Jan 2026, installed March — unchanged), Claude Code 2.1.219.
Crash signature (5 occurrences, 2026-07-28 → 07-29):
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Every crash: same exit code 0x060C201E, whole app dies (no GPU-process relaunch), Windows logs an AppHang (Event 1002), and the MSIX package is left in Modified state so normal launch is blocked until Settings → Apps → Repair.
Timeline evidence it's a regression: main.log history back to 2026-07-09 shows zero GPU-process crashes before 07-28. The app package updated 07-24 (folder creation date). No Windows update or GPU driver change in that window.
Trigger correlation: every crash followed in-app Browser pane activity on external sites. The clearest case: pane opened several x.com tabs at 17:30, GPU process died 17:32. x.com runs heavy WebGL/fingerprinting probes, consistent with the OP's analysis. Localhost previews never crashed it.
Key finding — the crash reproduces in the WARP path, so disabling hardware acceleration does NOT help:
- With
isHardwareAccelerationDisabled: trueinclaude_desktop_config.json, the GPU process runs with--use-angle=d3d11-warp-webgland still dies with the identical exit code (2 crashes in this state). - With
--disable-gpupassed to the exe: Browser pane still serves WebGL 1+2, renderer stringANGLE (Microsoft, Microsoft Basic Render Driver ... D3D11)— the app's forced gpu-preferences keep WebGL-on-WARP alive regardless of the flag. --disable-webgl/--disable-3d-apisdo not propagate to renderers (removed from modern Chromium), so users have no way to close the WebGL path at all.
Suggestion: the app already ships a window with
webPreferences: { webgl: false }(the feedback window), so the plumbing exists — exposing that (or a setting) for the Browser pane webContents would give users an effective mitigation until the WARP/ANGLE crash itself is fixed. Alternatively, catching the fatal GPU-process exit (0x060C201E) and relaunching instead of dying would at least stop the MSIX-Modified/Repair loop.Recovery note for others hitting this: launching the exe directly (e.g.
& (Join-Path (Get-AppxPackage -Name Claude).InstallLocation 'app\Claude.exe')) bypasses AppX activation, which appears to be what blocks relaunch when the package is flagged Modified — worth trying before a full Repair. Kill leftoverclaude.exe/cowork-svc.exeprocesses first (single-instance lock).- With
Hello, I think I also encountered this issue, and my issue blocks my usage of Claude Desktop app's internal browser which would be useful for me. Please be mindful about its priority.
Additional reproduction: AMD GPU, cross-driver evidence, and reproduction under WARP software rendering
Adding a second environment with the same fatal signature and several observations that may help narrow the cause.
Environment
- Claude Desktop 1.24012.9.0 (MSIX), Electron 42.7.0
- Windows 11 Pro build 26200
- AMD Radeon RX 9070 with an integrated Radeon iGPU
- Matching crashes occurred before and after an AMD driver update
Same failure as OP
- No matching GPU-process crashes were found in the retained logs from earlier builds. The fatal crashes began after the 1.24012.x update, with four occurrences over approximately three days.
- Each crash occurred within approximately 1 to 2 seconds of embedded Browser preview activity while the loaded page was running WebGL capability probes:
[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, // 0x060C201E serviceName: 'GPU' }- The package subsequently changed to
Modified, NeedsRemediation, and activation failed with0x80073CFCuntil the package was repaired. - Memory pressure was not present. The latest pre-crash telemetry showed approximately 2.8 GB application RSS and approximately 48 GB of free system memory.
- No corresponding WER fault, display-driver TDR event, or DxgKrnl error was logged. The GPU process exited with the same custom code on every occurrence, although that alone does not establish why Chromium terminated it.
Not isolated to one driver version or GPU vendor
The AMD display driver was updated during the investigation, and the same fatal signature recurred afterward. Combined with the OP's NVIDIA reproduction across two driver versions, this makes a defect specific to one GPU vendor or driver version less likely.
Key finding:
--disable-gpuis not a sufficient workaroundWhen launched with:
--disable-gpu --disable-gpu-compositingthe GPU helper continued to provide WebGL through WARP:
--use-angle=d3d11-warp-webglThe identical
0x060C201Efailure reproduced in that configuration. The failure therefore does not require hardware GPU acceleration and persists when Chromium uses its Windows software-rendering backend.The crashes were consistently and immediately preceded by WebGL capability-probe activity, including the
INVALID_ENUMandCONTEXT_LOST_WEBGLsequence described by the OP. This is a strong temporal correlation, although it does not by itself prove which WebGL component is responsible.Stricter workaround under evaluation
Launching with:
--disable-gpu --disable-gpu-compositing --disable-gpu-rasterization --disable-software-rasterizercauses the GPU helper to run with:
--use-gl=disabledA short stress test using multiple embedded Browser tabs, image-heavy HTML previews, and local preview servers completed without another crash. This has not yet been validated over an extended period. The tradeoff is that WebGL and 3D content cannot render in the embedded Browser.
Repair issue
After a crash, reinstall or repair may fail with
0x80073CF9. In this reproduction, the underlying AppX deployment error was0x80070020, a sharing violation while replacingcowork-svc.exe. The file was held by CoworkVMService. Stopping that service allowed installation to complete, and the service restarted afterward.This is separate from the stale
chrome-native-host.exelock and0x80073D05condition already documented.I can provide additional sanitized excerpts or test a build containing a candidate fix.
Another reproduction: RTX 5000 Ada + Intel hybrid on Win10 19045, 115 GB free RAM at the crash instant — and Bug 2 needed a full uninstall/reinstall, 25 Repair attempts over 55 h all failed
Adding a data point that I think strengthens the driver-agnostic claim and kills the memory-pressure reading. More importantly, I have AppXDeploymentServer forensics for Bug 2 that back up @SaLoGeF's "Repair does not fix it on Windows 10" finding with hard numbers.
Environment
- Claude Desktop 1.24012.9.0 (MSIX
Claude_pzs8sxrjxfjjc, x64) - Windows 10 Pro 19045, zh-CN locale
- Dell Precision 7780 mobile workstation, i9-13950HX, 128 GB RAM
- Hybrid graphics: NVIDIA RTX 5000 Ada Generation Laptop GPU (driver 32.0.15.7342 = R570 U6 / 573.42, dated 2025-06-11) + Intel UHD Graphics (31.0.101.5522, 2024-05-11)
- HAGS enabled (
HwSchMode=2; registry key last written 2024-10-29, i.e. unchanged through the crash) - Chromium hardware acceleration at default (enabled — no
isHardwareAccelerationDisabledinclaude_desktop_config.json) - Single crash: 2026-07-27 23:01:09 local (UTC+8) = 15:01:09 UTC
Bug 1 — same signature, probe→death gap is 1 second
%APPDATA%\Claude\logs\unknown-window.log:23:01:00 [error] Loading the script 'https://www.walmart.com/akam/13/2fadd2cb' violates ... CSP 23:01:08 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat <- 19 lines, 23:01:08 [warn] ... invalid internalformat when EXT_color_buffer_[half_]float is not enabled both EXT 23:01:08 [warn] ... invalid internalformat when EXT_color_buffer_float is not enabled variants 23:01:08 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127 23:01:09 [error] %c%d font-size:0;color:transparent NaN 23:01:09 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size 23:01:09 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lostmain.log, same second:2026-07-27 23:01:09 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }101457950 = 0x060C201E. main.log stops mid-write; whole app gone. Line-for-line match with the OP, down to the%c%d font-size:0;color:transparent NaNand the WOFF 2.0 OTS error.Two more bot-detection vendors on the trigger list
The pane was being driven programmatically by an agent session (Workflow tool). In the ~2 minutes before the crash it loaded, among others:
walmart.com— the CSP-blocked script path is/akam/13/..., i.e. Akamai Bot Managertrademarks.justia.com/connect.justia.com- several pages emitting
getAwsWafToken(): AwsWafIntegration is not defined - check challenge.js script in configuration.json— AWS WAF challenge
So alongside Cloudflare Turnstile and x.com, Akamai Bot Manager and AWS WAF challenge pages also reach the crashing probe path. Three different commercial bot-detection products now, consistent with the OP's "standard fingerprinting suite" framing.
Memory pressure is not it
App's own telemetry, 48 s before the crash:
2026-07-27 23:00:21 [info] [process-memory] trigger=interval tree_rss_sum=3600MB electron(18)=3600MB top=[electron_renderer:21676:803MB electron_main:18376:353MB electron_gpu:23184:311MB ...] sys_free=114457MB/130757MB114 GB of 128 GB free, GPU process at 311 MB, 16 GB of dedicated VRAM essentially idle. Earlier reports cited 10–12 GB free on 32 GB machines; this widens that margin a lot.
On the "is it load?" question: this session was unusually heavy on the pane — 116
browser:open_site-related records in the preceding 20 min,openTabsreaching 5, electron process count 10 → 18. High pane throughput plausibly raises the odds of loading a probe page, but nothing was being exhausted.Driver-agnostic
RTX 5000 Ada is Ada Lovelace workstation silicon, distinct from the Quadro RTX 5000 (Turing) reported earlier despite the name. More usefully, my driver is 573.42 from 2025-06 — roughly a year older than the 32.0.15.9595 / 32.0.16.1074 / 32.0.15.9186 builds others tested. Same crash, same exit code. Also: zero TDR /
nvlddmkm/dxgkrnl/ display-reset events in the Windows System log anywhere near the crash.
Bug 2 — 25 Repair attempts over 55 hours, all failed; only uninstall + reinstall worked
This is where I can add the most. Full
Microsoft-Windows-AppXDeploymentServer/Operationalforensics for the outage window (2026-07-27 22:00 → 2026-07-30 09:00): 843 Claude-related events, spread 293 / 121 / 120 / 309 across the four days — the OS never stopped churning.Package state, captured mid-outage (
Get-AppxPackage *Claude* -AllUsers, 2026-07-30 06:19):Name : Claude Version : 1.24012.9.0 PackageFullName : Claude_1.24012.9.0_x64__pzs8sxrjxfjjc InstallLocation : C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc Status : Modified, NeedsRemediation PackageUserInformation : {S-1-5-...-500 [Administrator]: Installed}25 separate
RegisterByPackageFullNameoperations withRepairAppRegistrationOption(mix of OS-automatic remediation on failed activation and my own Settings → Apps → Claude → Repair clicks), none of which restored the app:07-27 23:01:12 23:01:18 23:06:41 23:06:53 23:08:20 23:16:44 23:17:56 23:24:55 23:25:28 23:33:26 23:38:39 07-28 07:54:40 07:54:47 07:55:15 18:57:32 07-29 00:11:49 00:19:09 00:27:29 00:28:14 07-30 05:23:03 06:15:19 06:15:32 06:19:21 06:20:24 06:20:25What finally worked — and note how it was reached. The
Get-AppxPackageoutput above is timestamped 06:19; seeingStatus: Modified, NeedsRemediationin black and white is what made it obvious that no amount of Repair was going to help. The next two deployment operations in the log are 2 minutes later:07-30 06:21:32 Id=603 op=Remove <- full uninstall 07-30 06:34:08 Id=603 op=StageUserData + register <- fresh installSo the entire 55-hour outage was gated on running one diagnostic command that nothing in the product or the OS ever suggests.
Microsoft-Windows-AppXDeployment/Operationalconfirms:07-30 06:34:08 Id=327 — packages to install: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc; packages to remove: NULL. First successful renderer log line after that: 07-30 07:01:28. So the renderer log shows a clean 2.5-day hole:2026-07-27 23:01:09 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost 2026-07-30 07:01:28 [error] Setting the document's base URI to 'https://claude.ai/' violates ...Net user-visible outage: 2026-07-27 23:01 → 2026-07-30 06:34, ~55 hours.
The leftover-process lock, timestamped
The OP flagged that
cowork-svc.exesurvives the crash and blocks repair. My log dates that precisely — Windows fired automatic repair 3 seconds after the "instant death" and was refused because the app was still running:07-27 23:01:12 Id=638 Package not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude} 07-27 23:01:12 Id=419 0x80073D02: cannot install because the following apps must be closed: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc 07-27 23:01:12 Id=401/404 Register from AppxManifest.xml failed, 0x80073D02 07-27 23:01:18 (identical, retry) 0x80073D02Then at 23:06:42 a later attempt did tear the service down —
TerminateSingleService succeeded (CoworkVMService)— confirming the packaged service was the thing holding the lock. Error histogram for the whole window:0x80073D02×6,0x80073CFA×1 (the latter during the 07-30 reinstall).One honest difference from the OP's report: I see no "Trying to repair ACLs for C:\Program Files\WindowsApps\Claude_…" loop in my logs — zero ACL events. So that particular spin may be Win11-specific or environment-specific.
The user-experience point, from someone who lived it
To be precise about that 55 hours: it is wall-clock from the log, not 55 hours of active troubleshooting — I was away from the machine for much of it. But that is rather the point. I'm not a Windows deployment expert, and there was nothing to act on: no Event 1000/1001, no error dialog, no diagnosable message. The app simply does nothing when launched, and the Repair button — which I clicked repeatedly — silently changes nothing. Antivirus quarantine was my first hypothesis, since this machine runs two Chinese AV products, so some of that time went into whitelisting directories that turned out to be irrelevant.
The single biggest thing that slowed me down was fear of data loss. The only remedy that works is uninstalling the app, and I had no idea whether that would take my local Claude Code session history with it. So before touching anything I spent most of my hands-on time backing up local data, specifically to preserve those conversations. Only once I was satisfied the backup was complete did I proceed — and I got to the uninstall/reinstall answer by working through it step by step with claude.ai in the browser, which is obviously not available to someone whose only entry point was the desktop app.
Three concrete asks:
- On failed activation, surface something. Even a one-line "the app didn't shut down cleanly — a reinstall may be required", or just "run
Get-AppxPackage *Claude* | fl Name,Statusand check forModified, NeedsRemediation", would have collapsed this into 15 minutes. Repair should also stop presenting itself as a fix for this state when it demonstrably is not one. - Say explicitly whether uninstalling preserves local session history, in that message or in the docs. Right now the only working remedy looks, to a user, like it might destroy their work. That hesitation is a bigger cost than the reinstall itself.
- Fix the shutdown path so the packaged service dies with the app. The 0x80073D02 above shows the OS trying to self-heal 3 seconds in and being blocked by the app's own leftover process. If
cowork-svc.exewent down with the crash, automatic remediation might well have succeeded on the first try.
Summary of what this adds
- 4th GPU family (RTX 5000 Ada) on the oldest driver tested so far (573.42, 2025-06) — same crash.
- 128 GB machine with 114 GB free at the crash instant — memory pressure ruled out with a wide margin.
- Two more bot-detection vendors on the trigger list: Akamai Bot Manager (
walmart.com/akam/…) and AWS WAF. - Agent-driven pane at high throughput (116
open_siterecords / 20 min) — relevant to the unattended-workflow angle. - Bug 2 quantified: 843 deployment events, 25 failed Repair operations across 55 hours, resolved only by uninstall + reinstall — independent confirmation of @SaLoGeF's Win10 finding, with the event-log timeline to back it.
- The leftover-
cowork-svc.exelock captured 3 seconds after the crash as0x80073D02/ "affected apps are still running". - A UX cost that may not be obvious from the other reports: the only working remedy (uninstall) is one users are afraid to perform, because nothing tells them whether local Claude Code session history survives it.
Happy to provide full log excerpts or Crashpad IDs if useful.
- Claude Desktop 1.24012.9.0 (MSIX
Same crash on 1.24012.9 — plus new evidence: the post-crash Repair schedules a forced app shutdown hours later
Environment
- Claude desktop (MSIX): 1.24012.9.0 (
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc) - Windows 11 Home 25H2, build 10.0.26200, x64
- CPU: Intel Core Ultra 7 265 · RAM: 32 GB
- Graphics: Intel(R) Graphics (driver 32.0.101.8132) plus an Insignia USB3.0-to-dual-HDMI adapter (DisplayLink-class, driver 1.9.2501.1223) — noting this because USB display adapters are a well-known trigger for Chromium GPU-process instability, which may be a factor in who hits this bug
Bug 1 reproduced — GPU crash 4 seconds after the in-app Browser preview tab opened
From
%APPDATA%\Claude\logs\main1.log(last lines of the session — the app died instantly, nothing logged after):2026-07-30 15:25:34 [info] [PreviewContext] Opened preview user tab { serverId: 'preview-local_...', tabId: 'tab-2', openTabs: 3 } 2026-07-30 15:25:38 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }101457950 decimal ==
0x060C201E— same code as the OP. Also matches #81159. No WER report and no crash dump is written (%APPDATA%\Claude\Crashpad\reportsstays empty), so from Windows' point of view the app simply vanishes — nothing in Event Viewer's Application log at all. An earlier shutdown the same day (~13:55) left Sentry error data but no log tail, consistent with the same failure.Bug 2 reproduced — plus a follow-on repair loop worth documenting
After the crash the package was unlaunchable until Settings → Apps → Claude → Advanced options → Repair. But
Microsoft-Windows-AppXDeploymentServer/Operationalshows the repair never fully completes while the app is running: the Add step succeeds, then the final re-register fails with 0x80073D02 ("Unable to install because the following apps need to be closed") because the app relaunches immediately after repair:16:00:32 Id 603 RepairPackageOperation started (re-downloads 1.24012.9 .msix from downloads.claude.ai) 16:01:14 Id 400 Deployment Add operation finished successfully (~41 s) 16:01:14 Id 9641 0x80004004: Deployment aborts due to active service Claude_...!Claude 16:01:14 Id 638 Packages were not updated because affected apps are still running 16:01:14 Id 401/404/419 Register failed with 0x80073D02Windows then completes the pending registration ~4 hours later using
ForceTargetApplicationShutdownOption— killing the running app mid-use with no warning:20:06:10 Id 603 RegisterByPackageFullName ... Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption 20:06:11 Id 400 Register finished successfully <-- the running app was force-closed at this momentSo the user-visible pattern is: GPU crash → Repair → app works → second "random" shutdown hours later (actually Windows finishing the half-failed repair). Each Repair while the app is running re-arms this. The same 0x80073D02 failure repeated at 20:07 and 20:58 the same day.
Workaround that breaks the loop: fully quit Claude first (tray icon → Quit; verify no
claude.exe/cowork-svc.exein Task Manager), then run Repair — the register step completes immediately and no forced shutdown gets scheduled.Happy to provide full
main.log/main1.logand the complete AppX deployment event export on request.- Claude desktop (MSIX): 1.24012.9.0 (
Confirming this on Windows ARM64 — same exit code, same signature — plus two findings that may help narrow the fault.
Environment
- Claude Desktop 1.24012.9.0 (MSIX / Windows Store), Claude Code 2.1.219
- Windows 11 Home 26200 (ARM64), Surface Pro 11, Snapdragon X X1P64100
- GPU: Qualcomm Adreno X1-85, driver 31.0.137.0
- Electron 42.7.0 / Chrome 148.0.7778.280, 16 GB RAM
Reproduction (5/5 crashes today, all exitCode 101457950 / 0x060C201E)
Openinghttps://suno.com/createin the in-app Browser pane (preview_start) kills the GPU process 5–11 s after pane creation and takes the whole app down. Console signature identical to OP:
WebGL: INVALID_ENUM: getInternalformatParameter×19 →requestAdapterpowerPreference warning ×2 →GPU process gone: { reason: 'crashed', exitCode: 101457950 }.
Sessions that never open the Browser pane never crash; a different URL (gemini.google.com) in the same pane on an earlier day was fine.Finding 1: "Disable Hardware Acceleration" does not prevent it
WithisHardwareAccelerationDisabled: trueconfirmed loaded at startup, the crash reproduces identically. Inspecting the live GPU process afterwards: no software-rendering flags on its command line, and the Adreno user-mode driver DLLs are loaded — i.e. the toggle does not propagate to the GPU process (consistent with electron/electron#17180 / #51363). So this crash is not user-avoidable via that setting.Finding 2: GPU-vendor-independent
OP reproduced on NVIDIA RTX 2080; this repro is on Qualcomm Adreno X1-85 (ARM64). Same exit code and signature on both — pointing at the Chromium/ANGLE/Dawn layer rather than a specific vendor driver.No Crashpad minidumps are generated (
Crashpad/reportsstays empty), which makes further user-side diagnosis difficult.Cross-ref: #81159 appears to be the same crash.
Confirming again — Windows 10 Pro 19045.6456, NVIDIA GeForce RTX 3090.
Same exit code (101457950 / 0x060C201E), same trigger (in-app Browser pane → external page → WebGL getInternalformatParameter probe burst → CONTEXT_LOST_WEBGL → GPU process gone), same second-timestamp instant death.
One data point I don't think is in the thread yet: I had TdrLevel=0 (TDR detection disabled) during my first two crashes, then explicitly set it to TdrLevel=3 (Windows default) to see if it would at least convert the crash into a recoverable TDR-timeout instead. It didn't — crashed again with the identical signature, and no Event ID 4101 fires in the System log either before or after the change. Consistent with the rest of this thread's finding that this is an outright process crash, not a driver hang — TDR settings aren't a relevant lever either way.
Also: crashed on driver 536.23 (R535) and 610.47 (R610 Studio, current as of writing) with the identical signature — another data point for "not driver-specific," now across three driver generations combined with everyone else's reports.
Didn't hit Bug 2 either time (app auto-relaunched cleanly, no Modified flag) — for what it's worth as a contrast to the Windows 10 reports above where Repair didn't resolve it.
Additional data point: same GPU crash (exitCode 101457950 / 0x060C201E) on 1.24012.9.0, triggered by a Cloudflare bot-detection probe in the in-app Browser
Same signature as #80444 and #81159, on a different GPU combination — adding data in case it helps narrow down the cause.
Environment
App version 1.24012.9 ( Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, MSIX / windowsStore)CCD 2.1.219, Node 24.18.0 OS Windows 11 Enterprise 10.0.26200, de-DE GPU 0 Intel Iris Xe Graphics — 32.0.101.7084 (2026-01-15) GPU 1 NVIDIA GeForce MX550 — 32.0.15.9608 (2026-03-31) GPU 2 MirrorOp Virtual Graphics Adaptor — 1.1.185.70 (2019-10-01) Display DELL P2722H, 1920x1080 @ 60 Hz, scaleFactor 1 Hybrid graphics, no per-app GPU preference set. Note the third adapter: a virtual display adapter (MirrorOp / wePresent presentation software) is present alongside the hybrid pair. Might be relevant — the reports so far have single-vendor or hybrid setups; this one has a stale virtual adapter in the enumeration list.
Trigger
Agent-driven research in the in-app Browser pane on a German retail site (
mindfactory.de) that is behind Cloudflare bot detection. The crash happens while the page runs its WebGL/WebGPU capability-probe burst — i.e. the fingerprinting stage of the challenge, not any interaction with the challenge widget itself.Reproduced 3× in one day:
11:25:09,13:44:51,13:47:13(local time, 2026-07-31).Log evidence
%APPDATA%\Claude\logs\unknown-window.log— 1–2 s before every crash, a burst of ~20 identical probe lines plus a WebGPU adapter request:2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat (x12 identical) 2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_[half_]float is not enabled 2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled 2026-07-31 13:47:12 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127 2026-07-31 13:47:12 [error] %c%d font-size:0;color:transparent NaN 2026-07-31 13:47:13 [warn] A valid external Instance reference no longer exists.On the 13:44 occurrence the context loss is explicit:
2026-07-31 13:44:51 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost%APPDATA%\Claude\logs\main.log— the GPU process dies with the exact same exit code every time, and this is the last line of the session; the main process goes down with it, no graceful shutdown, no further log output until the next manual launch:2026-07-31 11:25:09 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' } 2026-07-31 13:44:51 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' } 2026-07-31 13:47:13 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Restart timestamps from the same file confirm the app never recovered on its own:
2026-07-31 10:13:30 [info] Starting app 2026-07-31 11:37:47 [info] Starting app <- 12 min after the 11:25:09 crash 2026-07-31 13:45:46 [info] Starting app <- after the 13:44:51 crash 2026-07-31 13:48:19 [info] Starting app <- after the 13:47:13 crashSecondary failure: Windows "Repair" cannot run after the crash
Same as reported in #80444/#81159, but here is the exact Windows-side reason. Immediately after the crash,
Settings → Apps → Claude → Advanced options → Repairreports "Diese App konnte nicht repariert werden" / "This app could not be repaired". Event logMicrosoft-Windows-AppXDeploymentServer/Operational:13:48:14 Error 401 Register / volume C: for Claude_1.24012.9.0_x64__pzs8sxrjxfjjc failed with 0x80073D02 13:48:14 Error 404/419 0x80073D02: cannot install because the following apps need to be closed: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc 13:48:14 Error 8104 Failed to set the trust label for the package, flags 0x0. Error: 0x80070057 13:48:14 Error 8107 Invalid integrity check attempted for a non-AppStore/non-AppInstaller package 13:48:14 Info 613 Register: Failed to reach state ResolvedDeferredRegistrations (953 ms)0x80073D02isERROR_INSTALL_PACKAGE_IN_USE. Repair fails because child processes survive the crash and keep the package in use — in this casecowork-svc.exe(confirmed running with the app gone). Corroborating evidence from the next launch:2026-07-31 11:37:48 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile 'C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe' -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'Also:
AppxManifest.xmlin the install location hasLastWriteTime = 2026-07-31 13:47:26— 13 seconds after the crash, i.e. the crash path touches the package and Windows flags it as modified.Get-AppxPackage Claudestill reportsStatus: Ok, so the "damaged" state is not visible via the normal status field.No local crash dump is produced
%APPDATA%\Claude\Crashpad\contains onlysettings.dat— no minidump reports at all.- No
Application Error(Event ID 1000) and no WER report forClaude.exein the Windows event log.
So on this machine the crash is invisible to both Crashpad and WER; the only local trace is the two log lines above. If you need a dump for this signature, the reporter path appears to be broken for GPU-process kills in the MSIX build.
Impact
Any agent-driven research task that touches a Cloudflare-protected site kills the whole app mid-run, loses the session, and leaves the MSIX package in a state where the documented recovery step (Repair) fails until leftover processes are killed manually. There is no user-accessible way to disable hardware acceleration in the app —
%APPDATA%\Claude\config.jsonhas no corresponding key, and MSIX gives no way to pass--disable-gpufrom a normal shortcut.Requests
- Don't let a GPU-process crash take the main process down — fall back to SwiftShader / software compositing for the Browser pane, as already asked for in [Windows] Desktop app 1.24012.1: fatal GPU-process crash (0x060C201E) via in-app Browser tab; crash leaves MSIX package unlaunchable (appxState=2) until Repair #80444.
- Add a persisted "disable hardware acceleration" setting so there is a recovery path without PowerShell gymnastics.
- Make sure all child processes (
cowork-svc.exein particular) are terminated on abnormal exit, so Windows Repair is not blocked byERROR_INSTALL_PACKAGE_IN_USE. - Guard the WebGL/WebGPU capability-probe path — the crashing input is a read-only capability enumeration (
getInternalformatParameterwith unsupported enums +requestAdapter()), which should never be able to kill the GPU process.
Confirming this on completely different hardware, plus three findings that narrow it down.
Same exit code, same log lines, same day-one-of-1.24012 onset — but on a single integrated Intel GPU, not a discrete NVIDIA card and not a hybrid-graphics laptop. That rules out both the vendor-driver and the Optimus adapter-negotiation theories floated in #80468.
Environment
Claude Desktop 1.24012.9 (MSIX / Store) Claude Code (CCD) 2.1.219 OS Windows 11 Pro 25H2, build 26200 CPU / GPU 13th Gen Core i7-1355U / Intel Iris Xe — the only display adapter present RAM 16 GB Three fatal crashes in 88 minutes (12:36:22, 12:49:02, 14:04:15 local), all
exitCode: 101457950, all with your exact renderer chain includingOTS parsing error,
%c%d font-size:0;color:transparent NaNandCONTEXT_LOST_WEBGL.main.logstops
mid-stream each time; no WER entry, no minidump, emptyCrashpad\reports.MSIX corruption matches too — the app would not relaunch after the second crash and needed
reinstalling.
1. One crash had no browser action at all — and no new tab
This is the finding I think matters most, because it breaks the "page runs a WebGL probe"
framing.The 12:36:22 crash happened in a preview pane that had been open and untouched for
13 minutes 24 seconds. The owning session issued no tool call in that window — its
previous output was at 12:35:10 and the next user input at 12:46:20.main.logcontains
nothing between 12:35:12 and the crash except two cached-OAuth lookups. There is no
[Preview] Createdline and nototalContextschange.What did happen: 72 seconds earlier a ~3.1 kB block was appended to the transcript, forcing
a layout reflow of the surrounding UI. Our reading is that the pane was re-mounted as a
side effect, re-initialising its compositing surface.So the trigger is not "a page executes fingerprinting code". It appears to be a webview
compositing surface being created or re-created, and a transcript-driven reflow is
sufficient. That also means an idle pane is not safe.2. The failing WOFF2 comes from the app shell, not from page content
The page loaded in that pane was a locally served internal app on
http://localhost:8001/.
That app is deliberately built with no bundler and no web fonts — grepping its entire
source tree forwoff,@font-face,fonts.googleapisandfonts.gstaticreturns
zero hits. It uses only-apple-system, "Segoe UI", system-ui, sans-serif.The page therefore cannot be the origin of the malformed WOFF2.
OTS parsing errorfires
on a font belonging to the surrounding shell, re-parsed when the surface is rebuilt.(For completeness: two of our three crashes were triggered by an external page behind a
Cloudflare "Just a moment" interstitial, which does run canvas/WebGL fingerprinting —
consistent with your repro. The third one above shows that page is not necessary.)3.
totalContextsseparates the survivors from the fatalitiesFor the two crashes that did follow an explicit
preview_start, the app logs the new
pane as the second live preview context:14:04:10 [Preview] Created session preview context { previewId: 'preview-…', totalContexts: 2 } 14:04:10 [Preview] Created browser preview { serverId: 'browser-preview-…' } 14:04:14 OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size 14:04:15 WebGL: INVALID_ENUM: getInternalformatParameter … ×19 14:04:15 The powerPreference option is currently ignored when calling requestAdapter() … 14:04:15 A valid external Instance reference no longer exists. 14:04:15 GPU process gone: { … exitCode: 101457950 … }Every pane created at
totalContexts=1survived — including a deliberate 20-minute stress
run (16 page loads, ~20 screenshots, two colour themes, three window widths) that produced
the full WebGL warning burst without crashing. Both fatalities were attotalContexts=2.The two paths also have different terminal lines, which may be useful when bisecting:
Path Terminal line Second context created A valid external Instance reference no longer exists.Existing pane re-mounted WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
A recoverable control case, in the same logs
Worth having as a negative control: at 13:27:38 the GPU process died with
exitCode: 34, no WebGL burst, and the app kept logging normally for the next three
minutes. That was Chromium doing the right thing during a display-driver swap.So the defect isn't that the GPU process can die — it's that in the
101457950case
recovery never happens and the whole tree goes with it.GPU process gonealone is not
the signature;exitCode 101457950plus the log terminating in the same second is.Ruled out here, each measured
- GPU driver — crash Claude is either blank or non-interactive #3 occurred on Intel 32.0.101.7088 after Create SECURITY.md #1–I want to use openrouter #2 on 7084;
identical exit code. Combined with your RTX 2080, that is two vendors and three drivers. - Memory — peak Electron tree on the crash day was 4 380 MB, lower than 5 025 MB on a
crash-free day the previous week. At crash Claude is either blank or non-interactive #3: 2 462 MB in use, 5 495 MB free of 16 057 MB. - Driver hang / TDR — zero display-reset events in the Windows System log.
- Reinstall — restored the identical version and did not prevent crash Claude is either blank or non-interactive #3.
- Claude in Chrome extension — zero extension or native-host activity within ±90 s of
all three; Chrome was not running at all during crash Claude is either blank or non-interactive #3.
Blast radius
We run four concurrent Claude Code sessions in one desktop app. Each crash killed all
four, including three that had never opened a pane. One session's documentation lookup
cost three unrelated threads their in-flight context. That is what makes this expensive
rather than merely annoying.Not yet tried
We have not applied the
--disable-gpuworkaround, because #76307 reports that flag being
auto-persisted after a GPU crash and leaving the app in a CPU busy-loop. If that risk is
understood or fixed, we would happily test it and report back.Our current mitigation is simply to stop using the preview pane for anything external, and
fetch pages as text instead. Happy to run any instrumented build or capture additional logs
if that would help.- GPU driver — crash Claude is either blank or non-interactive #3 occurred on Intel 32.0.101.7088 after Create SECURITY.md #1–I want to use openrouter #2 on 7084;
Adding a data point from another affected machine, including one workaround result that isn't in the thread yet.
Environment: Claude Desktop 1.24012.9 (MSIX,
Claude_pzs8sxrjxfjjc), Windows 11 Home 26200, RTX 4090 (driver 32.0.15.9186 / Jan 2026), Alienware AW3423DWF (10-bit, P3). Same regression window as OP: browser previews on 1.22209.3 (2026-07-17 and 07-19) ran clean; every pane open since updating to 1.24012.x (2026-07-24) has killed the app.Still reproduces on 1.24012.9 — three fatal crashes logged, all identical:
2026-07-30 12:05:17 [info] [Preview] Created browser preview { serverId: 'browser-preview-1785427517751-0' } 2026-07-30 12:05:20 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Log ends there each time (no shutdown sequence); next line is
Starting appafter a Settings → Repair.New datum: the in-app hardware-acceleration toggle does NOT prevent the crash. We set Help → Troubleshooting → "Disable Hardware Acceleration", confirmed
"isHardwareAccelerationDisabled": trueinclaude_desktop_config.json, restarted (Starting app12:03:27), then opened a browser preview at 12:04:20 on a trivial page (example.com). The pane created fine and served page text; the GPU process crashed with the sameexitCode: 101457950at 12:05:37, roughly when the pane was brought into view. So Electron'sapp.disableHardwareAcceleration()path is insufficient — consistent with the WebGL-probe theory, since WebGL still executes in the GPU process under software rendering. The--disable-gpulaunch workaround from this thread is untested on our machine.Repair behavior matches OP: app refuses to relaunch after the crash until Settings → Apps → Claude → Advanced options → Repair; the Repair reports failure but the app launches afterward.
Impact note: the in-app Browser pane is the primary verification loop for our dev workflow across several projects, so this is effectively a blocker on 1.24012.x rather than an inconvenience. Happy to provide full logs or run diagnostics on request.
Another confirmation (dedicated RTX 3060 Ti, Win11 26200) — crash reproduced ~2h AFTER a DDU clean driver downgrade, plus an unattended overnight crash during automated Browser-pane use
Environment: Claude Desktop 1.24012.9.0 (MSIX
Claude_pzs8sxrjxfjjc), Claude Code 2.1.219, Node 24.18.0 · Windows 11 Pro 10.0.26200, VBS/HVCI enabled, 32 GB RAM · NVIDIA GeForce RTX 3060 Ti (dedicated GPU, no hybrid graphics/iGPU), driver 32.0.16.1062 (Studio, 2026-06-11) after a DDU clean reinstall on 2026-07-31; a newer driver installed earlier showed the same crashes.Signature (6 crashes, 2026-07-27 → 07-31, accelerating; zero crashes in the 3 weeks of logs before):
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }(0x060C201E), identical every time; whole app dies with no shutdown lines.- CodeIntegrity/Operational at the exact crash second, every time: Event 3033 (
...\app\claude.exeattempted to load...\app\vk_swiftshader.dll— blocked) + Event 3010 ×3 (unable to load...\AppxMetadata\CodeIntegrity.cat, Status 0xC000003A). - Afterwards MSIX activation refused ("This app can't open") until Repair; Repair fails with 0x80073D02 while zombie package processes linger — but terminates them as a side effect, after which the app launches again.
Data points possibly new to this thread:
- Crash reproduced ~2 hours after a DDU clean driver downgrade — further confirms driver-agnostic.
- Unattended overnight crash (04:14) while an autonomous Claude Code session used hidden Browser-pane previews —
capturePreviewScreenshot ... the Browser pane is not displayedwarning bursts appear seconds before death in 5 of 6 crashes here. - Single dedicated GPU, no hybrid setup — additional counter-evidence to the Optimus/adapter-negotiation theory from Claude Desktop App Crashing After the Latest Update on Windows #80468.
- Negative findings: no nvlddmkm/TDR events, no WER Event 1000 for the app, Crashpad reports dir empty.
Current workaround here: avoid the in-app Browser pane entirely (verification via external Chrome / Playwright), plus a script that kills the full package process tree instead of the Settings-Repair round-trip.
169 remaining items
Same GPU-process crash signature. Two data points I think are new to this thread:
(1) the crash reproduces on BOTH GPUs of a hybrid-graphics laptop with no difference between
them, and (2) it reproduces on demand — every relaunch + Browser pane use = new crash.Machine: HP Pavilion Gaming 15-dk1xxx · 32 GB RAM · hybrid graphics: Intel UHD 630 + NVIDIA
GeForce GTX 1650. Windows 11 25H2 build 26200.8973 — Home until 11 Aug, upgraded to Pro on
11 Aug (as an attempt to fix this); crashes continued on Pro.Claude Desktop: MSIX/Store package (Claude_*_x64__pzs8sxrjxfjjc). Crashes observed on
1.24012.9.0 (3 Aug) and 1.28929.0.0 (12–13 Aug). Current: 1.40609.1 (69aac0), installed
30 Aug — not re-tested with the Browser pane (see below).Evidence (Windows Application log, read 13 Aug):
exitCode: 101457950(= 0x060C201E,
"GPU process gone") ×4 on 12–13 Aug 2026, plus one earlier. The ×4 in one day is not random:
I kept repairing and relaunching the app to finish a work session, and it crashed again each
time the Browser pane was used. Reproducible on demand.Dual-GPU: crashes occurred on the Intel iGPU (late July – 3 Aug, driver 30.0.101.1994) and,
after I assigned Claude to the NVIDIA GPU on 3 Aug (Settings > Display > Graphics > High
performance, driver 32.0.16.1088) and left it there, on the NVIDIA GPU (12–13 Aug). No
difference in behavior between the two GPUs — frequency simply tracks Browser pane usage.Ruled out on this machine: no BSOD, no Kernel-Power 41, C:\Windows\Minidump empty with
CrashDumpEnabled=3, pagefile peak 116 MB of 10 GB, 14.6 GB RAM free at capture. Crashpad
folder empty (0 KB): the app leaves no crash dump. OS edition change (Home→Pro) had no effect.Trigger: in-app Browser pane (preview_start / navigate / get_page_text / screenshot). Dozens
of crashes late July – 13 Aug. Two documented pages: a directory results page with a WebGL map
(~58 listings, 694 KB HTML) and a Cloudflare challenge page.Since 13 Aug: Browser tools fully disabled (Chrome extension instead). Since ~30 Aug the machine
has a new Intel driver (31.0.101.2141), NVIDIA switched to Studio mode, and cleaned cooling
(CPU 90–95 °C → 47–50 °C); a WebGL benchmark in headless Chrome now runs stably on both GPUs.
NOT re-tested with the Claude Browser pane after these changes — not willing to trigger the
Repair cycle again, and #91273 shows the same crash on 1.40609.0 anyway.(Separate, to avoid confusion: this machine also had chronic Intel TDR events — LKD_0x141,
igdkmd64.sys, 12 in July — from the 2022 driver under thermal throttling. Different problem,
likely fixed by the driver/cooling changes. The 101457950 crashes are the app.)Independent confirmation of the existing diagnosis in #80444 / #80999 / #81341, with a newer Claude Desktop build and the now-released Electron fix. This is not a new root-cause claim; credit belongs to the original reporters and the Electron maintainers.
Confirmed on 2026-09-02
- Windows 11 25H2, build 26200.9168
- Claude Desktop MSIX: 1.40609.1
- Downloaded MSIX SHA-256:
D0282066855A3CAC5990912350C0DE4D01BB48CA65B8B6B4CE1EC9F2C910A6F9 - Bundled runtime identifies as Electron 42.10.0 / Chrome 148.0.7778.280
Opening the Code-tab Browser Preview produced this second-exact Windows event sequence:
15:51:17.371–15:51:17.380 CodeIntegrity Event 3010 x3: unable to load ...\AppxMetadata\CodeIntegrity.cat Status 0xC000003A 15:51:17.393 CodeIntegrity Event 3033: packaged claude.exe attempted to load app\vk_swiftshader.dll, which did not meet the Microsoft signing level requirements 15:51:17.633–15:51:17.643 AppModel-Runtime Event 6 x5: 0x3CFC / package process creation blocked 15:51:18.164 AppModel-Runtime Event 217: Claude Desktop AppX container destroyedInspection of the downloaded MSIX confirmed:
app\vk_swiftshader.dllis present- its Authenticode signature is valid and issued to Anthropic, PBC
AppxMetadata\CodeIntegrity.catis absent
This matches the established chain:
Browser Preview / WebGPU fallback → late vk_swiftshader.dll load after GPU sandbox enables MicrosoftSignedOnly → Code Integrity 3033 → AppX integrity failure / GPU exit 0x060C201E (101457950) → GPU restart attempts blocked by 0x3CFC → Chromium fatal “GPU process isn't usable” → Desktop and active Code session terminate → package requires remediationUpstream fix is available
Electron fixed this in:
- Windows MSIX/AppX: Chromium GPU process can be killed when Code Integrity rejects vk_swiftshader.dll electron/electron#52700
- fix: preload SwiftShader before the GPU sandbox locks down again electron/electron#53174
- released in Electron 42.11.0
The Electron fix restores SwiftShader preloading before the Windows GPU sandbox enables
MITIGATION_FORCE_MS_SIGNED_BINS.The currently distributed Claude Desktop MSIX 1.40609.1 still uses Electron 42.10.0, so it does not contain that fix. The official non-MSIX Claude Desktop 1.44121.0 inspected on the same date also identifies as Electron 42.10.0. The non-MSIX build avoids the AppX-fatal/remediation layer, but that is a packaging workaround rather than confirmation that the underlying runtime defect is fixed.
Requested action: upgrade Claude Desktop to Electron 42.11.0 or later, or backport the equivalent SwiftShader preload fix, then validate the signed MSIX with Browser Preview pages that call
navigator.gpu.requestAdapter({ forceFallbackAdapter: true }).Reacted by SammyDoeAnother data point, now on 1.40609.1: Claude Desktop 1.40609.1 (MSIX, Windows 11 Pro 26200), CCD 2.1.255, AMD Radeon integrated graphics (driver 32.0.31041.1004, driver date 2026-08-17, installed 2026-08-25), 32 GB RAM.
- 3 crashes in 18 h (2026-09-01 21:17:59, 2026-09-02 14:39:45 and 14:51:54), each
GPU process gone: { reason: 'crashed', exitCode: 101457950 }about 1 s after the in-app Browser pane opened a page. In all three cases the last line before the crash was[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }(same signature as [BUG] GPU process crashes app when Browser pane blocks a subresource ("PreviewContext" / private-resolving host) #91290 / [BUG] Browser pane crashes GPU process and exits the app on Windows — regression in desktop 1.40609.1 #91314). - After the crash nothing more is written to main.log (not even the per-minute
[process-memory]sampler lines) and the window is dead; recovered only by rebooting. - Regression evidence on this machine: the app auto-updated 1.40609.0 -> 1.40609.1 at 20:56 local on 2026-09-01 and the first crash came 21 minutes later. Between 2026-08-11 and 2026-08-31 the Browser pane was opened 60+ times on the same machine and the same display driver with zero GPU crashes; the only earlier
GPU process gone(exitCode 34) happened at the moment the display driver was installed on 2026-08-25 and was recovered gracefully. Theprivate-resolving hostlog message itself first appears after the update; earlier builds loggedBlocked subresource to non-public hostinstead. - Same conclusion as jasonbennett-founded in [BUG] Claude Desktop MSIX: CIG (MicrosoftSignedOnly) + vendor-signed vk_swiftshader.dll kills GPU process on every browser preview (0x060C201E) #81341: the built-in
[gpu-recovery]auto-disable never fires here, because every crash takes the app down and the counter resets on relaunch. - Separately, on 2026-09-02 10:44 Windows logged
MoAppHang/ Event 1002 for claude.exe with 8 concurrent sessions running (35-44 child processes, ~6 GB RSS, more than 13 GB RAM free); the whole process tree was killed. No GPU crash was involved, so possibly unrelated.
Mitigation on my side until this is fixed:
"permissions": { "deny": ["mcp__Claude_Browser"] }in~/.claude/settings.json, so sessions cannot open the pane at all.- 3 crashes in 18 h (2026-09-01 21:17:59, 2026-09-02 14:39:45 and 14:51:54), each
Still reproducing many versions later, and on Windows 10 — adding a scope data point rather than a new report.
Environment
- Claude Desktop 1.40609.1.0 (MSIX
Claude_1.40609.1.0_x64__pzs8sxrjxfjjc), Claude Code binary 2.1.255 - Windows 10 Pro 22H2 (10.0.19045) — every other report I found in this cluster is Windows 11, so this is not Win11-specific
- NVIDIA RTX 3070, 32 GB RAM
Independently confirms your not-driver-specific finding, across a wider gap. Reproduced identically on driver 560.94 (Aug 2024) and again on 616.56 (Aug 2026) after a Custom → Clean Installation.
exitCodeis byte-identical on both — 101457950 / 0x060C201E — so a two-year driver jump and a different GPU generation than your 2080 change nothing.Signature, five occurrences, each 0–2s after the PreviewContext warning:
2026-08-27 12:12:37 blocked -> 12:12:38 crash 2026-09-02 08:00:14 blocked -> 08:00:14 crash 2026-09-02 08:04:08 blocked -> 08:04:09 crash 2026-09-02 08:26:50 blocked -> 08:26:51 crash 2026-09-02 10:36:56 blocked -> 10:36:58 crashFive
[PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }lines in the whole log, five crashes, 1:1 with no unpaired instances either way.Supports the session-resume re-trigger in #90461. Four of the five fired shortly after
Starting app, with no user-initiated preview call:08:00:09 start -> 08:00:14 crash 5s 08:03:57 start -> 08:04:09 crash 12s 08:25:13 start -> 08:26:51 crash 1m38s 10:34:46 start -> 10:36:58 crash 2m12sThe last one is a clean example of the loop: nvidia.com was opened in the in-app Browser pane, the machine was rebooted, session restore reloaded that pane, and it crashed 2m12s after launch. NVIDIA's site runs bot detection, which matches the WebGL capability-probe mechanism in your original report.
Workaround that has held so far: driving the real browser via the Claude-in-Chrome tools instead of the in-app Browser pane. No crashes since switching. Worth noting for anyone landing here, since the MSIX packaging means there is no shortcut to attach
--disable-gpu-compositingor--disable-gputo.Three reinstalls with a reboot each also changed nothing, and
[process-memory]logged 16–17 GB free of 32 GB at every crash, so it is not memory pressure.- Claude Desktop 1.40609.1.0 (MSIX
Adding crash dumps and a stable module offset — the earlier reports here have the exit code but, as #84992 notes, "no dumps, no
Claude.exemodule offsets provided." Four dumps captured on one box today, all four identical.Environment: Windows 11 Home 10.0.26200 · Claude Desktop 1.40609.1.0 (MSIX,
Claude_pzs8sxrjxfjjc) · NVIDIA RTX 4060 · 16 GB.The assertion, read out of the dump
[FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye. gpu_last_exit_reason crashed gpu_last_exit_code_hex 0x060C201E gpu_last_exit_code 101457950 ptype browserptype=browsermatters: the browser process is not faulting on the GPU — it deliberately aborts (__debugbreak(),0x80000003) afterGpuDataManagerImplPrivategives up on repeated GPU-process failures. That is why the whole app dies rather than the GPU process being respawned.Four crashes, one instruction
#1 #2 #3 #4 exception 0x800000030x800000030x800000030x80000003Claude.exeoffset+0x6E89D89+0x6E89D89+0x6E89D89+0x6E89D89absolute address 0x7FF682F39D890x7FF7C5649D890x7FF729889D890x7FF6A40E9D89uptime at crash 13.6 min 21.6 min 52.5 min 47.3 min GPU exit code 0x060C201E0x060C201E0x060C201E0x060C201EAbsolute addresses differ (ASLR); the module-relative offset never moves. Different pids, threads, uptimes and module counts (109/105/105/100). One deterministic assertion, not a random or environmental fault. Uptime varying 13–52 min fits "abort after N GPU-process failures" rather than a timer or a leak.
Ruled out here by experiment, so others can skip them
- GPU driver.
32.0.16.1088→32.0.16.1656+ reboot. Crash OAuth error on a new project #4 came 47 min later, unchanged. Zero TDRs (Id 4101/4102) and zeronvlddmkmerrors across 14 days throughout — the display driver never faults, only Chromium's GPU process. - Stale GPU/shader caches.
GPUCache,DawnGraphiteCache,DawnWebGPUCachedeleted and rebuilt against the new driver. Unchanged. - Memory pressure. Crash OAuth error on a new project #4 fired 50 minutes after a clean reboot at 29% commit.
- Hardware specificity. Reports in this thread cover RTX 5070 and Intel Iris Xe; this is an RTX 4060. Not GPU-vendor specific.
Downstream, matching #84992
The dirty exit leaves the MSIX package
Modified, NeedsRemediation. Windows' repair then fails0x80073D02becauseCoworkVMServicestill holdscowork-svc.exeinside the package directory, and activation returns0x80073CFC— "package not found for this user", withPackageUserInformationempty whileGet-AppxPackagestill lists it.What recovers it without uninstalling (uninstall looks unsafe —
SignatureKindisDeveloper):sc.exe stop CoworkVMService # needs no elevation; skipping it fails 0x80070020 Add-AppxPackage -Path <same-version .msix> -ForceApplicationShutdown
Note
Add-AppxPackage -Register <AppxManifest.xml>and-RegisterByFamilyNameboth report success and change nothing while the service holds the directory.Possibly relevant
This box auto-updated to 1.44121.2.0 and has been crash-free for ~5.5 h since — too early to call, and posted only so it can be corroborated or contradicted by others still on 1.40609.x.
Happy to send the minidumps (~34 MB each) if there's somewhere to upload them.
- GPU driver.
Still reproducing on 1.40609.0.0, and the packaged fix is still absent in 1.44121.4.0.
I filed #80999, closed here as a duplicate on 2026-08-25. It has since reproduced three more times, on a considerably newer build than any I can find reported in this thread (the newest I see is 1.30096.x).
Environment
- Claude Desktop MSIX 1.40609.0.0 (all three crashes), now on 1.44121.4.0
- Claude Code CLI 2.1.252
- Windows 11 Pro 26200.9168
- Intel UHD + NVIDIA Quadro T2000 Max-Q (driver 32.0.15.8195)
- 64 GB RAM.
main.logprocess-memoryshows 43989 / 46746 / 39923 MB free at the three crashes, so this is not memory pressure.
Three crashes, identical chain each time
2026-09-01 02:37:21,2026-09-01 07:24:48,2026-09-03 10:16:39(local, UTC+3). Every line below shares the same second.CodeIntegrity 3010 x3 ...\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat Status 0xC000003A CodeIntegrity 3033 claude.exe -> ...\app\vk_swiftshader.dll did not meet the Microsoft signing level requirements unknown-window.log The powerPreference option is currently ignored when calling requestAdapter() on Windows main.log GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Then the app dies and every relaunch shows the Repair dialog.
The precondition is still shipping in the current build
Checked on disk today, on 1.44121.4.0:
...\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\AppxMetadata -> does not exist ...\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll -> presentSo neither of the two packaging fixes (page hashes, or a
CodeIntegrity.cat) has landed as of 1.44121.4.0.A deterministic trigger, and a negative control that matters for triage
Unlike the hidden-pane and screenshot repros above, mine is a visible pane and an explicit navigate, with no screenshot call involved:
action result Claude_Browser__navigate->https://aluma.smarticket.co.il/show/1088crash in 0.7 to 2.9 s, 3/3 https://example.comno crash, and no requestAdapter()linelocalhost dev servers 658 pane calls in another project, zero crashes the same host's plain 404 page no crash, and no requestAdapter()lineThat last row is the important one. Whether the probe fires is page-content dependent, which I suspect is behind the "intermittent" reports here. After the 1.44121.4.0 update I retested the same URL, it survived, and I nearly concluded it was fixed. It was not:
unknown-window.logshowed therequestAdapter()probe never fired that run, so the trigger was simply never exercised.A retest that survives proves nothing unless you confirm the WebGPU probe actually ran. Worth stating explicitly if anyone is verifying a candidate fix.
Second-order symptom I do not see documented here: it wedges terminal Claude Code sessions
The desktop app's death also kills in-flight CLI sessions, and the host terminal is left hung rather than exiting:
cowork-service.log: [Server] Persistent RPC: connection ended: failed to read length: EOF0.7 to 2.9 s after the tool call, matching the GPU death second for second. On the first crash the terminal stayed wedged for 4 h 45 min until Windows reaped it:
Application Hang 1002 / AppHangXProcB1 P1 = cmd.exe "Waiting on Application Name" = node.exe 24.19.0.0So the blast radius includes unsaved agent work in terminal sessions, not just the desktop window. From the user's side it presents as "Claude broke and Windows needs repairing", with no error and no WER crash report, which I expect suppresses reporting of this bug considerably.
Recovery and workaround
Recovery is Settings > Apps > Claude > Advanced options > Repair, per #80999.
taskkilldoes not clear the Modified flag.Workaround confirmed working here: drive real Chrome through the
claude-in-chromenative-messaging tools, or useWebFetch/WebSearch. No Electron renderer is created, the GPU process never falls back to SwiftShader, and the trigger is absent.Still reproducing on 1.44121.4 (latest as of 2026-09-03). Adding package-level evidence I have not seen in this thread, plus a correction: updating does not fix this, and disabling hardware acceleration does not either.
Environment
Package Claude_1.44121.4.0_x64__pzs8sxrjxfjjc(MSIX)Runtime Chrome/148.0.7778.280 Electron/42.10.0(fromapp\Claude.exestrings; FileVersion 1.44121.4)OS Windows 11 Pro for Workstations 25H2, build 26200.9278 GPU RTX 5090, driver 32.0.16.1088 Three package facts
app\vk_swiftshader.dllships in the package (5.29 MB), Authenticode signature Valid, signerCN="Anthropic, PBC".AppxMetadata\CodeIntegrity.catis absent from the package. TheAppxMetadatafolder contains no catalog at all.- The shipped Electron is 42.10.0. Upstream, the Chromium 148 GPU-process regression in this area is fixed in 42.11.0.
Point 2 is the one I would most like a maintainer to check. Without a package catalog, an Anthropic-signed DLL loaded into a process running under the MicrosoftSignedOnly / CIG mitigation has nothing to validate against. For an MSIX-packaged process the loader's integrity-failure path terminates the process rather than failing the load, which matches the observed exit code
0x060C201E(101457950) exactly — a loader termination code, not a Chromium result code.I want to be explicit about what I could not confirm locally: I never captured the corresponding CodeIntegrity 3033 event. On this machine
Microsoft-Windows-CodeIntegrity/Operationalis capped at 1 MB and had already rolled past the crash window by the time I looked. So the mechanism above is a hypothesis; the three facts are measurements.Reproduction and timing
Four crashes on 2026-09-02, all with
exitCode: 101457950, each one 10–220 s after the in-app Browser pane opened, and never without it:19:35:37 preview → GPU gone 22:25:50 preview 22:25:40 → GPU gone 22:48:36 preview 22:48:17 → GPU gone 23:33:47 preview 23:32:42, page loaded 23:33:32 → GPU goneOn the fourth, the renderer logged
WebGL: CONTEXT_LOST_WEBGL: loseContext: context lostat the same second. After every crash the main process stops logging entirely — no heartbeat, no periodic memory line — until Windows kills it.Disabling hardware acceleration does not help
Worth stating plainly, because it is the workaround most often suggested. Crash 4 happened with
isHardwareAccelerationDisabled: trueactive. The GPU process was running--use-gl=angle --use-angle=d3d11-warp-webgland renderers--disable-gpu-compositing, and it still died with the same code.app.disableHardwareAcceleration()moves rendering to WARP but does not disable WebGPU, so the SwiftShader path is still reachable.Related: the in-app auto-recovery never fires here. The gpu-recovery routine that disables hardware acceleration after 3 GPU deaths is gated off for MSIX installs, and in any case the main process hangs on the first death, so a streak of 3 in one session cannot accumulate. There are no
[gpu-recovery]lines in any of my logs.The repair loop, and what actually makes it long
Sequence from the Windows event logs, consistent across all four incidents:
- GPU process dies; package status shows Modified (
0x2). Nothing in any Windows log records the moment this bit is set. - User clicks the icon →
TWinUIactivation → within ~100 msAppXSvcstartsRegisterByPackageFullNamewithForceTargetApplicationShutdownOption, RepairAppRegistrationOption. - That register step fails
0x80073D02— "apps need to be closed" — namingClaude_pzs8sxrjxfjjc!Claude, becauseCoworkVMService/cowork-svc.exeis still alive. It retries. - Only a full
RepairPackageOperationsucceeds, and that re-downloads the entire MSIX fromdownloads.claude.ai. Measured: 2.5 to 6 minutes of download, 3 to 12 minutes end to end.
Killing
Claude.exebefore clicking the icon does not shorten this — the trigger is the status bit, not the live processes. Stoppingcowork-svc.exefirst does, because it removes the0x80073D02retry loop.Requests
- Ship
CodeIntegrity.catin the MSIX, or confirm why the package does not need one. - Bump Electron to 42.11.0 or newer.
- Make the main process survive a GPU-process death instead of hanging on it — this is what turns a recoverable crash into a package repair.
- Make
CoworkVMServicestop with the app, so the repair path is not blocked by its own service.
Happy to run any specific diagnostic and attach output — including re-arming the CodeIntegrity log with a larger size and reproducing on purpose, if that 3033 event would be useful to you.
Additional data point — Windows 10 22H2 / 1.40609.1 / RTX 3070: two crashes today, each 4–6 s after
[Preview] Created browser preview.Created browser previewfired exactly twice today and both were followed by the GPU crash (2/2); 60+ artifact html-previews in the same log were harmless.Environment
- Claude Desktop 1.40609.1 (MSIX
Claude_1.40609.1.0_x64__pzs8sxrjxfjjc,isPackaged: true, node 24.18.1) - Windows 10 Pro 22H2 (10.0.19045) — second Windows 10 report in this thread
- NVIDIA GeForce RTX 3070, driver 32.0.16.1047 (2026-05-19), 64 GB RAM
- ~18 Claude Code (CCD) sessions open; an external 1-minute watchdog samples the process tree,
Process.Respondingof the app root, andGet-AppxPackage Status
Timeline (local UTC+8), from
%LOCALAPPDATA%\Claude\Logs\main.log15:34:14 [WarmLifecycle:preview] Warming up session <A> (sidebar focus switch) 15:34:15 [Preview] Created session preview context 15:34:15 [Preview] Created browser preview { serverId: 'browser-preview-1788593655277-113' } 15:34:17 [process-memory] electron(18)=3888MB children(866)=18317MB tree_rss_sum=22205MB 15:34:19 GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' } 15:50:43 [WarmLifecycle:preview] Warming up session <B> (sidebar focus switch) 15:50:51 [Preview] Created session preview context 15:50:51 [Preview] Created browser preview { serverId: 'browser-preview-1788594651941-0' } 15:50:57 GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }Both sessions had used the in-app Browser pane earlier. The crash happens when the app re-instantiates that preview on sidebar focus, not at the moment the agent first opens it.
Package state after crash #2 (no human interaction between crash and rescue; the user only ran PowerShell)
- Watchdog: app root
Responding=Trueat 15:50:44, process gone at 15:51:43 — no hang phase. Get-AppxPackage Claude | % Statusflipped toModified, NeedsRemediationin that same minute.Microsoft-Windows-AppXDeploymentServer/Operational: zero deployment/Repair events between the previous reinstall (15:37:31) and the next (15:57:05).- Application log: zero 1000/1001/1002 — Windows recorded neither a crash nor a hang.
Microsoft-Windows-AppModel-Runtime/Adminat reinstall:state updated to 0x0 (previous state = 0x2)→ appxState=2.- File integrity: all 3,057 files listed in
AppxBlockMap.xmlpresent, zero stray files — consistent with @saymonsh's finding that the registration state, not the payload, is what gets corrupted.
Crash #1 also shows the aggravation path when Settings → Repair is clicked while package processes are still alive:
15:34:46 id=603 RepairAppRegistrationOption 15:34:46 id=638 package not updated because the app is still running {Claude_pzs8sxrjxfjjc!Claude} 15:34:46 id=419 0x80073D02 15:34:46 id=617 package status updated (Clear=0x0, Set=0x400)Recovery that works every time (~5 s): kill
WindowsApps\Claude_*processes →Add-AppxPackage <same-version .msix> -ForceApplicationShutdown -ForceUpdateFromAnyVersion→Status: Ok. Settings → Repair andAdd-AppxPackage -Registerdo not clear it.Side observations (possibly unrelated):
CoworkVMServicelogsfailed to configure SCM recovery actions … Access is deniedon every start;C:\ProgramData\Claude\Logs\cowork-service.loghas grown to 664 MB / 7.0 M lines with no rotation; the Crashpad directory holds onlysettings.dat/metadata— no minidumps for either crash.- Claude Desktop 1.40609.1 (MSIX
Follow-up to my comment above, after reading the app's own crash handling out of
app.asar(1.40609.1) — this corroborates @kai-sorensen'sptype=browserfinding from a different angle:- The app's JS
child-process-gonehandler fortype: 'GPU'only counts deaths (gpu-crash-streakmarker inuserData), and only at ≥3 deaths within 5 min does it disable hardware acceleration and offer "Restart now". There is no GPU-gone →app.exitpath in the app code. - On both of today's crashes
main.logends immediately afterGPU process gone: { … exitCode: 101457950 }— zero further lines until the nextStarting app. Thegpu-crash-streakmarker was never written (the async write did not complete), and there is not a single[gpu-recovery]line in the log.
So the sequence is: one GPU-process exit with
0x060C201E→ the browser process aborts (gpu_data_manager_impl_private.cc:418 "GPU process isn't usable. Goodbye.") before the app's JS gets a chance to react. That means the in-app GPU auto-recovery (disable HW accel after N deaths) is effectively unreachable in this failure mode — it assumes the app survives deaths #1 and #2.Both of today's GPU exits came 4–6 s after
[Preview] Created browser preview(the in-app Browser pane WebContentsView being re-created on sidebar focus). Windows 10 22H2 / RTX 3070 / 64 GB, details in my comment above.- The app's JS
Binary-level follow-up (same box as above, 1.40609.1):
Claude.exeis a stock Electron 42.10.0 build: its CodeView GUID (02AC5507-F22E-7FF6-4C4C-44205044422E, age 1, PDB nameelectron.exe.pdb) resolves onsymbols.electronjs.org. So the whole GPU-fallback path below is unmodified Chromium 148.0.7778.280.- Read from the binary (capstone +
.pdata):GpuProcessHost::RecordProcessCrashreturns early unlessrecent_crash_count >= 3(kGpuMaxCrashCount) and--disable-gpu-process-crash-limitis absent; only then does it callGpuDataManagerImpl::FallBackToNextGpuMode, which popsfallback_modes_andLOG(FATAL)s "GPU process isn't usable. Goodbye." when the vector is empty.DisableHardwareAcceleration()merely pre-pops the hardware modes (while gpu_mode_ in {GL, Metal, Vulkan}: FallBack()), which explains why turning off hardware acceleration doesn't help: the same exits drain the remaining modes. - Consequence: reaching "Goodbye" needs at least 6 GPU-process exits, yet
main.logrecords exactly oneGPU process gonebefore the process dies. The relaunch/exit loop completes inside the browser process before the app's JS handles the firstchild-process-gone, so the in-app streak marker / auto-disable never runs. 0x060C201Eis not a literal constant in any PE in the package (Claude.exe, libGLESv2, vk_swiftshader, dxcompiler, vulkan-1, the .node addons, cowork-svc.exe) nor ind3d11.dll/dxgi.dll/d3d12.dll/vulkan-1.dll/twonvwgf2umx.dllversions on this machine. It looks runtime-composed; knowing what emits it on the GPU-process side would pin the root cause.
Ruling out the obvious suspects for
0x060C201E, from the binary (1.40609.1, stock Electron 42.10.0 confirmed by PDB GUID against symbols.electronjs.org):I disassembled every call site of
base::Process::TerminateCurrentProcessImmediatelyinclaude.exeand read the exit code each one passes. There are 11, and none of them passes0x060C201E:function (resolved against the official PDB) exit code gpu::GpuWatchdogThread::DeliberatelyTerminateToRecoverFromHang2 viz::VizMainImpl::ExitProcessvariable viz::GpuLogMessageManager::TerminateProcessOnIOvariable content::ChildThreadImpl::Init/::EnsureConnected0 content::RenderThreadImpl::Shutdown0 gpu::GpuChannelMessageFilter::TerminateForTesting0 media::AudioThreadHangMonitor::TerminateCurrentProcess1 blink::HandleChromeDebugURL1 There is exactly one
KERNEL32!ExitProcesscall site (CRT teardown), and the constant0x060C201Eappears nowhere in the binary, in any DLL shipped in the package, or ind3d11.dll/dxgi.dll/d3d12.dll/vulkan-1.dll/ twonvwgf2umx.dllversions on this machine.Two consequences:
- The GPU watchdog is not the cause. If a hang had tripped
DeliberatelyTerminateToRecoverFromHang, the GPU process would exit with 2, not0x060C201E. So this is not "GPU hung, watchdog killed it". - The value is not a Chromium-chosen exit code at all. On Windows an unhandled exception becomes the process exit code, so
0x060C201Eis most likely an exception code (its bit pattern is not a standard NTSTATUS — severity bits are 00 — which points at a third-party/custom raise), or the process was terminated by something outside Chromium.
Either way this needs a GPU-process minidump, not a browser-process one. The browser-process dumps posted earlier (
ptype=browser,base::ImmediateCrashat theIntentionallyCrashBrowserForUnusableGpuProcesspath) only show the downstream deliberate abort.For completeness, the browser-side chain resolved against the PDB is:
GpuProcessHost::RecordProcessCrash→IncrementCrashCount→ (>= 3 crashes) →GpuDataManagerImpl::FallBackToNextGpuModeDueToCrash→GpuDataManagerImplPrivate::FallBackToNextGpuMode→ whenfallback_modes_is empty →IntentionallyCrashBrowserForUnusableGpuProcess→logging::LogMessage::HandleFatal→base::ImmediateCrash.- The GPU watchdog is not the cause. If a hang had tripped
Negative data point on 1.52386.3.0: did not reproduce in one short run. Same machine where I reported six crashes with
exitCode 101457950in #81840 (2026-08-16, app 1.30096.5).Environment
- Claude Desktop MSIX
Claude_1.52386.3.0_x64__pzs8sxrjxfjjc, Claude Code engine 2.1.266 - Windows 11 Pro 25H2, build 26200.9445
- NVIDIA GeForce RTX 4090, driver 32.0.16.1088 (2026-07-22), single adapter
What I did (2026-09-13, local time)
- In the in-app Browser pane opened
https://nowsecure.nl(Cloudflare Turnstile widget on an animated 3D card, visible in the pane), thenhttps://itch.ioin a second tab. itch.io's Cloudflare interstitial is what @Eltacolibre used for deliberate reproduction in In-app Browser pane crashes Desktop app's GPU process (exitCode 101457950), even with hardware acceleration disabled #81840. - The app's network service had established TCP connections to the Cloudflare addresses of both hosts (created 01:05:49 and 01:07:40).
- Borrowing @Eltacolibre's approach from In-app Browser pane crashes Desktop app's GPU process (exitCode 101457950), even with hardware acceleration disabled #81840: an external
pwshwatcher held open handles to the mainclaude.exeand the--type=gpu-processchild and polled once per second for exit codes, from 01:05:55 until I stopped it at about 01:08:10.
Result
- The main process and the GPU process kept the same PIDs they had at app start (00:54:39 / 00:54:41) — checked at the end of the run and again at 01:11, so neither was restarted during the test.
- The watcher logged no exit events.
Caveats
- A single short run. The watcher started ~6 s after the first connection to nowsecure.nl, so the no-restart conclusion rests on the unchanged PIDs rather than on the watcher alone.
- Crashes were intermittent for some reporters, so this is a negative data point, not proof of a fix.
- No crash dumps in
%APPDATA%\Claude\Crashpad, but that is weak evidence: it stayed empty during real crashes in In-app Browser pane crashes Desktop app's GPU process (exitCode 101457950), even with hardware acceleration disabled #81840 too. %APPDATA%\Claude\logs\main.loghas not been written since 2026-08-21 on this machine, so I could not check for theBlocked subresource to private-resolving hostprecursor.
- Claude Desktop MSIX
any hints about fixed release version?
I noticed that this issue has been closed, but I could not find a clear explanation for the closure.
Given that this problem has been reported and reproduced by multiple users, it would be very helpful if the Claude team could clarify why the issue was closed.
In particular:
- Was the underlying problem fixed?
- If so, in which Claude Desktop version was the fix released?
- If it was not fixed, was the issue superseded by another issue or tracking mechanism?
- Is there an official workaround for users who still encounter the MSIX /
CoworkVMService/Modified, NeedsRemediationbehavior?
My own issue was closed as a duplicate and ultimately pointed to this issue as the canonical report, so the closure of this issue without an explanation leaves it unclear whether the underlying problem is considered resolved.
A short maintainer note explaining the closure status would be greatly appreciated, especially for users who are still trying to determine whether it is safe to return to the MSIX/Cowork installation.
Reacted by GusOEther
Environment
Claude_pzs8sxrjxfjjc,build_type: windows-store), Electron 42.7.0 / Chrome 148.0.7778.280 / Node 24.18.0Bug 1 — fatal GPU-process crash kills the whole app
Four identical fatal crashes (local time UTC+2): 2026-07-22 21:08:47 and 21:22:21, 2026-07-23 04:20:40 and 07:03:56 (= 19:08:47Z, 19:22:21Z, 02:20:40Z, 05:03:56Z).
Signature, every time, in
%APPDATA%\Claude\logs\unknown-window.log— a page loaded in the in-app Browser preview tab runs a WebGL/WebGPU capability-probe suite (looks like standard bot-detection/fingerprinting code; several probed sites use it):then immediately in
main.log:…and the entire app dies instantly with the GPU process (main.log stops mid-write, no shutdown path, window-state.json never re-saved). Exit code is 101457950 = 0x060C201E in all four crashes.
Repro chain observed 4/4 times: a Claude Code session opens an in-app Browser preview tab (
[PreviewContext] Opened preview user tab/[Preview] Created browser previewin main.log) → 15–36 seconds later the loaded page runs the WebGL probe burst → GPU process dies → app dies. Notably, a GPU-process crash with a different exit code (34, during a driver install) was recovered gracefully — the GPU process just relaunched. Only the 0x060C201E path takes the app down.One of the four crashes happened fully unattended at 04:20 (an overnight workflow re-opened its Browser tab), so this also kills long-running/autonomous sessions.
Minidumps: Crashpad wrote dumps for all four crashes and the Sentry integration uploaded them at the subsequent app startups (local Crashpad db swept clean each time). Crashpad
client_id: c022cf05-35e3-4f4e-9b4a-c4c68f176905, Sentrydid: e6db0749-fa5b-4a66-900d-313bdbe10bd4— the four events should be findable under those IDs around the UTC timestamps above. One captured Sentry event id from the 2026-07-22 19:14:57Z restart:1a18be03af2243a38b279cd0adca2e8d.Bug 2 — every fatal crash leaves the package unlaunchable until manual Repair
This is arguably the worse bug for ordinary users. After every fatal crash, Windows flags the MSIX package Modified (
appxState=2) and refuses to activate the app — launch attempts die before any app code runs (zero log lines). The OS then loops into Microsoft Store remediation, which cannot service the Developer-signed non-Store package (AppXDeploymentServer errors 8107 "invalid integrity check for a non-AppStore package" and 8104 / 0x80070057), and logsTrying to repair ACLs for C:\Program Files\WindowsApps\Claude_… → ACLs repaired successfullyover and over (15+ times observed).The only reliable fix is Settings → Apps → Claude → Advanced options → Repair, which re-downloads the full .msix from downloads.claude.ai and re-registers it — needed after every single crash. Two aggravating factors observed in the AppX/AppModel event logs:
cowork-svc.exe) survives the app crash and holds a file lock, so the automatic repair fails with 0x80070020 (sharing violation creatingapp\resources\cowork-svc.exe) until a ForceTargetApplicationShutdown register kills it (cost: ~3 extra minutes of outage).Windows Error Reporting captures none of this (no Event 1000/1001 — Crashpad intercepts the fault), so from the OS's perspective the app just refuses to start with no diagnosable error. A non-technical user would plausibly conclude the app is broken and reinstall.
Ruled out during diagnosis
[process-memory]telemetry); no Resource-Exhaustion-Detector events; pagefile peak 219 MBWorkarounds found (for other users hitting this)
cowork-svc.exefirst to speed it up)Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude -Command 'app\Claude.exe' -Args '--disable-gpu'🤖 Diagnosed and drafted with Claude Code (forensics: app logs, Crashpad/Sentry state, WER + AppXDeployment/AppModel event logs)