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 lost
then 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.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 preview in 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, 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 logs Trying to repair ACLs for C:\Program Files\WindowsApps\Claude_… → ACLs repaired successfully over 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:
- The packaged CoworkVMService (
cowork-svc.exe) survives the app crash and holds a file lock, so the automatic repair fails with 0x80070020 (sharing violation creating app\resources\cowork-svc.exe) until a ForceTargetApplicationShutdown register kills it (cost: ~3 extra minutes of outage).
- Repair's Register step reports 0x80073D02 ERROR_PACKAGES_IN_USE when 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-AppxPackage Status "Ok" between episodes
Workarounds found (for other users hitting this)
- After a crash: Settings → Apps → Claude → Advanced options → Repair (kill leftover Claude processes incl.
cowork-svc.exe first 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 (forensics: app logs, Crashpad/Sentry state, WER + AppXDeployment/AppModel event logs)
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)