[BUG] Windows MSIX: Code Integrity blocks vk_swiftshader.dll in the GPU process on first in-app Browser use, package flagged NeedsRemediation, app self-terminates (root cause for #49676)

## Summary

On a sideloaded MSIX install, the first use of the in-app Browser preview makes Chromium's GPU process load app\vk_swiftshader.dll. Windows Code Integrity blocks the load because the GPU child process runs under the forced-Microsoft-signed mitigation and the package ships no AppxMetadata\CodeIntegrity.cat. The GPU process dies; Windows then reports the package as Modified, NeedsRemediation; every subsequent CreateProcess for the package fails with 0x3CFC (ERROR_NEEDS_REMEDIATION); Chromium exhausts all GPU fallback modes and calls LOG(FATAL), killing the whole app.

Reproduced 4/4. Reinstalling restores the app only until the next in-app Browser use.

I believe this is the undiagnosed root cause of #49676 (closed as not planned) — same OS build, same MSIX packaging, same silent crash, same ~35 MB Crashpad dump, same final log lines, and the same failure of --disable-gpu / disabling hardware acceleration to help.

Environment

• Windows 11 Home 10.0.26200.8875 (DISM image 10.0.26100.8737)
• Claude Desktop 1.24012.9.0, package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
• SignatureKind: Developer (sideloaded via Claude Setup.exe, AddPackage, all-users: false)
• Electron 42.7.0
• Intel UHD Graphics, driver 31.0.101.4255
• 8 GB RAM

Evidence

1. The package ships no Code Integrity catalog

Test-Path 'C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\AppxMetadata'
False

AppxBlockMap.xml contains zero references to CodeIntegrity.cat, so it is absent from the distributed package, not lost on disk.

Kernel confirms, Microsoft-Windows-CodeIntegrity/Operational Event 3010, three times per crash:

Code Integrity was unable to load the \Device\HarddiskVolume3\Program Files\WindowsApps\
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.

2. The DLL load is blocked

Microsoft-Windows-CodeIntegrity/Operational Event 3033:

Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\WindowsApps\
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\claude.exe) attempted to load \Device\HarddiskVolume3\
Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

RequestedPolicy=8 (Microsoft), ValidatedPolicy=1 (Unsigned), Status=0xC0000428 (STATUS_INVALID_IMAGE_HASH).

3. The package files themselves are intact

All 2180 files / 10909 64 KB blocks were verified by SHA-256 against the package's own AppxBlockMap.xml: zero mismatches. The Modified status is not file corruption.

4. Second-order failure: package flagged, then CreateProcess denied

Microsoft-Windows-AppModel-Runtime/Admin Event 6, five times in ~25 ms:

0x3CFC: Cannot create the process for package <NULL> because an error was encountered
while checking the machine-level package status.

No AppXDeploymentServer Event 617 accompanies the status change — the status is computed live, not written by a deployment operation.

5. The app kills itself

From the Crashpad dump (ptype=browser, pid=2012, 35 421 408 bytes):

[2012:0727/121221.411:FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418]
GPU process isn't usable. Goodbye.

Chromium can survive a GPU process crash by falling back through GPU modes, but every relaunch needs CreateProcess inside the package, which now returns 0x3CFC. After five failures FallBackToNextGpuMode has nowhere left to go.

Timeline of one crash (external monitor, 3 s sampling + millisecond log stamps)

12:12:12.19   [Preview] Created session preview context
12:12:12.19   [Preview] Created browser preview
12:12:14.51   preview navigates about:blank -> an ordinary external web page
12:12:20      renderer initialises WebGL2, then calls WebGPU requestAdapter()
12:12:20.836  CodeIntegrity 3010 x3  (CodeIntegrity.cat missing, 0xC000003A)
12:12:20.865  CodeIntegrity 3033     (vk_swiftshader.dll blocked, 0xC0000428)
12:12:21.0    GPU process dies; renderer logs CONTEXT_LOST_WEBGL
12:12:21.2    package status Ok -> Modified, NeedsRemediation
12:12:21.387  AppModel-Runtime Event 6 x5, 0x3CFC
12:12:21.411  LOG(FATAL) "GPU process isn't usable. Goodbye."
12:12:22.734  AppModel-Runtime 217: Destroyed Desktop AppX container
12:12:24      0 processes

Steps to reproduce

1. Install Claude Desktop on Windows 11 (MSIX, sideloaded) with Memory Integrity / default Code Integrity active.
2. Open a Code session — the Browser preview pane is created automatically.
3. Let it navigate to any page that touches WebGPU.
4. App dies within ~10 s. Package status becomes Modified, NeedsRemediation.
5. The app now refuses to launch at all ("go to advanced options and select Repair").

What does NOT fix it

• Reinstalling the app (works until the next in-app Browser use)
• Add-AppxPackage -Register on the existing manifest — flag persists
• DISM /Online /Cleanup-Image /RestoreHealth + sfc /scannow (repaired unrelated component-store damage; app still died on the next request)
• "isHardwareAccelerationDisabled": true — counterproductive: it routes WebGL to software rendering too, i.e. straight at the blocked SwiftShader
• --disable-gpu, --disable-software-rasterizer --disable-features=WebGPU,Vulkan --use-angle=d3d11 (flags verified present in the process command line; crash unchanged)
• Antivirus is not involved: Defender has zero detections for the package; no third-party AV installed

Verified workaround

Launch the packaged app with:

--disable-gpu-sandbox --disable-software-rasterizer --disable-features=WebGPU --use-angle=d3d11

With this, the Browser preview opens normally, vk_swiftshader.dll is never loaded, no 3033 fires, and the app survives. --disable-gpu-sandbox is the operative flag — the same set without it still crashes.

Because the MSIX declares no uap3:AppExecutionAlias and the claude: protocol only forwards a URL, the arguments have to be passed via COM IApplicationActivationManager::ActivateApplication (CLSID 45BA127D-10A8-46EA-8AB7-56EA9078943C). This is obviously not something a normal user can be expected to do, and it costs the GPU process sandbox.

Suggested fixes

1. Backport / pick up Chromium change 963206a961a7992b048d07f756f87f11fa2e5420, which only preloads SwiftShader when that load is permitted and otherwise takes the Windows fallback path.
2. Ship vk_swiftshader.dll with a signing level acceptable to the GPU child policy, or create the GPU process with AllowStoreSignedBinaries=ON.
3. Include AppxMetadata\CodeIntegrity.cat in the MSIX (necessary but, judging by openai/codex#34133 where the catalog is present and the crash still happens, not sufficient on its own).
4. Degrade gracefully when the GPU child cannot be launched, instead of LOG(FATAL) — a missing GPU process should not take down the application.
5. Separately: a failed Code Integrity check should not leave the package permanently flagged Modified, NeedsRemediation, which is what makes the app unlaunchable afterwards and sends users into repeated reinstall loops.

Related

• #49676 — same OS build, same symptoms, same log tail, closed as not planned; I believe this is its root cause
• openai/codex#34133 — identical mechanism in another MSIX Electron app; there the catalog exists and the DLL still fails the GPU child policy
• OpenAI community thread: "Windows x64: In-app Browser crashes ChatGPT.exe when Code Integrity blocks vk_swiftshader.dll"

Reinstall trap worth documenting

AddPackage failed with HRESULT 0x80073CF6 occurs if chrome-native-host.exe (which lives inside the package's own data directory) is still running: the installer cannot delete existing app data, so registration of the windows.stateExtension fails with 0x80073D05. Killing that process before reinstalling avoids it.