[BUG] [CRASH] {solution proposed} Shipped MSIX has no AppxMetadata\CodeIntegrity.cat — vk_swiftshader.dll blocked by Code Integrity, AppX container destroyed (0x3CFC) **Needs packaging (and something to protect data from getting nuked.)

Independent verification confirms five complete occurrences today at 03:33, 03:40, 03:49, 14:30, and 15:27. Each occurrence contains the same sequence: Code Integrity Event 3010 attempting to load the absent AppxMetadata\CodeIntegrity.cat, Event 3033 rejecting app\vk_swiftshader.dll, five AppModel-Runtime Event 6 failures with 0x3CFC, and subsequent destruction of Claude’s AppX container.

The package directory is readable. AppxSignature.p7x, AppxBlockMap.xml, and app\vk_swiftshader.dll exist, but the entire AppxMetadata directory does not. The catalog failure is therefore not caused by access permissions.

The absence of CodeIntegrity.cat alone does not necessarily make an MSIX invalid. However, Windows is explicitly attempting to load that catalog for this Claude installation immediately before rejecting vk_swiftshader.dll and terminating the application. This indicates an inconsistent package registration, deployment, or signing-integrity state.

Get-AppxPackage still reports Status: Ok, so the normal package-registration health check is not detecting the runtime integrity failure.

Determining whether the catalog was omitted from Anthropic’s original package or lost during installation requires comparison against the original signed MSIX/MSIXBundle.

Additional evidence collected after filing:

The same complete failure sequence occurred five times today: 03:33, 03:40, 03:49, 14:30, and 15:27. Each occurrence included Code Integrity Event 3010, Event 3033 involving app\vk_swiftshader.dll, five AppModel-Runtime Event 6 failures with 0x3CFC, and subsequent destruction of Claude’s AppX container.

The current package directory is readable and contains AppxSignature.p7x, AppxBlockMap.xml, and app\vk_swiftshader.dll, but the entire AppxMetadata directory is absent. Therefore, the failure to load AppxMetadata\CodeIntegrity.cat is not a permissions error. Event 3010 reports 0xC000003A (STATUS_OBJECT_PATH_NOT_FOUND), consistent with the missing path.

Get-AppxPackage nevertheless reports Status: Ok. Although CodeIntegrity.cat is not required in every MSIX configuration, Windows is explicitly attempting to load it immediately before rejecting vk_swiftshader.dll and failing Claude process creation. This suggests an inconsistent deployment, registration, or signing-integrity state.

The precise sub-second sequence was verified for the 15:27 occurrence. The four earlier occurrences were verified as having the same ordered event types, but their sub-second timing was not separately analyzed.

PS C:\Users\yosef> $p = (Get-AppxPackage -Name Claude).InstallLocation; Get-ChildItem $p | Select-Object Name; "CodeIntegrity.cat present: $(Test-Path (Join-Path $p 'AppxMetadata\CodeIntegrity.cat'))"

Name
----
app
assets
AppxBlockMap.xml
AppxManifest.xml
AppxSignature.p7x
priconfig.xml
resources.pri
resources.scale-200.pri
CodeIntegrity.cat present: False

PS C:\Users\yosef> Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppModel-Runtime/Admin'; Id=6; StartTime=(Get-Date).Date} | Group-Object {$_.TimeCreated.ToString('HH:mm')} | Select-Object Name,Count

Name Count
---- -----
15:27 5
14:30 5
03:49 5
03:40 5
03:33 5

PS C:\Users\yosef>

This is probably a straightforward fix on the packaging side: the installed package
contains no AppxMetadata directory at all, so a likely first step is to generate and
include CodeIntegrity.cat in the MSIX build step. With the catalog present, Windows
could validate bundled DLLs like app\vk_swiftshader.dll against the package signature
instead of rejecting them (Event 3033), which appears to be what escalates into the
fatal 0x3CFC / container destruction.

One caveat: many MSIX packages ship without a catalog and run fine — and this one does
run fine most of the time. Something makes Windows enforcement intermittent (the app
survived hours between failure bursts). So shipping the catalog is likely a reliable
workaround for the trigger condition, but the intermittent escalation itself may be
OS-side policy behavior that only your telemetry can fully explain.

Two further data points:

1. This package has now been fully deleted and reinstalled four times on this machine.

Every install produced the same state: readable package directory, no AppxMetadata
directory, CodeIntegrity.cat absent. This makes a corrupted individual download or
install unlikely — either the shipped MSIX does not contain the catalog, or the
deployment pipeline reproducibly drops it.

1. On why enforcement bites on this machine while most users never see it: Smart App

Control is Off, but WDAC reports an enforced code-integrity policy
(Win32_DeviceGuard.CodeIntegrityPolicyEnforcementStatus = 2). An enforced CI policy
would explain why Windows insists on validating app\vk_swiftshader.dll against the
(absent) catalog and escalates to the fatal 0x3CFC, and why the failure is
machine-dependent rather than universal.

Verification command for point 2:
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
Select-Object CodeIntegrityPolicyEnforcementStatus, SmartAppControlState

Root cause: the deployed MSIX has no AppxMetadata directory, so vk_swiftshader.dll is blocked by Code Integrity

Reproduced deliberately on 2026-08-11 with an event-log sentinel running. Same
signature as 5 prior spontaneous occurrences on this machine the same day.

Environment

• Windows 11 Home 10.0.26200, x64, 16 GB
• Claude desktop 1.26832.0.0, package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
• Installed from the official Claude Setup.exe (5 separate installs, all identical)

The package is missing AppxMetadata entirely

C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\ contains:
app assets microsoft.system.package.metadata
AppxBlockMap.xml AppxManifest.xml AppxSignature.p7x
priconfig.xml resources.pri resources.scale-200.pri

There is no AppxMetadata\ directory, and therefore no AppxMetadata\CodeIntegrity.cat.
The Code Integrity error status is 0xC000003A = STATUS_OBJECT_PATH_NOT_FOUND —
the catalog is absent, not corrupt. This matters for triage: it is not local
file damage, it is what the installer deploys.

Event sequence (identical on every occurrence)

| # | Log | ID | Event | Count |
|---|---|----|-------|-------|
| 1 | CodeIntegrity/Operational | 3010 | AppxMetadata\CodeIntegrity.cat failed to load, status 0xC000003A | x3 |
| 2 | CodeIntegrity/Operational | 3033 | app\vk_swiftshader.dll did not meet Microsoft signing level requirements | x1 |
| 3 | AppModel-Runtime/Admin | 6 | 0x3CFC: Cannot create the process for package <NULL> ... error while checking the machine-level package status | x5 |
| 4 | AppModel-Runtime/Admin | 217 | Destroyed Desktop AppX container ... for package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc | x1 |
All four fire within the same second; the container dies ~1s later.

Why the DLL is blocked despite being correctly signed

app\vk_swiftshader.dll carries a valid Authenticode signature:
Status : Valid
Subject: CN="Anthropic, PBC", O="Anthropic, PBC", L=San Francisco, S=California, C=US
Issuer : CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Serial : 0ED59CA47F15D09A57755E4B12D31A50
Valid : 2025-10-13 -> 2026-10-20

An Authenticode signature is not a Microsoft signing level. Inside a
WindowsApps package that attestation comes from AppxMetadata\CodeIntegrity.cat.
With the catalog absent, CI refuses the load, the package's machine-level status
check then fails (0x3CFC), and the AppX container is destroyed. Every open
window, session and shell dies with it.

Trigger

vk_swiftshader.dll is Chromium's software-rasterizer fallback, so the crash
fires whenever the renderer falls back off the GPU. In practice that is
render-heavy UI work — I reproduced it on demand by loading an app page and
submitting a form under load. That explains the "random" timing: it is not
random, it is whenever GPU fallback is attempted.

Reinstalling does not help

Five installs from the official bootstrapper produced five packages with the same
missing directory. The fix has to be in what is packaged/published, not on the
client. Suggested checks on your side:

1. Whether the MSIX build pipeline is emitting AppxMetadata\CodeIntegrity.cat

at all for this version, or whether it is being dropped at signing/publish.

1. Whether shipping vk_swiftshader.dll in the package is necessary, given it

only loads on the fallback path that is guaranteed to be blocked without the
catalog.

Also observed

At 15:32:55 a package removal was rejected:
Remove failed: PreserveApplicationData on non-dev package (x2) — worth noting
for anyone told to uninstall cleanly first.

Evidence

Full bundle collected by an event-log sentinel: crash-events.txt (71 events
across 19 timestamp clusters, 2026-08-11 01:33 -> 16:14) plus raw .evtx for
Microsoft-Windows-CodeIntegrity/Operational,
Microsoft-Windows-AppModel-Runtime/Admin,
Microsoft-Windows-AppXDeploymentServer/Operational and System.
Happy to attach.
Note: the application-side %APPDATA%\Claude\logs\main.log is truncated on
crash-restart, so it contains nothing from before the crash — it begins at
Starting app for the new process. Anyone asking reporters for main.log after
a crash is getting a file with the relevant portion already deleted. The Windows
event logs above are the only surviving record.

intuitively i tried researching how to to graft the catalog from another version but aparently I cant on my end and it needs to come from the current hash.

The intuitive workaround — copy AppxMetadata\CodeIntegrity.cat from a different
Claude version into this package — cannot work, and makes things worse:

1. A catalog is a hash manifest of one specific build. A .cat from another

version does not contain the hash of 1.26832.0.0's vk_swiftshader.dll, so
Code Integrity blocks the load exactly as it does now — identical 3033 event.

1. C:\Program Files\WindowsApps is TrustedInstaller-owned; writing there means

taking ownership of a system directory.

1. AppxBlockMap.xml / AppxSignature.p7x cover package contents. Adding files

breaks the package's own integrity, which can break servicing and future
updates — turning a crash into a package that will not update.

There is no client-side fix for the missing catalog. It has to be corrected in
what is published.