Windows Desktop 26.721.4979.0: Code Integrity blocks bundled `vk_swiftshader.dll` inside the MSIX container, app is killed ~20s after launch (no Crashpad dump)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #35411
• #35352
• #35132
• #35290

Powered by Codex Action

Independent reproduction on 26.721.4979.0 — plus: the package is cryptographically pristine, re-registration does NOT clear the state, and --disable-software-rasterizer does NOT avoid the block

Same build, same CI 3033 on vk_swiftshader.dll, same Modified, NeedsRemediation flip. Windows 11 26200.8875, x64, zh-CN. Four additions that may help narrow this down.

1. Not user-side hardening. On this machine Smart App Control is off (VerifiedAndReputablePolicyState = 0), HVCI is off (Enabled = 0), and Win32_DeviceGuard.SecurityServicesRunning is empty. So the signing-level enforcement that kills the app is the AppX/MSIX container's own, exactly as your isolation test concluded — no third-party AV or user policy is involved. Worth stating explicitly, because the natural first guess for anyone hitting this is "your machine is locked down / your AV ate a file."

2. The Modified flag is spurious — the payload is byte-perfect. I verified the installed package against its own AppxBlockMap.xml:

| Check | Result |
|---|---|
| Files declared in BlockMap | 9544 |
| Present on disk, correct size | 9544 / 9544 |
| Files on disk not in BlockMap | 0 (only AppxManifest/BlockMap/Signature) |
| Per-64KB-block SHA256 over all 69 .exe/.dll/.node/.asar | all match |
| Package root ACL vs a healthy Store package | identical structure |

vk_swiftshader.dll itself hashes clean against the blockmap, i.e. it is exactly the DLL you shipped. So Modified, NeedsRemediation is not file tampering or corruption — it is a derived state produced by the CI kill, and it is what subsequently blocks activation entirely (0x80073CFC, "无法打开这个应用" / "This app can't open" dialog). That makes #35347 a downstream symptom of this issue rather than a separate bug — same build, same status string, and its screenshot matches what we see.

3. Re-registration is not sufficient to recover (relevant to the workaround suggested in #35347). With the package in NeedsRemediation, both of these reported success and left the flag untouched:

Add-AppxPackage -DisableDevelopmentMode -Register "<InstallLocation>\AppxManifest.xml"     # success, still NeedsRemediation
Add-AppxPackage -RegisterByFamilyName -MainPackage OpenAI.Codex_2p2nqsd0c76g0 `
                -ForceApplicationShutdown                                                   # success, still NeedsRemediation

Only re-staging the payload (Store "Repair" / Store update, which rewrites all files) clears it. Until then every activation attempt — including Invoke-CommandInDesktopPackage — fails with 0x80073CFC.

4. Negative result: the obvious flag workaround does not work. After a clean repair (Status: Ok, no leftover processes), I launched the packaged app with package identity preserved and the SwiftShader fallback explicitly disabled:

Invoke-CommandInDesktopPackage -PackageFamilyName OpenAI.Codex_2p2nqsd0c76g0 -AppId App `
  -Command "<InstallLocation>\app\ChatGPT.exe" -Args '--disable-software-rasterizer'

Timeline (T0 = 10:25:54):

| T | Processes | New CI 3033 | Package status |
|---|---|---|---|
| +10s | 7 | 0 | Ok |
| +25s | 11 | 0 | Ok |
| +40s | 14 | 0 | Ok |
| +60s | 7 | 1 | Modified, NeedsRemediation |

CI 3033 on vk_swiftshader.dll at 10:26:53 → AppX container destroyed at 10:26:55 → all processes gone. So --disable-software-rasterizer does not prevent the load inside the container; it only postponed it (59s here vs ~4 min on an unflagged launch earlier the same morning — survival time looks variable rather than flag-dependent). Since vk_swiftshader.dll is the SwiftShader Vulkan ICD, the load is likely happening during Vulkan capability probing, which that switch doesn't gate. Users cannot work around this locally.

Kill signature for anyone triaging: CI 3033 → AppX container 217 destroyed 2–3 seconds later, no Application Error event, no WER, no Crashpad dump — consistent with your "killed by the platform, not crashing" observation. Grepping Microsoft-Windows-AppModel-Runtime/Admin for event 217 next to Microsoft-Windows-CodeIntegrity/Operational 3033 pins it in seconds.

Suggested fix direction (unchanged from yours, just reinforced): ship vk_swiftshader.dll at a signing level the AppX container accepts, or drop/gate the SwiftShader Vulkan ICD from the packaged build. Given that re-registration can't recover the resulting state, each failed launch currently costs the user a Store repair.

⚠️ SUPERSEDED — two claims in this comment are wrong. Please read my final comment instead. 1. The workaround given below (without WebGPU,WebGPUService,Dawn) is incomplete — it survives ~19 min, then dies to the same block when a webview lazily initializes Dawn/WebGPU. 2. "The package version is not the variable" was a bad inference. The clean 07-25 session simply never opened the triggering surface (0 occurrences in the logs); nothing environmental changed on 07-26. Kept for the record rather than deleted, so the correction trail stays readable.

---

Correction to my previous comment: there IS a working workaround — force ANGLE to D3D11 and disable Vulkan. Also: the GPU process is the victim, and the package version is not the variable.

I said earlier that "users cannot work around this locally." That was wrong, and the reason it was wrong points at the actual trigger. Correcting with data.

1. Working workaround (verified, 13 min clean vs 1–11 min to death before)

Launch the packaged app with package identity preserved and Vulkan disabled at the source:

$p = Get-AppxPackage OpenAI.Codex
Invoke-CommandInDesktopPackage -PackageFamilyName $p.PackageFamilyName -AppId App `
  -Command (Join-Path $p.InstallLocation 'app\ChatGPT.exe') `
  -Args '--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE --disable-gpu-compositing'

| T | Processes | New CI 3033 | Package status |
|---|---|---|---|
| +15s | 12 | 0 | Ok |
| +2min | 11 | 0 | Ok |
| +5min | 9 | 0 | Ok |
| +9min | 9 | 0 | Ok |
| +13min | 9 | 0 | Ok |

Longest survival before this was 11m36s (and the three most recent unflagged/mis-flagged launches died at 5m30s, 2m14s, 1m01s). Process composition at +13min: 1 main / 4 renderer / 1 gpu-process / 2 utility / 1 crashpad-handler — the GPU process is alive and the UI is fully functional.

Note --disable-software-rasterizer alone does not work (my earlier test: CI hit at T+59s). That switch gates the software rasterizer fallback; vk_swiftshader.dll is the SwiftShader Vulkan ICD, loaded during Vulkan ICD enumeration in GPU-process init, which that switch never reaches. --use-angle=d3d11 + --disable-features=Vulkan avoids the enumeration entirely.

Caveat for other users: this only helps when launched with the args, so Start-menu/taskbar activation still dies. It is args-only — no files touched, fully reversible.

2. Mechanism: the GPU process is what dies

Each failed session shows this exact sequence in the desktop log, 1 second after the CI 3033:

warning Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed  serviceName=GPU
warning Recoverable Chromium child process gone exitCode=18        processType=GPU reason=launch-failed serviceName=GPU

matched at 08:22:33, 09:26:40, 10:26:54 local — i.e. once per CI 3033 — followed by AppX container destruction (AppModel-Runtime 217) and the flip to Modified, NeedsRemediation. So: GPU process init → Vulkan ICD enumeration → CI blocks the unsigned-for-container SwiftShader ICD → GPU process killed → relaunch fails → container torn down.

3. The package version is not the variable (this may matter for your regression window)

On this machine 26.721.4979.0 was installed 07-25 15:16 and then ran cleanly for 1h54m (container 210 at 15:21:12 → 217 at 17:14:56, zero CI 3033 in that window, and 8 in-app-browser sessions during it). The first CI 3033 ever recorded is 07-26 21:24:31 — ~30 hours later, after a reboot at 21:03. Every session since dies. The CodeIntegrity log on this box retains back to 06-17, so the absence of earlier blocks is real, not log rollover.

Ruled out as the 07-26 trigger, each checked directly:

• CI policy change — the four active policy IDs logged in event 3099 have identical versions across the last 10 days (VBS 10.0.29605.0, Cross-Cert 10.29611.0.0, Endpoint Security 10.0.29526.0).
• GPU driver — Intel Iris Xe 32.0.101.7085, dated 2026-03-03, untouched.
• Server-side flags — the Features enabled set logged on 07-25 and 07-26 is byte-identical.
• In-app browser usage — 07-25 (clean) had 8 IAB backend starts, 07-26 (broken) had 1.
• User-side hardening — SAC off, HVCI off, DeviceGuard not running (from my previous comment).

I have not identified what changed on the evening of 07-26, and I'd rather flag that honestly than guess. If your regression window assumes "shipped broken in 26.721.4979", this data point argues the binary alone isn't sufficient — something makes the GPU process take the Vulkan path where it previously didn't. Anyone else hitting this: checking whether your first CI 3033 predates or postdates your install of this build would help triangulate.

(Also still true from before: the package payload is byte-perfect against its own BlockMap, so Modified remains a derived flag, not corruption.)

⚠️ PARTIALLY SUPERSEDED — "condition 3" below is wrong and retracted here. I claimed the SwiftShader ICD is only loaded when Dawn falls back for lack of a hardware WebGPU adapter, and suggested reproducing on an integrated-GPU machine. Hardware capability provides no protection — the ICD is loaded during adapter enumeration, regardless of whether a hardware adapter exists or is chosen. The reporter's RTX 5090 machine hits it, and on my own box hardware rasterization was demonstrably working (GrShaderCache writes) while the block still occurred. Do not use the integrated-GPU repro recipe. Everything else here (the v3 workaround, Dawn as the loader, flag propagation check, the usage-path explanation) still stands.

---

Second correction + root of the variable repro: the loader is Dawn/WebGPU, not Chromium's Vulkan backend. Full workaround now verified against the actual trigger path.

Two things in my previous comment need fixing, and the fix explains why this reproduces for some users and not others.

1. The earlier workaround was incomplete (19 min, not durable)

--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE --disable-gpu-compositing survived 19 minutes of real use, then died to the same vk_swiftshader.dll block. Sequence in the desktop log, every time:

05:55:27 warning [mcp-app-sandbox] mcp_app_sandbox.attach_unmatched guestWebContentsId=13 url=about:
05:55:29 warning [workspace-settings-webview] Failed to load workspace settings auth handoff
05:55:32 warning [workspace-settings-webview] Failed to load workspace settings auth handoff
05:55:45 warning Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed
05:55:46 warning Recoverable Chromium child process gone exitCode=18        processType=GPU reason=launch-failed

The identical two-line prelude (mcp-app-sandbox attach → workspace-settings-webview Failed) precedes the earlier 07-26 21:24 kill as well. So the ICD is not only loaded at GPU-process startup — a webview opened later initializes it lazily.

It's Dawn/WebGPU. DawnWebGPUCache and DawnGraphiteCache both had files written during the affected session. --disable-features=Vulkan gates Chromium's Vulkan backend; Dawn does its own adapter enumeration and pulls in the SwiftShader Vulkan ICD as a fallback adapter, bypassing that switch.

2. Complete workaround (verified against the real trigger)

$p = Get-AppxPackage OpenAI.Codex
Invoke-CommandInDesktopPackage -PackageFamilyName $p.PackageFamilyName -AppId App `
  -Command (Join-Path $p.InstallLocation 'app\ChatGPT.exe') `
  -Args '--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE,WebGPU,WebGPUService,Dawn --disable-gpu-compositing'

Verification, with the failure path deliberately exercised:

• Flags reach the GPU process (checked Win32_Process.CommandLine of --type=gpu-process): use-angle=d3d11 ✓, disable-features=…Vulkan… ✓, …WebGPU… ✓ — so this is not a "flags silently dropped in the child" false positive.
• Trigger exercised 3× during the run: workspace-settings-webview Failed at 06:24:05, 06:24:58, 06:25:38 plus mcp-app-sandbox attach ×3 and an IAB browser session. Previously that prelude killed the app within 13 seconds.
• Result at T+10.8 min: 12 processes, GPU process alive, 0 new CI 3033, package still Ok.

Caveat: args-only, so Start-menu activation still dies; and disabling WebGPU may degrade any WebGPU-dependent UI.

3. Correcting myself: "the package version is not the variable" was a wrong inference

I reported that 26.721.4979.0 ran cleanly for 1h54m on 07-25 and concluded the build wasn't the differentiator, with an unexplained change on 07-26. That inference was wrong. Counting the trigger in the desktop logs:

| Date | workspace-settings-webview occurrences | CI 3033 |
|---|---|---|
| 07-13 … 07-24 (older builds) | 0 | 0 |
| 07-25 (this build, 1h54m clean session) | 0 | 0 |
| 07-26 | 10 | 1 |
| 07-27 | 34 | 4 |

The clean 07-25 session simply never opened that surface. Nothing environmental changed on 07-26. Also worth noting: the workspace-settings-webview component does not appear anywhere in this machine's logs before 07-26, across all builds back to 07-13 — so on this box the trigger surface itself is new with 26.721.41059.

4. Why this repros for some users and not others (three conditions must coincide)

1. Build ships vk_swiftshader.dll at a signing level the AppX container rejects.
2. A code path initializes WebGPU/Dawn — e.g. the workspace-settings webview or an mcp-app-sandbox guest. Users who never open those surfaces never trip it. This alone explains multi-hour "it was fine yesterday" gaps on an already-broken build.
3. Dawn falls back to the SwiftShader adapter — i.e. no suitable hardware WebGPU adapter. On machines where Dawn gets a hardware D3D12 adapter, vk_swiftshader.dll is never loaded and the CI block never fires.

Condition 3 is the environment-dependent one and is probably why this is hard to reproduce internally: this machine is Intel Iris Xe integrated graphics, driver 32.0.101.7085 (2026-03-03). Boxes with discrete GPUs or newer drivers likely take the hardware path and never see it. Note this is not about user-side hardening — SAC, HVCI and DeviceGuard are all off here (previous comment); the container's signing-level enforcement is standard.

Implication for the fix: gating only Chromium's Vulkan backend will not be sufficient — Dawn's adapter enumeration reaches the ICD independently. Either ship the ICD at an acceptable signing level, drop it from the packaged build, or prevent Dawn from enumerating the SwiftShader fallback inside the container. Reproduction recipe if useful: run the packaged build on an integrated-GPU machine and open the workspace settings surface.

Retraction: my "condition 3" (only integrated-GPU machines are affected) is wrong — please disregard that repro recipe. The blast radius is wider.

In my previous comment I claimed the SwiftShader ICD is only loaded when Dawn falls back for lack of a hardware WebGPU adapter, and suggested reproducing on an integrated-GPU machine. The reporter's own hardware falsifies that: RTX 5090 Laptop (32.0.15.9201) + Intel Graphics (32.0.101.8331), both healthy — a machine with an unambiguously capable hardware WebGPU adapter — and it still hits the block.

Re-checking my own data, it contradicted me too and I missed it: during the affected 19-minute session on this machine, GrShaderCache received new files and the GPU process was alive and healthy the whole time, i.e. hardware GPU rasterization was working — and vk_swiftshader.dll was still loaded and blocked. So it was never a "no hardware → fall back" situation here either.

Corrected mechanism: the ICD is loaded during adapter enumeration, not during fallback selection. Dawn enumerates available adapters — including the SwiftShader fallback adapter — to build the adapter list, and that enumeration LoadLibrarys the ICD regardless of whether a hardware adapter exists or is ultimately chosen. Hardware capability provides no protection.

Revised conditions for hitting this — now only two, and neither is hardware:

1. Running a build that packages vk_swiftshader.dll at a signing level the AppX container rejects.
2. Exercising a surface that initializes WebGPU/Dawn (on this machine: the workspace-settings webview / mcp-app-sandbox guest). Users who never open such a surface don't trip it — that alone explains long "it was fine until now" gaps on an already-broken build, and it's why the same build ran 1h54m clean here on 07-25 with zero occurrences of that surface in the logs.

So the practical blast radius is every user on an affected build who opens one of those surfaces, independent of GPU. That likely makes this higher-severity than my previous comment implied, and it means the internal repro does not need special hardware — just the packaged build plus opening the workspace-settings surface.

The rest of my earlier findings are unaffected: flags do propagate to the GPU process (verified via Win32_Process.CommandLine); the full workaround --use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE,WebGPU,WebGPUService,Dawn --disable-gpu-compositing held through 3 deliberate triggerings of the failure path with 0 CI 3033 at T+10.8 min; and gating only Chromium's Vulkan backend is insufficient because Dawn enumerates independently.

Apologies for the noise — flagging it explicitly because a hardware-specific repro recipe would have sent triage in the wrong direction.