[BUG] Claude Desktop MSIX: any WebGPU requestAdapter() bricks the install — missing AppxMetadata/CodeIntegrity.cat makes Windows flag the package "Modified, NeedsRemediation" (root cause for #85199-type crashes)

Preflight Checklist

• [x] I have searched existing issues — #85199, #83016, #88760 report the same symptom; this report contains the root cause with kernel-level evidence, found via live debugger capture
• [x] This is a single bug report
• [x] I am using the latest version (Claude Desktop 1.34493.1.0 MSIX, re-downloaded from api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect today)

TL;DR

Any web content that calls navigator.gpu.requestAdapter() (even simple WebGPU feature detection) kills the entire Claude Desktop MSIX install. The GPU process lazily loads vk_swiftshader.dll; Chromium's CIG mitigation rejects it (normal, Chrome does this daily and shrugs it off), but because the shipped MSIX contains no AppxMetadata\CodeIntegrity.cat, Windows treats the rejection as package tampering: it flags the package Modified, NeedsRemediation, kills the GPU process, all 5 GPU relaunches fail with ERROR_NEEDS_REMEDIATION (0x3CFC), and the browser process aborts via IntentionallyCrashBrowserForUnusableGpuProcess. Windows then demands "Advanced options → Repair", which can never succeed because no file is actually modified.

This is a packaging defect: the MSIX is signed without generating the code-integrity catalog that SignTool normally embeds.

Environment

• Windows 11 Pro 10.0.26200, NVIDIA RTX 3080 (irrelevant — not a driver issue)
• Claude Desktop 1.34493.1.0 MSIX sideload (Claude_pzs8sxrjxfjjc), Electron 42.9.2
• 7/7 crashes in one morning, 100% reproducible; trigger was an MCP widget browser preview whose page probes WebGPU

Full causal chain (every step directly observed on this machine)

renderer: navigator.gpu.requestAdapter()
→ GPU process: dawn::native::vulkan::VulkanInstance::Initialize
    → dawn::DynamicLib::Open → LoadLibraryExA("vk_swiftshader.dll")        [lazy load, after sandbox lockdown]
→ kernel CI (process runs with CIG / RequestedPolicy=8 "Microsoft"):
    CodeIntegrity #3010 ×3: unable to load <pkg>\AppxMetadata\CodeIntegrity.cat — 0xC000003A (path not found)
    CodeIntegrity #3033:    vk_swiftshader.dll "did not meet the Microsoft signing level requirements"
    → NtCreateSection returns 0xC0000462 STATUS_NEEDS_REMEDIATION          [because the file is package content]
→ ntdll!LdrpMapDllNtFileName routes 0xC0000462/0xC000047E/0xC000047F (only these) to:
→ ntdll!LdrAppxHandleIntegrityFailure
    ├ package status → Modified, NeedsRemediation   (flips within 100 ms of the exception; polled at 150 ms)
    └ RtlReportException + NtTerminateProcess(…, 0x060C201E)               [the mystery exitCode 101457950]
→ browser: GPU relaunch ×5, each CreateProcess rejected
    AppModel-Runtime #6 ×5: "0x3CFC: cannot create process … machine-level package state"
→ GpuProcessHost::OnProcessLaunchFailed → FallBackToNextGpuMode (all modes exhausted)
→ content::IntentionallyCrashBrowserForUnusableGpuProcess → LOG(FATAL)     [whole app gone in ~300 ms]
→ next launch: Windows auto-repair loop → fails → "go to Advanced options and select Repair"

Key captures (full bundle available on request — Crashpad browser dump, 402 MB GPU full dump, cdb session logs, ntdll disassembly, per-run event logs):

GPU process, live cdb attach, at the moment of death:

LDR-LOAD: <pkg>\app\vk_swiftshader.dll
  ntdll!LdrLoadDll ← KERNELBASE!LoadLibraryExA ← dawn::DynamicLib::Open
  ← dawn::native::vulkan::VulkanInstance::Initialize ← dawn::native::vulkan::Backend::DiscoverPhysicalDevices
  ← dawn::native::InstanceBase::EnumerateAdapters ← gpu::webgpu::WebGPUDecoderImpl::RequestAdapterImpl
  ← dawn::wire::server::Server::DoInstanceRequestAdapter
(94e4.7934): Unknown exception - code 060c201e (!!! second chance !!!)
ExceptionAddress: ntdll!LdrAppxHandleIntegrityFailure
   frame: ntdll!LdrAppxHandleIntegrityFailure+0x1cb ← ntdll!LdrpMapDllNtFileName+0x499   (arg: 0xC0000462)

Browser process Crashpad dump (!analyze -v):

Claude!logging::LogMessage::HandleFatal ← content::IntentionallyCrashBrowserForUnusableGpuProcess
← GpuDataManagerImplPrivate::FallBackToNextGpuMode ← GpuProcessHost::RecordProcessCrash
← GpuProcessHost::OnProcessLaunchFailed ← ChildProcessLauncher::Notify        (0x3cfc on the stack)

Why nothing in your telemetry explains this

• The GPU process has no Crashpad handler registered, and the exception is raised by ntdll → WER; your logs only show the opaque GPU process gone: reason 'crashed', exitCode 101457950.
• The decisive evidence (CodeIntegrity 3010/3033, AppModel-Runtime #6, package status flip) lives only in the user's Windows event logs.
• The in-app [gpu-recovery] auto-disable logic (threshold: 3 GPU deaths) can never fire: the browser process CHECK-crashes ~300 ms after the first GPU death.
• The Windows "Repair" button runs RepairAppRegistrationOption, repairs ACLs, and still leaves the flag — because package content was never actually modified. Users end up in reinstall loops (→ the session-data destruction reported in #88760, and the installer failure chains in #83016 / #88727 / #88689).

Root cause: the MSIX ships without a CI catalog

• The official MSIX (235.9 MB, v1.34493.1.0, downloaded today) has zero AppxMetadata/* entries — no CodeIntegrity.cat. (It also contains a stray [Content_Types].old, suggesting a custom packing pipeline rather than MakeAppx+SignTool.)
• SignTool sign generates AppxMetadata\CodeIntegrity.cat (hashes of all PE files) when signing an MSIX. Packages on the same machine signed that way (Outlook, MSTeams, WinDbg, and a locally-built test package — none of which declare uap10:PackageIntegrity) all have it; 146 of 318 package folders on this machine do.
• The manifest also declares no <uap10:PackageIntegrity>, so runtime integrity semantics default to enforcement on current Windows 11.
• With a catalog present, CI validates the file against the catalog and the CIG denial stays a plain policy failure (0xC0000428) — exactly Chrome's harmless daily case (verified: same machine, chrome.exe logs the identical #3033 for its vk_swiftshader.dll/vulkan-1.dll many times a day, with zero consequence). Only the catalog-missing path escalates to STATUS_NEEDS_REMEDIATION → LdrAppxHandleIntegrityFailure.

Verified mitigation (and one that does NOT work)

| Launch flag | Result |
|---|---|
| --disable-features=WebGPU,WebGPUService | ✅ Verified: identical trigger (same session, same widget preview) — GPU survives, package stays Ok, zero CodeIntegrity events, app ran to timeout |
| --disable-blink-features=WebGPU | ❌ Still crashes — WebGPU is gated by a base::Feature, not a Blink runtime flag |

(A/B/A verified with a harness that repairs the package, launches, polls package status at 150 ms, and diffs CodeIntegrity/AppModel event logs per run.)

Suggested fixes (any one suffices)

1. Sign the MSIX so AppxMetadata\CodeIntegrity.cat is generated (SignTool or equivalent) — the real fix; makes the CIG denial benign like Chrome's.
2. Or declare <uap10:PackageIntegrity><uap10:Content Enforcement="off"/></uap10:PackageIntegrity> in the manifest.
3. Or stop loading non-Microsoft-signed DLLs after GPU sandbox lockdown: pre-warm vk_swiftshader.dll/vulkan-1.dll before LowerToken(), or disable WebGPU in the packaged build.
4. Defense in depth: the "Repair" dead-end deserves its own look — a package flagged NeedsRemediation with intact contents currently has no in-product recovery path (Add-AppxPackage -ForceUpdateFromAnyVersion over the same version clears it; the Settings "Repair" button does not).

Relationship to existing issues

• #85199 — same user-visible symptom ("Advanced options → Repair" loop); the CoworkVMService lead there is a red herring (we exonerated it: the service runs for minutes without flipping the package; the flip coincides exactly with the WebGPU DLL load).
• #83016 — "WebFetch to arthive.com corrupts the install": consistent with this chain if that page probes WebGPU; the corruption mechanism reported here explains "crash → install corrupted → reinstall required".
• #88760 / #88727 / #88689 / #86530 — downstream damage of the resulting reinstall loops.