Windows MSIX: GPU process crash (UnknownVizError, exit 101457950) in embedded browser preview, package left Modified/NeedsRemediation; CodeIntegrity 3033 on vk_swiftshader.dll and package ships without AppxMetadata\CodeIntegrity.cat

Summary

Claude Desktop (MSIX, Claude_pzs8sxrjxfjjc) has twice in 12 hours suffered a fatal GPU-process crash while the Claude Code embedded browser preview displayed a Clerk sign-in page (dashboard.clerk.com), each time followed by the package entering Modified, NeedsRemediation and refusing to relaunch until a Windows Settings Repair. The failure signature matches public issues anthropics/claude-code #82967, #68049, #84333 and the cross-vendor Electron parallel openai/codex #34133.

Environment

• Claude Desktop 1.30096.5.0 (previous incident on 1.30096.1.0), package family Claude_pzs8sxrjxfjjc, SignatureKind Developer, CCD runtime 2.1.229
• Windows 11 Enterprise 10.0.26200, Intel Core Ultra 9 275HX, NVIDIA RTX PRO 4000 Blackwell Laptop GPU (driver 32.0.15.9658, May 2026) + Intel iGPU (hybrid graphics), 64 GB RAM
• Smart App Control: OFF (VerifiedAndReputablePolicyState = 0). No WDAC user policy known.

Incident timeline (all times local, 15 Aug 2026)

| Time | Event |
|---|---|
| 00:00:04 | main1.log: [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } (preview showing dashboard.clerk.com) |
| 00:00:07 | GPU process gone: { reason: 'crashed', exitCode: 101457950 } + capturePreviewScreenshotIfChanged failed: UnknownVizError (v1.30096.1.0) |
| 00:03–00:04 | AppModel-Runtime Id 68: package status flaps 0x2 ↔ 0x80002, then 0x200000 (NeedsRemediation) at 00:04:31 |
| 00:46–00:52 | Relaunch attempts; two further GPU crashes (exitCode −1) |
| 08:44 | Update/re-registration to 1.30096.5.0 completes (old package removed via 0x280000→0x200000→0x0) |
| 08:46, 08:55 | Launch failures: AppModel Id 215/208, 0x80070020 "error converting the job" (sharing violation; CoworkVMService running) |
| 09:31–09:38 | System-initiated reboot; Lenovo Firmware Driver Update 1.33.0.0 installs 09:38:49; WHEA corrected PCIe warnings cluster at boot (09:38:43-44) |
| 09:59:19 | Claude package status flap 0x2 ↔ 0x80002 begins again (pre-crash) |
| 09:59:56 | Unrelated app, same block: CodeIntegrity 3033 ×3 — comet.exe (Perplexity Comet, non-MSIX) blocked loading its own vulkan-1.dll and vk_swiftshader.dll ("did not meet the Microsoft signing level requirements") |
| 11:20:27 | main.log: [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'script' } (preview on dashboard.clerk.com sign-in) |
| 11:20:30 | CodeIntegrity 3033: claude.exe blocked loading packaged app\vk_swiftshader.dll; CodeIntegrity 3010 ×3: unable to load AppxMetadata\CodeIntegrity.cat, status 0xC000003A; GPU process gone: { reason: 'crashed', exitCode: 101457950 }; AppModel Event 6 launch failures follow |
| 11:55–11:57 | Windows Settings Repair restages MSIX; AppXDeploymentServer: "ACLs repaired successfully", CoworkVMService terminated for update, register result 0x0; status 0x280000 → 0x200000 → 0x0 |
| 11:58–12:00 | App launches cleanly; no further CI/GPU events |

Key forensic facts

1. AppxMetadata\CodeIntegrity.cat is absent from the Claude package both before AND after a successful Repair, with package Status now Ok and the app running. Every other MSIX package sampled on this machine ships one (Microsoft.WindowsTerminal, Microsoft.WindowsNotepad, PerplexityAI.PerplexityApp, OpenAI.Codex). Either the Claude MSIX intentionally omits the CodeIntegrity catalogue or it is systematically lost in staging.
2. app\vk_swiftshader.dll (SHA256 837ED0FD403148C9DB7804C55F0699AD37143DE6B541DE1EA700A1665FB9F553) is byte-identical before and after Repair — no file corruption.
3. Exit code 101457950 (0x060C201E) + UnknownVizError matches anthropics/claude-code#82967 and #68049 exactly.
4. A second, non-MSIX Chromium browser (Comet) hit the identical 3033 "Microsoft signing level" block on its own SwiftShader/Vulkan DLLs 80 minutes earlier the same morning — so the block is process-mitigation-level (Code Integrity Guard on the Chromium GPU child), not unique to Claude's package or catalogue.
5. Both fatal crashes occurred with the embedded preview on a Clerk sign-in page, seconds after a [PreviewContext] Blocked subresource to private-resolving host warning — 2 out of 2. Suspect the page's bot-detection/fingerprinting exercises WebGL/Vulkan and forces a software-rendering fallback, triggering a late load of vk_swiftshader.dll after the GPU process has enabled its DLL signing mitigation.
6. Package Modified-status flapping (0x2 ↔ 0x80002) occurred both post-crash (00:03) and pre-crash (09:59:19, 81 minutes before the 11:20 crash) — package-state instability is correlated with, but not strictly caused by, the GPU crash.
7. No WER 1000/1001 records for claude.exe in 92 days; the crashes are internal Chromium child-process deaths.
8. WHEA corrected PCIe warnings cluster at boot (09:38), not at crash times. No TDR/display-driver resets at crash times. Machine health (RAM/SSD/thermals) unremarkable.
9. Crash dump preserved: 6dcc8b8d-f4ef-42e7-a086-65f8e5854dc6.dmp, SHA256 F45F1F031686BFF1B326E2E62CBC1F4050F5B4702365E293946797C7433216D0 (available on request).

Questions for Anthropic

1. Is the omission of AppxMetadata\CodeIntegrity.cat from the Windows MSIX intentional? If not, is it a packaging-pipeline defect? (All other vendors' MSIX packages on this machine include one.)
2. The GPU child process appears to run with a Code Integrity Guard / signing-level mitigation that blocks a late-loaded vk_swiftshader.dll (which carries no Microsoft signing level). Should SwiftShader be preloaded before the mitigation is applied, signature-exempted, or the fallback disabled — so a software-rendering fallback cannot kill the GPU process permanently? (Cross-vendor precedent: openai/codex#34133 — same DLL, same 3033, catalogue intact.)
3. Why does a GPU-process death correlate with the package being marked Modified → NeedsRemediation, bricking relaunch until manual Repair? (See also #82967, #84333; and #83932 for updater staging into a live package while claude.exe/CoworkVMService run — we observed 0x80070020 job-conversion launch failures with the service running.)
4. Is there a supported way to force software/disable GPU rendering for the embedded preview, or to keep preview rendering out of the main app's fate, so a preview render failure cannot require a package repair?

Impact

Three user-visible incidents requiring package repair (two forensically confirmed with identical signatures on 15 Aug; one earlier incident not yet evidenced). Each incident costs me the running session and ~30–60 minutes of repair. Data was preserved in all cases (hash-verified backups; Repair retains LocalCache).

Timeline, event correlation and hashes were assembled with Claude Code from local Windows event logs and app logs; all forensic claims above were verified read-only on the affected machine. A private support ticket referencing this issue will follow.