[BUG] Windows MSIX: inline browser preview crashes GPU process, leaves package Modified/NeedsRemediation

I can confirm the same bug on another Windows machine.

Environment:

• Windows build: 10.0.26200.8973
• Claude Desktop MSIX: 1.24012.9.0
• Claude Code: 2.1.219
• Electron: 42.7.0
• Chromium: 148.0.7778.280
• GPU: NVIDIA GeForce RTX 5070 Ti
• NVIDIA driver: 32.0.16.1062 (2026-06-11)

Reproduction:

1. Open a Claude Code/Cowork session.
2. Use the inline browser preview to open OpenRouter.
3. Attempt to proceed to the OpenRouter login page.
4. Claude Desktop crashes and becomes unlaunchable.

This reproduced twice:

• 2026-07-29 22:04:33 JST
• 2026-07-29 22:20:26 JST

main.log:
capturePreviewScreenshotIfChanged failed:
Error: UnknownVizError

GPU process gone:
type: GPU
reason: crashed
exitCode: 101457950
serviceName: GPU

unknown-window.log shows the same sequence immediately before both crashes:

• repeated WebGL INVALID_ENUM errors
• “A valid external Instance reference no longer exists”
• CONTEXT_LOST_WEBGL

After each crash, Windows AppModel Runtime reported 0x3CFC and Claude could not launch. Repair and reboot did not restore it; reinstalling the same MSIX over the existing installation was required.

There were no Windows display-driver reset events or system-wide GPU failures. Memory pressure was also not present.

This appears to be the same inline-preview GPU crash and MSIX self-bricking behavior described in this issue, now reproduced with an RTX 5070 Ti and an OpenRouter login page.

Same crash here on Windows 11 Pro (26200), Claude 1.25927.0, sideloaded MSIX. I think I have the full causal chain — the GPU crash is a symptom, not the cause. Eight crashes over two days, all with a byte-identical fingerprint across three separate Windows event logs.

The chain

1. Chromium's GPU process hits a lost context and falls back to software rendering, which lazy-loads app\vk_swiftshader.dll.
2. Code Integrity tries to validate it against the package catalog and fails, because AppxMetadata\CodeIntegrity.cat does not exist in the package:

``
CodeIntegrity/Operational Id=3010 (×3)
Code Integrity was unable to load the ...\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A
`
(0xC000003A = STATUS_OBJECT_PATH_NOT_FOUND` — the file is genuinely absent.)

1. With no catalog, the lazily-loaded DLL can't meet the signing level the GPU process requires:

``
CodeIntegrity/Operational Id=3033
Code Integrity determined that a process (...\app\claude.exe) attempted to load
...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
``

1. The GPU process dies. The app logs the familiar line:

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

1. Every subsequent child-process spawn is refused, and the container is torn down — this is what kills the whole app:

``
AppModel-Runtime/Admin Id=6 (×5)
0x3CFC: Cannot create the process for package <NULL> because an error was encountered
while checking the machine-level package status.
AppModel-Runtime/Admin Id=217
Destroyed Desktop AppX container {...} for package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
`
(0x3CFC = ERROR_NEEDS_REMEDIATION`.) The whole sequence spans ~1.5 seconds.

Notes that may save others time

• vk_swiftshader.dll is not unsigned. Get-AuthenticodeSignature reports Valid, signer Anthropic, same as libGLESv2.dll / ffmpeg.dll / vulkan-1.dll. It fails the Microsoft signing level specifically, which the package catalog is what normally satisfies. d3dcompiler_47.dll (Microsoft-signed) is the only DLL in the folder that would pass on its own.
• 16–18 of the 3010 catalog errors fire harmlessly at every single app start — those DLLs load before the mitigation applies. Only the lazy SwiftShader load is fatal. So the presence of 3010 alone isn't the bug; the 3033 is.
• It is not a GPU or driver problem. Intel Iris Xe 32.0.101.7084 → 7088 changed nothing. Pinning the app to the discrete RTX 4050 via UserGpuPreferences changed nothing. And an ordinary GPU crash (exitCode 34) is absorbed and recovered from normally — only the 101457950 variant is fatal, because that one is container teardown rather than a process fault.
• The browser preview is not required. It reproduces fastest that way (~2–20 s after opening preview tabs, matching this report), but my most recent crash happened with the app fully idle and no preview open — sessions had been paused for idle timeout six minutes earlier. WarmLifecycle:preview is armed when-hidden, so a background preview warm appears to be enough.
• No crash dump will ever appear. WER LocalDumps for Claude.exe produces nothing and %APPDATA%\Claude\Crashpad\reports stays empty, because the process is terminated rather than faulting. Anyone chasing a dump is chasing a dead end.
• Package state here is Status: Ok, SignatureKind: Developer, IsDevelopmentMode: False. Re-registering the package (Add-AppxPackage -Register -DisableDevelopmentMode) does not help — it comes back within the hour.

Verify in one command

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'; Id=3033} |
  Where-Object Message -match 'swiftshader' | Select-Object TimeCreated, Message -First 5

Cross-reference the timestamps against Id=6 in Microsoft-Windows-AppModel-Runtime/Admin and against GPU process gone in %APPDATA%\Claude\logs\main.log. On my machine those three line up to the second, eight times out of eight.

Suggested fix

Ship a Microsoft-countersigned AppxMetadata\CodeIntegrity.cat in the MSIX (standard for packages whose binaries are lazily loaded under a signing-level mitigation). Failing that, either preload vk_swiftshader.dll at startup alongside the other GL DLLs so it's validated on the normal path, or build with the software rasterizer disabled so the fallback is never attempted.

Happy to supply full .evtx exports or the app log bundle if useful.

@sanderwollaert, your chain checks out on the machine from this report (Win10 / RTX 3060 Ti, so a different OS and GPU than yours). All three of my 07-25 crashes came right after the in-app browser/preview pane was opened (twice by a background agent session, once by the main session).

Your verify command matches here to the second:

• CodeIntegrity/Operational Id=3033 for vk_swiftshader.dll at 2026-07-25 13:12:02, and again at 14:05:13 (that one was the first pane-open right after reinstalling the app).
• main.log (rescued from the pre-reinstall profile) ends in the same second with the familiar line: GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
• Renderer side, same second (unknown-window.log): a burst of WebGL: INVALID_ENUM: getInternalformatParameter warnings, the requestAdapter() powerPreference warning, then A valid external Instance reference no longer exists. That is consistent with step 1 of your chain (context loss, then software-rendering fallback) as seen from inside the app.

One data point that differs from your notes: a Crashpad dump can appear, just not reliably. %APPDATA%\Claude\Crashpad\reports\ here contains a 35 MB minidump written at exactly 13:12:02, the same second as the 3033 event. It appeared on only one of the three crashes; the other two left no dump, no WER report, and no Application event log entry, matching your observations. So at least one process in the chain sometimes faults before the container teardown. Not attaching it, since minidumps carry process memory, but we kept it.

Workaround that has held up here: since 07-25 we stopped touching the browser/preview feature entirely, no preview tabs, and the browser tools are explicitly banned in every subagent prompt (two of the three crashes were triggered by background agents opening the pane). Zero crashes since, with heavy daily use otherwise. Given your idle crash via the WarmLifecycle:preview warm this may not be complete protection, but on this machine strict avoidance has been enough so far.

Edit: counted it for the record: since the 07-25 reinstall this machine has logged 414 [WarmLifecycle:preview] warm-ups in 13 days with zero crashes, so on a desktop with a stable discrete GPU the when-hidden warm alone doesn't appear to be enough; it seems to also need the context loss that forces the SwiftShader fallback. Pre-reinstall numbers back this up: the broken build logged 2,424 preview warm-ups over the preceding three weeks, also without an idle crash, and none of our three crashes has a warm-up in the crash second (nearest was ~35 s earlier, firing routinely right after an app relaunch). Every crash here lines up with the pane actually being opened.

One more artifact: the CLI-side MCP log of the fatal session pins the trigger-to-death window at 3 seconds. preview_start was called at 13:11:58 and returned "completed successfully in 912ms" at 13:11:59; the 3033 event, the GPU process gone line, and the minidump all follow at 13:12:02. So the pane reports success before the SwiftShader fallback kills the container.