Windows MSIX/AppX: GPU process killed when Code Integrity rejects an externally-injected DLL (Auto Super Resolution), not an app-bundled one

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

44.2.0

### What operating system(s) are you using?

Windows

### Operating System Version

Windows 11 Home, build 10.0.26200, ARM64

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Does the issue also appear in Chromium / Google Chrome?

No

### Expected Behavior

An MSIX/AppX-packaged Electron application should initialize its GPU process
successfully even when a third-party DLL injected into that process by the
operating system fails the GPU child's binary-signature policy.

If an injected module cannot be loaded under the GPU process's Code Integrity
policy, the load failure should be non-fatal — as it is for the same DLL in
non-packaged Chromium processes on the same machine — rather than terminating the
GPU process and, after the retry limit, the entire application.

### Actual Behavior

This is a distinct trigger from #52700, and it contradicts the packaging-defect
conclusion reached in that thread.

In every report on #52700 the rejected DLL is `vk_swiftshader.dll`, bundled
*inside* the application package — so the app's own signing and Code Integrity
catalog are plausibly at fault, and the assessment there concluded this was
"primarily a packaging defect."

In this report the rejected DLL is **`SuperResExt.dll`, shipped by Microsoft in a
separate MSIX package** (`Microsoft.AutoSuperResolution`) and injected into the
GPU child from outside the application entirely. The affected applications'
signing, catalogs and page hashes are irrelevant to it. **No amount of correct
application packaging can prevent this failure.**

## Mechanism

On Copilot+ ARM64 hardware, Windows Auto Super Resolution injects
`SuperResExt.dll` into Chromium-based processes. In MSIX-packaged Electron apps
the GPU child runs with `MicrosoftSignedOnly`; the injected DLL does not satisfy
it; Code Integrity logs Event 3033 and the GPU process is killed. Chromium
respawns it, the identical rejection recurs, and the app aborts at the retry
limit.

Because injection happens at launch, **the app never draws a window** — no error
dialog, no in-app recovery, and on MSIX no way for a user to pass a mitigating
flag.

## Two unrelated MSIX Electron apps affected; non-MSIX control unaffected

| App | Packaging | Arch | Result |
|---|---|---|---|
| Claude Desktop 1.52386.3.0 | MSIX | arm64 native | Dies at launch |
| Proton Pass 1.40.0.0 | MSIX | x64 under Prism emulation | Dies at launch |
| VS Code (arm64) | **non-MSIX**, `%LOCALAPPDATA%\Programs` | arm64 native | **Works**, GPU sandbox enabled |

Different vendors, different Electron versions, different architectures. The only
shared property is MSIX packaging.

## The rejection is routine machine-wide — only MSIX makes it fatal

Event 3033 counts for `SuperResExt.dll` over a 2-day window on this machine:

| Process | Event 3033 count | Outcome |
|---|---|---|
| `msedgewebview2.exe` | 112 | Works |
| `claude.exe` | 36 | **Dies** |
| `ProtonPass.exe` | 27 | **Dies** |
| `msedge.exe` | 4 | Works |
| `Code.exe` | 1 | Works |

Edge, WebView2 and VS Code take the same rejection of the same DLL, in the same
sessions, and carry on normally. This also answers the Chrome/Chromium question:
the rejection occurs there too, the fatality does not.

## Crash signature

Claude Desktop:
ERROR:content\browser\gpu\gpu_process_host.cc:1017]
GPU process exited unexpectedly: exit_code=101457950
... to 6 crashes ...
FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418]
GPU process isn't usable. Goodbye.

Proton Pass:
ERROR:content\browser\gpu\gpu_process_host.cc:999]
GPU process exited unexpectedly: exit_code=101457950
... to 9 crashes ...
FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:415]
GPU process isn't usable. Goodbye.

exit_code 101457950 = 0x060C201E — same code as #52700 and the Codex reports

Code Integrity event (`Microsoft-Windows-CodeIntegrity/Operational`), verbatim:

Code Integrity determined that a process (\Device\HarddiskVolume14\Program
Files\WindowsApps\Claude_1.52386.3.0_arm64__pzs8sxrjxfjjc\app\claude.exe)
attempted to load \Device\HarddiskVolume14\Program Files\WindowsApps\
Microsoft.AutoSuperResolution_1.0.1.0_arm64__8wekyb3d8bbwe\SuperResExt.dll
that did not meet the Microsoft signing level requirements.

One Event 3033 plus three Event 3089 per GPU child spawn attempt, second-aligned
with each crash. Identical event text for `ProtonPass.exe`.

**Note:** `vk_swiftshader.dll` (5.0.0) IS present in the Claude Desktop package,
but it was NOT rejected in this reproduction — no Event 3033 names it, and no
Event 3010 (missing `CodeIntegrity.cat`) appears. The only rejected module is the
externally-injected `SuperResExt.dll`. The app ships the binary implicated in
#52700, Code Integrity accepted it, and the crash originated elsewhere.

## A/B test — three states, same machine

| ASR state | `claude.exe` 3033 events | Claude Desktop |
|---|---|---|
| Package registered (Windows default) | 36 | Dies at launch |
| Toggled **Off** in Settings, rebooted | 12 | Dies at launch |
| Package **removed**, rebooted | 0 | **Launches normally** |

After removal both apps launch from their Start Menu tiles with no flags and the
GPU sandbox fully enabled. The Windows Settings toggle does not stop injection,
so the only user-available mitigation is removing a Microsoft OS component.

## Flag bisect — eliminates the graphics stack

| Flag | Result |
|---|---|
| *(none)* | Crash |
| `--use-angle=d3d11-warp` | **Crash** |
| `--in-process-gpu` | Works, hardware acceleration intact |
| `--disable-gpu-sandbox` | Works, hardware acceleration intact |

WARP is Microsoft's CPU software rasteriser and does not touch the vendor GPU
path, so the crash surviving it rules out the GPU driver and the ANGLE D3D11
rendering path. Both working flags eliminate the *restricted child process*
rather than changing rendering, localising the fault to GPU child creation under
the signing policy.

## Ruled out

- **GPU driver** — identical on current Qualcomm UGD 31.0.152.1; survives WARP. `anthropics/claude-code#68049` reports identical failure on an older OEM driver on comparable hardware.
- **Orphaned/zombie SID DACLs (#51761)** — `%LOCALAPPDATA%` DACL clean (SYSTEM, Administrators, user only; no orphaned `S-1-15-2-*`). Both failing packages' DACLs are equivalent to Windows Terminal, Notepad and Proton Pass; `S-1-15-2-2` is absent from **all** of them including the working ones, so its absence is not the differentiator on this platform.
- **App package signing/catalog** — `Get-AppxPackage` Status: Ok for both; the rejected DLL is in neither package.
- **Qualcomm Snapdragon/Adreno Control Panel** — uninstalled, rebooted, no change.
- **Exploit Protection** — `Get-ProcessMitigation -System`: every mitigation `NOTSET`, no overrides.
- **WER** — no Application Error/Hang entry; no Display/Dxgkrnl TDR events at any crash timestamp.

### Testcase Gist URL

_No response_

### Additional Information

Environment:
Device: ASUS Zenbook A14 UX3407QA
SoC: Qualcomm Snapdragon X X1-26-100 (ARM64, Copilot+)
GPU: Qualcomm Adreno X1-45, driver 31.0.152.1 (2026-05-23,
Qualcomm Upgradeable Graphics Driver)
OS: Windows 11 Home, build 10.0.26200, ARM64
Device Guard: HVCI + System Guard Secure Launch active
(SecurityServicesRunning {2,3})
Exploit Prot: all system mitigations NOTSET, no overrides

Electron version: not determinable from the shipped MSIX builds. Both vendors
overwrite the executable's version metadata with their own app version
(claude.exe reports 1.52386.3; ProtonPass.exe reports 1.40.0), and the bundled
Chromium DLLs carry no usable Chromium version string. The two affected apps
clearly bundle different Electron versions, evidenced by the differing source
line numbers in the crash output above (gpu_process_host.cc:1017 vs :999,
gpu_data_manager_impl_private.cc:418 vs :415) — which also indicates the failure
is not specific to one Electron version.

Claude Desktop auto-updated from 1.46388.4.0 to 1.52386.3.0 during this
investigation; the crash reproduced identically on both builds. The source line
numbers above correspond to the build bundled with 1.46388.4.0.

Relationship to existing reports:
electron/electron#52700 — same fatality mechanism (MSIX + CIG rejection kills
the GPU child), different trigger. The rejected DLL here is injected by the
OS from a separate package rather than bundled in the app, which the
packaging-defect explanation in that thread does not cover.
electron/electron#51761 — different root cause (orphaned SID DACLs), ruled out
here.
anthropics/claude-code#68049 — same device class and exit code, closed as
invalid for want of this root cause; that reporter could not test any flags
because direct exe launch from WindowsApps was ACL-blocked.
anthropics/claude-code#81341 — same CIG mechanism, bundled vk_swiftshader.dll.
openai/codex#34133 — Event 3033, Status 0xC0000428, RequestedPolicy 8,
ValidatedPolicy 1, then exitCode 101457950.

Also filed with Microsoft via Feedback Hub, since Auto Super Resolution, the
signing policy, and the failing binary are all Microsoft-side:
https://aka.ms/AA13dw5h (opens in the Windows Feedback Hub app)

Diagnosability note: the surfaced symptom is a bare GPU-process exit code with no
module name anywhere in the Electron log. The Code Integrity event log is the only
place the cause appears, and nothing points a user toward it. Logging the rejected
module on GPU child launch failure would stop this class of bug being
misattributed to graphics drivers — which is what happened in
anthropics/claude-code#68049.

Start with content/browser/gpu/gpu_process_host.cc and gpu_data_manager_impl_private.cc at the reported crash locations, then trace GPU child creation and retry handling under the MSIX signing policy. Reproduce with an externally rejected SuperResExt.dll and compare the default, --in-process-gpu, and --disable-gpu-sandbox cases. Done means the GPU process and application remain usable when that injected module is rejected, without disabling the GPU sandbox.

Written by the indexing model from the issue text.