Windows MSIX: GPU process killed by Code Integrity loading bundled vk_swiftshader.dll; app terminates and cannot relaunch

**Build:** Claude 1.40609.1.0 x64, MSIX package `Claude_pzs8sxrjxfjjc`
**OS:** Windows 11 26200 · **GPU:** AMD Radeon RX 6600, driver 32.0.21045.5002
**Reproduces:** every time, on any page that starts WebRTC — `dash.cloudflare.com` is reliable

## Summary

The GPU process is terminated by **Windows User Mode Code Integrity** for
attempting to load the application's own `vk_swiftshader.dll`. Every relaunch
is refused for the same reason, so Chromium hits its GPU crash limit and
terminates the entire application.

**No command-line flag avoids it.** Chromium loads that DLL unconditionally
during GPU initialisation. The only mitigation found is
`--disable-gpu-sandbox`, which works by removing the Code Integrity Guard that
raises the objection — i.e. by disabling a security mitigation, which is not an
acceptable long-term answer.

## The evidence

Windows says it directly. **Event 3033**,
`Microsoft-Windows-CodeIntegrity/Operational`, logged at the exact second of
every crash — 55 occurrences observed, one per crash, no exceptions:

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

And immediately alongside it, **Event 3010**:

> Code Integrity was unable to load the
> `\Program Files\WindowsApps\Claude_1.40609.1.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat`
> catalog. **Status `0xC000003A`** (STATUS_OBJECT_PATH_NOT_FOUND)

`0xC000003A` is the more interesting half. The package's own code-integrity
catalogue cannot be loaded, so Windows has no way to honour the package
signature on the application's binaries. It falls back to the Code Integrity
Guard rule that the GPU process runs under — Microsoft-signed only — and
`vk_swiftshader.dll` fails it.

The DLL itself is correctly signed:

```
signer : CN="Anthropic, PBC", O="Anthropic, PBC", L=San Francisco, ...
issuer : CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
status : Valid
```

Valid, but not Microsoft — which is exactly what CIG requires when the package
catalogue is unavailable. `libGLESv2.dll` and `libEGL.dll` carry the same
Anthropic signature and would presumably fail the same way if loaded under the
same conditions.

## What the application sees

```
GPU process exited unexpectedly: exit_code=101457950 (0x060C201E)
GPU process launch failed: error_code=18 x5 in 8 ms
FATAL:gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye.
```

Then the whole process tree ends: 14 processes in a single 400 ms tick,
confirmed by process-level tracing. The browser process itself exits with
`0x80000003` (STATUS_BREAKPOINT) — the `FATAL` above.

Two details worth noting:

- **Windows Error Reporting produces no dump**, with `LocalDumps` verified
configured for `Claude.exe`. That is consistent with termination by Code
Integrity rather than a crash.
- **Only respawns fail.** The GPU process created at application start is fine;
it dies the moment something causes SwiftShader to be loaded, and no
replacement can then be created.

## Reproduction

1. Launch Claude Desktop normally
2. Open `https://dash.cloudflare.com` in the in-app browser
3. The page starts WebRTC (STUN lookups to `stun.cloudflare.com` appear in the
log and fail with `-105`)
4. 1.3–2.5 s later the GPU process dies and the application terminates
5. `Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -Id 3033`
shows the block, timestamped to the second of the crash

The WebRTC connection is the trigger rather than the cause — it disturbs the
GPU context, which leads to the SwiftShader load.

## What does not help

Each of these was tested and left the failure byte-identical, with Event 3033
still logged at the moment of death:

| Attempted | Result |
| --- | --- |
| AMD driver update (Jan 2026 → Aug 2026) | fixed unrelated rendering issues; crash unchanged |
| AMD Radeon Upscaling disabled system-wide, with reboot | unchanged |
| `--disable-direct-composition` | AMD DirectComposition error disappeared; crash unchanged |
| `--disable-webrtc-hw-encoding --disable-webrtc-hw-decoding` | unchanged |
| `--disable-gpu --disable-gpu-compositing` | unchanged — and *forces* the SwiftShader path |
| `--in-process-gpu` | application window renders blank |
| `--disable-gpu-process-crash-limit` | app survives the first death, then retries the failing spawn indefinitely (~130 KB/s of log) and dies anyway |
| `--disable-software-rasterizer` | **Event 3033 still fired** — the DLL is loaded regardless |
| `--disable-software-rasterizer --use-angle=d3d11 --disable-features=Vulkan,DefaultANGLEVulkan,VulkanFromANGLE` | **Event 3033 still fired** |

The last two matter most: the DLL load cannot be prevented by configuration.
The package ships `vk_swiftshader_icd.json` alongside it, and Chromium loads
the ICD during GPU initialisation irrespective of these switches.

## The only mitigation found

`--disable-gpu-sandbox`, passed at launch. With it, the GPU process does not
die, Event 3033 is not logged, and the page loads normally.

This works by removing the Code Integrity Guard mitigation from the GPU
process — the process that parses untrusted image and video data. It is a
usable stopgap and a poor permanent answer.

Because the package is a `Windows.FullTrustApplication` with no execution
alias, flags cannot be passed by an ordinary shortcut. They can be passed with:

```powershell
Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc `
-AppId Claude -Command '\app\Claude.exe' `
-Args '--disable-gpu-sandbox'
```

## A shippable stopgap, if a proper fix needs time

The mitigation above is a launch flag, which end users cannot apply through
the normal Start Menu tile — an MSIX `Windows.FullTrustApplication` with no
execution alias will not carry arguments. So affected users currently have no
way to help themselves without a wrapper script.

The same switch can be set from inside the application, in one line, before
`app.whenReady()`:

```js
app.commandLine.appendSwitch('disable-gpu-sandbox');
```

That would make the workaround available to everyone without asking anyone to
launch the app differently. It has the same security cost as above — the GPU
process loses its sandbox — so shipping it unconditionally is a poor trade.

Two narrower forms avoid paying that cost on machines that are not affected:

**Apply it only when the catalogue is missing.** The condition that causes the
failure is detectable at startup:

```js
const fs = require('node:fs');
const path = require('node:path');

// Under MSIX the package catalogue is what lets Windows validate our own
// signatures inside a Code Integrity Guard process. If it is not there, the
// GPU process will be killed the moment it loads vk_swiftshader.dll, so the
// sandbox has to be dropped or the app cannot survive a GPU restart.
const catalogue = path.join(
path.dirname(app.getAppPath()), '..', 'AppxMetadata', 'CodeIntegrity.cat',
);
if (process.platform === 'win32' && !fs.existsSync(catalogue)) {
app.commandLine.appendSwitch('disable-gpu-sandbox');
}
```

**Or apply it only after the first failure.** Chromium reports GPU process
exits to the main process, so the app can notice the specific failure and
relaunch itself once with the switch, rather than dying:

```js
app.on('child-process-gone', (event, details) => {
if (details.type === 'GPU' && details.reason === 'crashed') {
// exit_code 101457950 (0x060C201E) with an immediately failing respawn is
// the Code Integrity signature; a normal GPU crash respawns cleanly.
relaunchOnceWith('--disable-gpu-sandbox');
}
});
```

The second is the better shape: machines that never hit the fault keep their
GPU sandbox, and machines that would otherwise be unusable lose it only after
proving they need to.

Either is preferable to the current behaviour, where the application
terminates and then cannot be reopened without killing a leftover process by
hand.

## Suggested fixes, in order of preference

1. **Ship a working `CodeIntegrity.cat`.** Event 3010 (`0xC000003A`) says the
package catalogue cannot be loaded at all. If Windows could validate the
package signature, the Anthropic-signed DLLs would satisfy CIG and nothing
else would need to change. This looks like the actual defect.
2. **Have `vk_swiftshader.dll` Microsoft-signed** (Store or attestation
signing), so it passes CIG on its own merits.
3. **Do not apply `MITIGATION_FORCE_MS_SIGNED_BINS` to the GPU process** in the
MSIX build, if the catalogue cannot be made to work.
4. **Fail gracefully.** Independently of the above: a GPU process that cannot
be respawned should not take the application down. Losing hardware
acceleration is recoverable; losing the session is not. The current
behaviour also leaves a windowless process behind that blocks MSIX Repair
("we couldn't repair this app because it's currently running") and prevents
relaunch until it is killed by hand.

## Secondary issue found while investigating

`CoworkVMService`'s DACL grants no rights to `BUILTIN\Administrators`:

```
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-...)
```

Authenticated Users have start/stop/query but not `DC` (change config), and
Administrators appear nowhere. The service logs
`failed to configure recovery actions ... open service: Access is denied` on
every start, and `ChangeServiceConfig2` fails with error 5 even from an
elevated shell. No SCM failure actions are ever set, so after any crash the
service stays stopped, which is what turns a recoverable GPU crash into an
application that will not restart.

Start at the Electron startup path around app.whenReady() and app.commandLine, then reproduce the MSIX failure while checking Code Integrity events 3033 and 3010. Review the GPU child-process-gone entry point and CoworkVMService recovery configuration. Done means the packaged app can relaunch after the GPU failure without requiring users to disable the GPU sandbox, with the chosen fix verified on Windows 11.

Rédigé par le modèle d'indexation à partir du texte de l'issue.