Windows MSIX: WebGPU requestAdapter() → Code Integrity blocks vk_swiftshader.dll → GPU process crash kills the whole app and wedges the package

Same signature as #81341, which has a longer evidence thread on it — CIG measured via Get-ProcessMitigation, a Chrome control group, and commit archaeology by @vkwislacode in that thread dating the regression to the March 2026 narrowing of Chromium's vk_swiftshader.dll preload. Cross-linking because this issue currently references none of that cluster, which now runs to roughly twenty reports.

Your Turnstile observation looks like a trigger detail that thread is missing. Several reports there describe the same URL crashing on some visits and loading fine on others with no explanation offered, and WebGPU being called only on some Turnstile challenges would account for it.

One datapoint to add: on Windows 11 26200 the preconditions are unchanged on 1.24012.11.0 — no .cat anywhere under the install root, vk_swiftshader.dll still shipped with a third-party Authenticode signature, GPU child still MicrosoftSignedOnly: ON / AllowStoreSignedBinaries: OFF, app\version still 42.7.0. Read-only checks only; I have not run a trigger test on that version. Details in #81341.

Thanks — the cross-link is right, and #81341 is clearly the better-instrumented thread. I'm folding my report into that cluster rather than maintaining a parallel account. Below is what I have that the thread doesn't already, kept separate by how well I can actually support it. (Assistant-assisted analysis; local paths and identifiers redacted.)

1. The Turnstile trigger — a hypothesis, and exactly how far my evidence goes

Since this is the part you flagged as missing, I want to be precise about it rather than let it get adopted as a finding.

What I observed. The page loaded in the Browser pane was a login page on a site I operate, fronted by Cloudflare Turnstile. unknown-window.log records requestAdapter on that page, and the CodeIntegrity 3010/3033 pair plus the GPU death follow within the same second.

What I did not do. I never instrumented the widget, never A/B'd the page with Turnstile removed, and never captured a challenge-versus-no-challenge comparison. So: requestAdapter() on a Turnstile-fronted page, not "Turnstile called requestAdapter()."

Why I still think it's worth having. Turnstile's fingerprinting is adaptive — it does not run the same probe set on every visit — which would produce exactly the pattern several reports here describe and none explain: the same URL crashing on some visits and loading fine on others. It is a plausible mechanism that fits the observation, and it is testable by someone with the appetite for a trigger run. It is not established.

Given that this thread has just watched one workaround withdrawn for a verification method that distinguished nothing, I would rather this go in labelled.

2. Two fires, eight days apart, on two different app versions

Both on the same machine (Windows 11 Pro 26200), with the CodeIntegrity correlation captured for each:

| | 2026-07-24 | 2026-08-01 |
|---|---|---|
| app version | 1.24012.1.0 | 1.24012.9.0 |
| requestAdapter() | 12:50:32 | 08:24:56 |
| CI 3010 ×3 (catalog, 0xC000003A) | 12:50:32 | 08:24:57 |
| CI 3033 (vk_swiftshader.dll) | 12:50:32 | 08:24:57 |
| GPU process gone, exitCode: 101457950 | 12:50:33 | 08:24:57 |
| app back (Starting app) | 13:05:40 | 08:31:36 |
| outage | 15 min 07 s | 6 min 39 s |

Identical exitCode: 101457950 both times, matching every other report here.

The version spread is the point: the 07-24 fire predates 1.24012.9.0 entirely, so whatever changed between those two releases changed nothing that matters. That's consistent with @DrRIH's app\version 42.7.0 table across 9.0 → 11.0, and with @vkwislacode dating the regression to March 2026 — it just extends the unchanged window backwards as well as forwards.

Three further incidents occurred on a second machine the night of 2026-07-31, same user-visible signature (pane opens, entire app vanishes, relaunch blocked). I did not capture CodeIntegrity data for those, so I'm listing them as occurrences only.

3. Base rate for Event 3033 on this machine

CodeIntegrity/Operational reaches back to 2025-03-31 on the affected machine. Event 3033 has fired exactly twice in that whole span — and both are the two crashes above.

That's a different cut from the Chrome control groups already posted (562/2, 275/2, and @relanderolli's Discord/Overwolf counts). Those show the block is routine and survivable elsewhere. This shows that on a machine where the event is otherwise nonexistent, both occurrences were fatal and both were this DLL. Zero background noise to subtract.

4. The failure is invisible in an agent transcript — worth knowing if you triage from one

This has cost me time twice and I haven't seen it mentioned, so: when the crash happens during an agent session, there is no failed tool call and no dangling call.

On 08-01 the sequence was preview_start → succeeded (navOk: true); read_page → succeeded, returning the full accessibility tree at 13:24:55.593Z; and the transcript then simply stops. The GPU process died one second after a tool returned successfully. Nothing is truncated mid-call, nothing errors, and it reads exactly like a session that ended normally.

Everything you'd normally reach for is also absent: no Application Error 1000, no bugcheck, no Kernel-Power 41, no GPU TDR (4101/141), no Resource-Exhaustion event, and %APPDATA%\Claude\Crashpad\reports is empty — zero dumps. Nothing faults at the OS level, because nothing faults; the loader terminates the process deliberately.

The definitive check needs no reboot to have occurred — the gap between these two lines is the outage:

grep -n "GPU process gone\|Starting app" "$APPDATA/Claude/logs/main.log" | tail

One trap: %APPDATA%\Claude\logs\ is the real log directory and sorts last in a directory listing, so it's easy to miss. %LOCALAPPDATA%\Claude\Logs is a decoy holding only chrome-native-host.log. I looked in the wrong place on my first pass.

5. Corroborating the 0x80073D02 recovery finding, from the other direction

@DrRIH's point in the "recovery may not need a full reinstall" comment matches my experience, and explains something I had recorded as a contradiction.

On 08-01 a Repair appeared to do nothing — the app still refused to launch afterwards, and the log shows that attempt succeeding at nothing more than re-ACLing the existing install ("ACLs repaired successfully… Register next time should succeed"). What actually recovered it was a second Repair, minutes later, that re-downloaded and re-added the MSIX; the app launched immediately after. On 07-31 I reached for a full Windows restart, which also worked but was almost certainly unnecessary.

So "Repair does nothing" and "Repair fixed it" are both true, and the discriminator is whether the Register step can actually run. That fits 0x80073D02 — "the following apps need to be closed" — precisely: a tray instance is enough to fail it, and the UI reports that as a flat "cannot repair this app". Fully exiting including the tray before repairing (or, per @DrRIH, before simply relaunching) is worth trying before anyone reaches for Remove-AppxPackage.

6. What I have not done

To keep the ledger clean: I have run no trigger test since 08-01, and I have not tested either workaround in this thread — neither the non-MSIX --exe build nor the --use-angle=d3d11 --disable-features=… flag set. The Browser pane is administratively disabled in my agent setup, and the work it was doing turned out to be better done with server-side curl assertions anyway.

Read-only preconditions on my machine today (Windows 11 Pro 26200, 1.24012.9.0, package Status: Ok, flagless launch) are unchanged and match the thread exactly: zero .cat files anywhere under the install root; app\vk_swiftshader.dll present with Status: Valid, CN="Anthropic, PBC"; GPU child MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF.

Happy to run a controlled trigger test with the flag set applied if that data would be useful to anyone — but I'd rather not burn a package on it speculatively.

Confirming this on a third machine, and adding two things the issue doesn't cover yet: a reliable trigger and a session-level consequence.

Environment

• Claude Desktop 1.26832.0.0 and 1.25927.0.0 (MSIX) — both newer than the versions listed in the report, so this is not fixed as of 1.26832
• Claude Code 2.1.219 / 2.1.222
• Windows 11 Pro 26200, x64
• Intel UHD Graphics 620 (integrated only), driver 31.0.101.2130 (2024-08-13)

Reliable trigger

The crash is not random. In %APPDATA%\Claude\logs\main.log there are exactly four GPU crashes across the whole log history, and every one of them lands within 30 seconds of the Browser pane loading the same Cloudflare-protected site:

| Browser-pane action (local time) | GPU crash |
|---|---|
| 2026-08-05 09:29:17 navigate → forum | 09:29:25 |
| 2026-08-05 10:42:24 get_page_text on forum | 10:42:39 |
| 2026-08-05 12:31:22 preview_start → forum | 12:31:29 |
| 2026-08-07 11:14:55 preview_start → forum | 11:15:08 |

In the same sessions the pane loaded three other sites (a SPA pricing page, a marketing site, a second pricing page) with no crash at all. The discriminator appears to be the Cloudflare interstitial, which fingerprints via WebGPU — matching the requestAdapter() path in this issue.

Immediately before each crash, main.log shows a burst of WebGL errors ending in:

[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
[warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

101457950 = 0x060C201E, same as reported here.

Code Integrity events, same second

Microsoft-Windows-CodeIntegrity/Operational at 2026-08-07 11:15:08 (and identically at 2026-08-05 12:31:29):

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

3010 Warning Code Integrity was unable to load
             ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
             catalog. Status 0xC000003A.       (x3)

Confirming the packaging side: vk_swiftshader.dll (5,546,320 bytes) is present in the installed package, but the AppxMetadata directory it should be vouched for by is not there at all. So the package ships a DLL it cannot authorize.

Recovery that actually worked

Reinstall was not needed here. The AppX Deployment log explains why plain Repair sometimes appears to fail:

404/419 Error  error 0x80073D02: Unable to install because the following apps
               need to be closed Claude_1.26832.0.0_x64__pzs8sxrjxfjjc.
638   Info     Packages were not updated because affected apps are still running.
               Running apps: {Claude_pzs8sxrjxfjjc!Claude}
649   Info     Trying to repair ACLs for ...\WindowsApps\Claude_...
649   Info     ACLs repaired successfully. Register next time should succeed.

Orphaned claude.exe child processes survive the crash and block re-registration. Get-Process claude | Stop-Process -Force before Repair (or before simply relaunching) is enough; a reboot works only because it kills the same orphans.

Session-level consequence — the part that hurts most

Beyond the app dying, the affected agent session becomes permanently unusable, because the crash is deterministic on resume:

1. Session crashes mid-task while reading a page in the Browser pane.
2. User relaunches and sends "continue".
3. The model, resuming the same task, calls get_page_text → gets No preview is open → calls preview_start on the same URL → crash.
4. Repeat.

Three separate resume attempts here, three identical crashes, across two app versions and a Repair in between. The session transcript ends each time on an unanswered mcp__Claude_Browser__get_page_text. The only escape is to abandon the session and hand the work over to a new one — losing whatever the model had gathered in context but not yet written to disk.

Two mitigations that would each be sufficient from a user's point of view:

• Ship / fix the AppxMetadata\CodeIntegrity.cat catalog so vk_swiftshader.dll can load (the actual fix)
• Failing that, keep a GPU-process crash from taking down the host window, so a bad page costs a pane rather than the app and the session

A settings toggle for GPU compositing would also help, but per #83028 the --disable-gpu-compositing flag is not reachable in the MSIX build, so it cannot be a user-side workaround today.