Windows: Browser pane GPU-process crash on Cloudflare Turnstile page kills entire app; session resume re-triggers it (crash loop) #90461

Activity

1. github-actions

   added

   duplicateThis issue or pull request already existsThis issue or pull request already exists

   platform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows

   area:desktop

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   on Aug 28, 2026
2. veysiemrah commented on Aug 30, 2026

   

   veysiemrah

   on Aug 30, 2026

   More actions

   Reproduced on a third GPU vendor and a much newer app build — byte-identical exitCode 101457950 / 0x060C201E, same Turnstile trigger.

   Environment

   • App: Claude desktop for Windows, MSIX (Claude_pzs8sxrjxfjjc), 1.40609.0.0 — notably newer than the 1.37937.x in the original report, so this is still live.
   • CCD: 2.1.247, Node 24.18.1
   • OS: Windows 11 Pro 10.0.26200
   • GPU: hybrid NVIDIA GeForce RTX 5070 Laptop (Blackwell), driver 32.0.16.1074 + Intel UHD (RaptorLake-S). Adds a third vendor to the AMD 890M here and the NVIDIA/Intel adapters in [BUG] Desktop (Windows): GPU process crashes with identical exitCode 101457950 (0x060C201E) on both NVIDIA and Intel adapters #83835 — same exit code across all of them, which lines up with [BUG] Windows Desktop destroys its own crash evidence — and the first GPU-process dump shows D3D12Core raising a non-continuable fail-fast (0x060C201E) #89525's finding that the fault is a D3D12Core non-continuable fail-fast rather than anything vendor-specific.

   Trigger

   Identical: the in-app Browser pane loading a site fronted by a Cloudflare Turnstile challenge. In my case it was a site I develop locally being previewed from a Claude Code session — worth noting because "preview the app I'm building" is the pane's primary use case, and any dev site behind Turnstile hits this every time.

   Two crashes, ~24 minutes apart, same signature both times:

   23:37:45 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
   23:37:47 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
   

   unknown-window.log shows the same probe burst 1–4 s ahead of each death:

   [warn] postMessage ... target origin ('https://challenges.cloudflare.com') does not match recipient window's origin
   [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
   [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. (x2)
   [error] %c%d font-size:0;color:transparent NaN
   [warn] A valid external Instance reference no longer exists.
   [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
   

   #	Timestamp (UTC+3)	App version	exitCode
   1	2026-08-30 23:37:47	1.40609.0.0	101457950
   2	2026-08-31 00:01:44	1.40609.0.0	101457950

   Three things that differ from the original report

   1. The app hung rather than exiting — and the OS did capture it.

   The report notes no WER event and an empty Crashpad dir. Here it is the opposite, which may give you artifacts to work with:

   • Crashpad\reports produced a 36 MB minidump per crash: 71955beb-0e67-4240-9106-82038640a6e5.dmp (23:37:47) and 529eaaf8-2d6a-496f-a2ad-a4912741831d.dmp (00:01:44).
   • Sentry caught the first one immediately after the GPU death: event id 6b9e3748d45345cdb7451187f4c5e097.
   • Windows logged Event 1002 Application Hang and WER Event 1001 MoAppHang (P1: Claude_1.40609.0.0_x64__pzs8sxrjxfjjc, P2: praid:Claude) — but 51 seconds after the GPU process died. So the main process did not exit with the GPU child; it wedged and the OS terminated it. That delay is a window in which containment (restart the GPU process, degrade the pane) would still have been possible.

   2. The MSIX wedge has a concrete file-level cause here.

   The 51-second hang is what breaks the package. Windows started its automatic repair at 23:41:38 while the packaged service was still alive, and the AppXDeploymentServer log shows exactly how it failed:

   error 0x80073D02: Unable to install because the following apps need to be closed Claude_1.40609.0.0_x64__pzs8sxrjxfjjc
   Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}
   Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude
   Failed to set the Trust Label on package ... Error: 0x80070057
   Illegal non-AppStore or non-AppInstaller package integrity validation attempted ... Flags: 0x0
   

   The aborted repair left app\resources\cowork-svc.exe half-written (its mtime is the exact minute of the failed repair), so the package sits permanently at Status: Modified, NeedsRemediation and every launch dies before writing a single log line.

   3. Add-AppxPackage -Register does not clear it.

   Worth recording as a dead end, since it is the obvious thing to try before Repair: re-registering the manifest in place returns success but leaves Status: Modified, NeedsRemediation unchanged and the app still unlaunchable. Verified with no leftover processes at all — CoworkVMService stopped with ProcessId: 0, no orphaned cowork-svc.exe, no phantom packaged claude.exe (the only claude.exe running was the standalone CLI at ~\.local\bin, which as others noted survives the GUI death unharmed). So the file-integrity damage is real, not just a stale lock, and Repair's re-download is genuinely required.

   Each launch attempt also retriggers OS remediation, which terminates the app mid-start — that is what "nothing happens when I click the icon" looks like from the user side.

   Happy to share the minidumps or fuller log excerpts if useful.

   👍React with 👍1Reacted by Craig Stoller
3. codebytere-ant

   closed this as completedon Sep 15, 2026