[BUG] Claude Desktop MSIX: CIG (MicrosoftSignedOnly) + vendor-signed vk_swiftshader.dll kills GPU process on every browser preview (0x060C201E)

Confirming this on discrete NVIDIA hardware, and adding one piece of evidence that I think narrows down where the fix belongs.

Environment: Windows 11 Pro 10.0.26200, Claude Desktop 1.24012.9.0, package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer, RTX 5060 Ti (driver 32.0.16.1074). Three fatal crashes over two days, each one preceded within two seconds by CodeIntegrity 3033 on app\vk_swiftshader.dll, GPU process exit 101457950, app gone.

The same CIG block hits other Chromium apps on this machine and none of them die. Every 3033 event in my log over 20 days:

11  Discord.exe   graphics-hook64.dll      (OBS)
11  Discord.exe   OWClient.dll             (Overwolf)
11  Discord.exe   ow-graphics-vulkan.dll   (Overwolf)
 3  claude.exe    vk_swiftshader.dll
 2  chrome.exe    vk_swiftshader.dll
 2  chrome.exe    vulkan-1.dll

Chrome took the identical block on its own vendor-signed vk_swiftshader.dll and kept running, no crash record that day. Discord takes it 33 times and keeps running. So CIG blocking a vendor-signed SwiftShader is normal Chromium behaviour and survivable. What is not survivable is what follows it here: CreateProcess for the package starts failing with 0x3CFC and the app cannot respawn its children, so the whole thing goes down. That part looks specific to the packaging rather than to CIG or to SwiftShader.

Worth stressing because it suggests two independent fixes. Shipping the catalog stops the block happening. Surviving a GPU process death, which every other Chromium app on this machine already manages, stops the outage even when the block does happen.

One difference from this report and from #81398: I do not need to reinstall. My package still reads Status: Ok and the app relaunches cleanly after each crash, despite the 0x3CFC errors at crash time. So the activation failure appears recoverable on some machines and sticky on others, which might be a useful variable to isolate.

Disabling hardware acceleration does not help, matching #81745. I ran that experiment: verified via loaded modules that the GPU process had zero nv*.dll and was on D3D10Warp.dll, and it still died with the identical exit code. WARP covers GL and compositing but Vulkan and WebGPU still fall through to SwiftShader, so the toggle moves the workload onto the exact path that is blocked.

Why nobody finds a crash dump. WerFault is blocked in the same window:

20:43:10  CodeIntegrity 3033   claude.exe  ->  vk_swiftshader.dll  blocked
20:43:11  Mitigations 36       WerFault.exe blocked from NtFsControlFile
20:43:12  AppModel-Runtime 6   0x3CFC: Cannot create the process for package  (x5)

That likely explains the "no crash dump" in #77768 and the empty Crashpad directories elsewhere. There is no Application Error record for claude.exe at any of my three crashes, which sent me chasing my GPU driver for a day and a half before I found the CodeIntegrity log.

Consistent with the browser-pane trigger in several of the linked issues, a Browser preview server was up at the time of the third crash, started six minutes earlier:

20:37:24  [Launch] Updating active servers store { count: 1, servers: [{"serverId":"browser-preview-...","name":"Browser","status":"running"}] }
20:43:12  GPU process gone: { reason: 'crashed', exitCode: 101457950 }

Impact worth flagging separately: the app dying takes running agent sessions with it, with no recovery and no notification. The 7/26 21:22 crash killed three live background tasks ([CCD] Skipping pause for session ... - 3 active background task(s), logged 62 seconds earlier) and the app stayed down for the next seven and a half hours until I restarted it by hand the following morning.

Open issues describing the same or a closely related failure, in case it helps consolidate triage:

#81745, #80999, #81275, #81698, #81398, #77768, #80978, #81578, #81159, #80483, #81358

Eleven besides this one, filed between 7/15 and 7/27. #77768 is the earliest I can find and dates the regression to around 7/15.

Confirming this on Windows 10 Pro 19045, with the mechanism measured rather than inferred. The existing reports in this cluster are all Windows 11, so this adds an OS data point, a Chrome control group with numbers, and a check on whether the package ships a code-integrity catalogue.

Environment

• Windows 10 Pro, build 19045, x64.
• Package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, installed from "Claude Setup.exe", not the Microsoft Store. SignatureKind: Developer, publisher Anthropic PBC via DigiCert.
• app\version reads 42.7.0, so Electron 42.7.0, which pins Chromium 148.0.7778.280.

What happens

Any page in the Browser pane that calls navigator.gpu.requestAdapter() kills the app. Dawn probes for a SwiftShader fallback adapter, which loads app\vk_swiftshader.dll from the package. The GPU child runs under Chromium's Code Integrity Guard, so Windows refuses the image. The GPU process dies, the browser process exhausts its GPU fallback modes and calls FATAL, and the app hangs rather than exits. On the next launch Windows tries to repair the package, fails because the AppX container is still occupied, and shows the generic "There's a problem with Claude. Reinstall the application from its original install location or contact your administrator."

Measured evidence

1. Code Integrity Guard, measured live with Get-ProcessMitigation against the running claude.exe --type=gpu-process: MicrosoftSignedOnly = ON, AllowStoreSignedBinaries = OFF. The parent browser process has both OFF. This is Chromium's own MITIGATION_FORCE_MS_SIGNED_BINS, applied to sandboxed children via SetDelayedProcessMitigations, so it arms after startup.
2. The blocked binary is validly Authenticode-signed. Get-AuthenticodeSignature on the packaged vk_swiftshader.dll returns Status: Valid, Kind: Authenticode, Signer: CN="Anthropic, PBC", O="Anthropic, PBC", L=San Francisco, S=California, C=US, issuer DigiCert. It is refused anyway, because no third-party signature reaches Microsoft signing level.
3. Windows event log, Microsoft-Windows-CodeIntegrity/Operational, event id 3033: status 0xC0000428, RequestedPolicy 8, ValidatedPolicy 1, on the packaged vk_swiftshader.dll.
4. The GPU process exits with 101457950 (0x060C201E). The browser process then logs "GPU process gone" repeatedly with launch error_code 18, and calls FATAL. That last step is Chromium's GpuDataManagerImplPrivate::FallBackToNextGpuMode() reaching IntentionallyCrashBrowserForUnusableGpuProcess() once fallback modes are exhausted.
5. Chrome control group, same machine, same OS, same CIG behaviour. Stock Chrome logged the identical 3033 block on its own vk_swiftshader.dll 275 times and on vulkan-1.dll 276 times in the same log window, and never crashed. Claude's own DLL was blocked exactly twice in 41 hours of log, both inside the crash seconds. The refusal itself is routine and survivable. What is not survivable is the escalation to a browser-process FATAL.
6. Repair chain. On the next launch, explorer.exe calls RegisterByPackageFullName with RepairAppRegistrationOption. It fails with 0x80073D02 ERROR_PACKAGES_IN_USE because the AppX container is still occupied by the wedged processes, and Windows shows the generic reinstall dialog. Killing the container processes and relaunching recovers it, so no reinstall is actually needed.
7. Package contents. This package ships no code-integrity catalogue at all: the AppxMetadata folder is absent and there are zero .cat files anywhere under the install root. The catalogue is not the fix, though. In the equivalent OpenAI Codex case (openai/codex#34133) the catalogue is present and valid, validates at Store signing level 6, and the load is still refused against requested level 8.

Caveat about the binary on disk

The package was re-staged after the crash. The deployment log shows same-version AddPackage operations with ForceApplicationShutdownOption,ForceUpdateFromAnyVersion following the incident. Anything hashed or inspected on disk now describes the re-staged copy, not the exact image that was blocked at crash time. The event-log entries above are from the crash window itself and are unaffected.

Why a Chromium or Electron bump will not fix this

Chromium hit this in 2022 and solved it by preloading vk_swiftshader.dll before sandbox lockdown (commit 51c97ad46b7b, bug 1266550). The in-tree comment states that adding the DLL to the sandbox allowlist is impossible, because the sandbox only admits Microsoft-signed code, and that the refusal is meant to be non-fatal. In March 2026 commit 97b3f5d7800fde085af53b1b7455b730c215a874 (bug 489001140, mirrored in the gpu subtree as 963206a961a7992b048d07f756f87f11fa2e5420) narrowed that preload to flag-gated cases, on the reasoning that WARP is now the default Windows software rasterizer. It landed in 148.0.7734.0 and reached stable in 148.0.7778.49. Electron 42.7.0 pins 148.0.7778.280, and none of its chromium patches touch gpu_init.cc, vk_swiftshader or FORCE_MS_SIGNED. So this build already contains the narrowing, and no upstream bump restores the preload.

That leaves the load happening late, from the Dawn fallback-adapter probe, after the delayed mitigation is armed.

Possible fixes, ranked

• Do not escalate a refused fallback-adapter load into a dead GPU process and a browser FATAL. Chrome takes the identical refusal hundreds of times on this machine and stays usable, so this is provably achievable, and it is the only fix that also covers every other CIG-refused module.
• Stop shipping vk_swiftshader.dll and rely on WARP, which is Chromium's own stated reason for narrowing the preload.
• Restore the preload by passing --use-webgpu-adapter=swiftshader, which the narrowing commit names explicitly as a preload condition. Note that MSIX activation discards launch flags, so this has to be set by the app, not by the user.
• Separately, contain the packaging damage: a dying AppX container should not leave the package needing a repair that then fails with ERROR_PACKAGES_IN_USE and tells the user to reinstall.

Two dead ends worth ruling out early. Signing cannot fix it, since requested level 8 is Microsoft product signing and even a genuine Microsoft Store catalogue at level 6 is refused. And --allow-third-party-modules would work but disables the binary-signature mitigation for sandboxed children, which is the wrong trade in a shipping app.

One thing I have not reproduced myself: other reporters state the crash still occurs with isHardwareAccelerationDisabled: true active, since disabling acceleration steers Chromium into the software path where SwiftShader lives. If that holds, the Help menu toggle is not a workaround.

Available on request

• Full CodeIntegrity/Operational export for the crash window, as CSV or XML rather than .evtx.
• Get-ProcessMitigation dumps for the parent and the GPU child, side by side.
• Deployment-log entries covering the failed repair and the subsequent re-stage.
• Package manifest listing showing the absent AppxMetadata folder, plus the signature dump and SHA-256 of the re-staged DLL.
• A redacted slice of the app log covering the crash seconds only.
• A re-test with any flag combination or build you want tried, including the non-MSIX installer, on the same machine.

Confirmed on Windows 10 22H2 build 19045.7548 with Claude Desktop 1.24012.9.0 x64 MSIX.

The issue is second-exact correlated with Windows Code Integrity:

2026-07-29 01:11:26 – Event 3010
Code Integrity was unable to load:
...\AppxMetadata\CodeIntegrity.cat
Status: 0xC000003A

2026-07-29 01:11:26 – Event 3033
claude.exe attempted to load:
...\app\vk_swiftshader.dll
which did not meet the Microsoft signing level requirements.

Immediately afterwards the Claude GPU process crashed with:

reason: crashed
exitCode: 101457950
serviceName: GPU

Get-AppxPackage then changed from:

Ok

to:

Modified, NeedsRemediation

Reproduction on this machine:

1. Fresh uninstall/reinstall.
2. Verify package status is Ok.
3. Start a Cowork session that opens the in-app Browser preview.
4. Within about 30 seconds, the GPU process crashes.
5. Package immediately becomes Modified, NeedsRemediation.

Additional diagnostics:

• Windows 10 22H2 build 19045.7548
• Claude Desktop 1.24012.9.0
• x64
• 16 GB RAM
• DISM /Online /Cleanup-Image /ScanHealth: no component store corruption detected
• Windows Application Hang 1002 / MoAppHang / Quiesce recorded
• Crashpad generated a 35.7 MB minidump at the crash timestamp
• Memory exhaustion was not present; about 5.6 GB RAM remained available

This was reproduced after a clean reinstall and matches the CodeIntegrity.cat / vk_swiftshader.dll failure described here. Full logs and the minidump are available privately because they may contain local paths and environment data.

Independent confirmation, plus a recovery that avoids the reinstall

I hit this on different hardware and can confirm your root cause. More usefully, I found
a recovery that doesn't require reinstalling and doesn't lose session history, which
seems worth having given how many duplicate reports are piling up (map at the bottom).

*Edited after an adversarial review: I had two claims in here that were wrong, and I've
corrected them rather than quietly deleting them. See the "two wrong turns" note in
section 3 and the correction in section 6.*

*Follow-up posted with further evidence: the paired Event 3089 signature data, a
signing-property hypothesis I tested and refuted, the AllowStoreSignedBinaries flag
state, and four more issues for the cluster. See
the follow-up comment.
It supersedes the open question I left at the end of section 3.*

Environment

| | |
|---|---|
| OS | Windows 11 Business, EditionID: Professional |
| Version / build | 25H2, build 26200.8893 (10.0.26200), x64 |
| Latest LCU | KB5121768 (installed 2026-07-19) |
| Claude Desktop | 1.24012.9.0 MSIX, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, X64 |
| Claude Code CLI | 2.1.220 |
| GPU | Intel(R) Arc(TM) Pro Graphics, driver 32.0.101.8517 (2026-04-03) |
| Region / locale | Format and UI culture en-GB; system locale en-US; GeoID 242 (UK); TZ GMT Standard Time (UTC+00:00) |
| VBS / HVCI | VirtualizationBasedSecurityStatus: 2, SecurityServicesRunning: {2,3,4,7}, CodeIntegrityPolicyEnforcementStatus: 2 |
| Smart App Control | Off, so this isn't a user-imposed lockdown |

Comparing this against the other reports rules out three things:

• Not GPU-vendor-specific. I'm on Intel Arc Pro, the same family as your Arc iGPU, but

#80444 is an NVIDIA RTX 2080 and openai/codex#34133
is an RTX 4060 Ti. It spans Intel and NVIDIA, integrated and discrete.

• Not locale-specific. I'm en-GB/UK/UTC+0; #80444 reports de-AT.
• Not tied to one Windows build. 26200 (25H2) here and in this issue, 19045 (Win10 22H2)

in codex#34133, 22000 in the ChatGPT-desktop thread, Win10 22H2 in #82381.

1. Confirming the CIG mechanism

Get-ProcessMitigation against the live Chromium children reproduces your finding:

GPU child   (--type=gpu-process) : BinarySignature.MicrosoftSignedOnly = ON
main browser process             : BinarySignature.MicrosoftSignedOnly = OFF

The raw EventData of the 3033 event is consistent with what CIG would request:

FileNameBuffer    = ...\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
ProcessNameBuffer = ...\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\claude.exe
RequestedPolicy   = 8            # SE_SIGNING_LEVEL_MICROSOFT
ValidatedPolicy   = 1
Status            = 3221226536   # 0xC0000428 STATUS_INVALID_IMAGE_HASH

Those three values are reproduced field-for-field in openai/codex#34133 on different
hardware and a different OS build, so they look stable across environments.

For completeness, the bundled DLL does carry a real signature: Status: Valid,
SignatureType: Authenticode (embedded, not merely package-level), signer
CN="Anthropic, PBC". Worth stating because a public ChatGPT-desktop thread claims the
DLL "only carries package-level signing", which isn't true of this build, so "just sign
it" isn't the fix. Chrome's copy of the same DLL on this machine is CN=Google LLC and
gets rejected identically, so it isn't about who signed it.

2. Your MSIX-vs-non-MSIX conclusion shows up in ambient logs too

Grouping every Event 3033 on this machine by process and blocked file:

Count  Process       Blocked DLL
  108  chrome.exe    vk_swiftshader.dll
  108  chrome.exe    vulkan-1.dll
    2  claude.exe    vk_swiftshader.dll

Chrome absorbed the identical rejection 108 times with no user-visible consequence
because it isn't MSIX. Claude is bricked by 2. That's independent support for
"packaging is the only difference", and I'd argue it makes the escalation (blocked DLL,
then process death, then package flagged as tampered) the highest-value thing to fix,
regardless of what happens with the DLL itself.

3. What is and isn't blocked, and two wrong turns worth avoiding

Inside the same CIG-enabled GPU process, these bundled DLLs load successfully, with no
3033 against them:

| DLL in app\ | SignatureType | Blocked? |
|---|---|---|
| vk_swiftshader.dll | Authenticode (vendor) | yes, twice |
| libGLESv2.dll | Authenticode (vendor) | no |
| libEGL.dll | Authenticode (vendor) | no |
| dxcompiler.dll | Authenticode (vendor) | no |
| d3dcompiler_47.dll | Catalog (Microsoft) | no |
| vulkan-1.dll (this package's copy) | Authenticode (vendor) | never loaded into the GPU process at all, and never observed blocked from this package. The 108 vulkan-1.dll rejections above are Chrome's own copy at Chrome's path. |

So three vendor-signed, in-package DLLs load fine in a process where
MicrosoftSignedOnly = ON, while vk_swiftshader.dll is rejected.

I went down two blind alleys explaining that, and I'm writing both up because each one
looks convincing:

First wrong turn: "so CIG isn't really active." It is. Get-ProcessMitigation
reports MicrosoftSignedOnly = ON for that exact PID. Verify the mitigation directly
instead of inferring it from which DLLs happened to load.

Second wrong turn: "CIG is applied late, so only late loads are blocked." I proposed
that Chromium enables the mitigation after ANGLE initialises, and offered the module
list as proof. Enumerating the GPU process's modules gives, at indices 39 to 51 of 52:

 [39] D3DCompiler_47.dll   PACKAGE   Microsoft Windows
 [40] libglesv2.dll        PACKAGE   "Anthropic, PBC"     vendor-signed, loaded OK
 [41] libegl.dll           PACKAGE   "Anthropic, PBC"     vendor-signed, loaded OK
 [42] dwmapi.dll           System32  Microsoft Windows
 [43] d3d11.dll            System32  Microsoft Windows
 [44] dcomp.dll            System32  Microsoft Windows
 [45] Microsoft.Internal.WarpPal.dll  System32  Microsoft Windows
 [46] OLEAUT32.dll         System32  Microsoft Windows
 [47] D3D10Warp.dll        System32  Microsoft Windows
 [48] dxil.dll             PACKAGE   Microsoft Windows
 [49] dxcompiler.dll       PACKAGE   "Anthropic, PBC"     vendor-signed, loaded OK
 [50] MSCTF.dll            System32  Microsoft Windows
 [51] MFCORE.DLL           System32  Microsoft Windows

dxcompiler.dll is vendor-signed, in-package, and present at index 49 of 52.

I originally wrote that this "refutes" the late-mitigation theory. That was too strong,
for two reasons, and I'd rather flag them than have someone build on a bad inference:

1. Whether a module snapshot is dependable evidence of load chronology is itself

contested. It's commonly said that the enumeration walks the PEB's
InLoadOrderModuleList, but Microsoft doesn't document an ordering guarantee for
EnumProcessModules, so I wouldn't hang an argument on index position alone.

1. Even granting the ordering, a late vendor-signed load is equally consistent with a

different explanation: that CIG doesn't reject in-package DLLs covered by the
package blockmap at all, at any time. That would make timing irrelevant rather than
decisive.

So I'm not claiming ordering is ruled out. What I'd say is only this, which the data does
support: whatever the rule is, it permits at least three vendor-signed in-package DLLs in
this process while rejecting vk_swiftshader.dll, and it rejects it with
STATUS_INVALID_IMAGE_HASH rather than a plain signature-level refusal.

That makes the useful question narrower than "vendor DLLs can't load in the GPU process".
It's: what is different about how this one DLL gets loaded? One direction I can't settle
from outside is whether the Vulkan loader brings the ICD in via a path or LoadLibraryEx
flag combination that skips the package-identity validation the other in-package DLLs
receive. If so, that would also explain why the missing AppxMetadata\CodeIntegrity.cat
you found matters for this DLL and not the others. Someone with loader or Chromium source
access can check that far more cheaply than I can.

4. Recovery without reinstalling, and without losing data

This is the part I most want to contribute, because this issue and the related ones all
prescribe either Repair (which can't work) or Remove-AppxPackage plus reinstall (which
destroys data).

Nothing on disk is actually corrupt. All 2182 files in the install directory keep their
original install timestamps; zero modified. What blocks launch is a flag Windows sets
when it sees the rejected in-package binary:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\<PackageFullName>
  PackageStatus = 2
  BinaryName    = ...\app\vk_swiftshader.dll     <- Windows names the DLL itself

Because it's a flag rather than damage, Repair structurally cannot clear it. Repair is a
re-registration, and the registration was never broken. I ran five consecutive
registration attempts (four via Settings > Repair, one via Add-AppxPackage -Register
-DisableDevelopmentMode -ForceApplicationShutdown). Each logged:

Event 400: Deployment Register operation ... finished successfully
Event 649: ACLs repaired successfully ... Register next time should succeed
Event 617: ... (Clear=0x20, Set=0x0)          <- servicing completed cleanly

while Status stayed Modified, NeedsRemediation throughout. The deployment log reports
success on operations that demonstrably fix nothing, which is its own bug and cost me
hours of misdiagnosis.

Clearing the flag recovers the app, keeps all sessions, and needs no reinstall. Run
elevated, and note the @(...) and the count check: if more than one Claude package is
registered, .PackageFullName returns an array and the path would silently be malformed,
so this refuses to guess.

$pkgs = @(Get-AppxPackage -Name '*Claude*')
if ($pkgs.Count -ne 1) { throw "Expected 1 Claude package, found $($pkgs.Count). Pick one manually." }
$k = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\$($pkgs[0].PackageFullName)"

reg.exe export $k "$env:USERPROFILE\claude-packagestatus-backup.reg" /y   # reversible
Set-ItemProperty -Path "HKLM:\$($k.Substring(5))" -Name PackageStatus -Value 0 -Type DWord

# then REBOOT; Windows caches package status until restart
Get-AppxPackage -Name '*Claude*' | Select-Object Status     # expect: Ok

Applied twice here. The cleared flag survived a reboot and the app has been healthy
since, with all sessions intact.

5. Why "reinstall after each crash" is worse than it sounds

-PreserveApplicationData cannot protect user data on this package. It fails with:

0x80073CFA - "the PreserveApplicationData flag can only be used on a package
              that was deployed in development mode."

Claude's MSIX is a normally signed package, so the flag is rejected outright and there's
no supported data-preserving package replacement. A removal wipes, under
%LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache\Roaming\Claude\:

• claude-code-sessions\, all Code-tab session history
• claude_desktop_config.json, the MCP server configuration
• Claude Extensions\, roughly 12.5k files and 128 MB
• vm_bundles\claudevm.bundle\rootfs.vhdx, the ~8.9 GB Cowork VM image (re-downloads)

The top-level folders survive as empty shells, so "the folder is still there" isn't
evidence the data survived. This cost me 56 Code-tab sessions, recovered only because a
Volume Shadow Copy happened to exist. Anyone following the reinstall-per-crash advice in
this thread should back up claude-code-sessions\ first, and ideally use section 4
instead.

6. Practical notes on the workaround

--disable-gpu tested clean here: launched with it, the GPU process loaded ANGLE
(libglesv2.dll, libegl.dll, d3dcompiler_47.dll), no swiftshader module, and no 3033
fired. Check with:

(Get-Process | Where-Object Path -like '*WindowsApps\Claude_*').Modules |
  Where-Object ModuleName -match 'swiftshader'     # expect: no output

Correction. An earlier version of this comment claimed the flag works because the
software path becomes D3D11 WARP, citing d3d11.dll, Microsoft.Internal.WarpPal.dll
and D3D10Warp.dll in the module list. That was an unsupported inference and I withdraw
it. Those modules sit directly after dwmapi.dll and dcomp.dll, which is a much better
fit for them arriving via OS composition than via Chromium's rasterizer selection, and
Chromium's software rasterizer is SwiftShader in any case. All I can actually claim is
the observation: with --disable-gpu, no swiftshader module was loaded and no 3033 fired.
Why is not established.

This still conflicts with #81840, which reports crashes persisting with hardware
acceleration disabled, and that's worth reconciling. It may mean the in-app toggle and the
command-line flag don't take the same path, but I can't demonstrate that.

I'd expect --disable-software-rasterizer to be more targeted, since
vk_swiftshader.dll is the software rasterizer, but I have not tested it. Offering it as
a hypothesis. Note that Chromium silently ignores unrecognised switches, so a self-check
can't distinguish "the flag worked" from "the flag was a no-op".

Invoke-CommandInDesktopPackage does not work here. The method usually suggested for
passing flags to an MSIX app hung for over 120 seconds and never started the app (no
process, app log untouched). What works is
IApplicationActivationManager::ActivateApplication with AUMID
<PackageFamilyName>!Claude, which returns S_OK and a PID immediately.

One gotcha if you use that: the app starts with no visible window. After S_OK the
process tree is alive and healthy (main, gpu, renderers, utilities; renderer around
365 MB, plugins synced, telemetry flushing) but MainWindowHandle is 0 on every process.
Enumerating top-level windows shows the window does exist, Chrome_WidgetWin_1 titled
Claude with sane 1215x809 geometry, but with IsWindowVisible = False and not
minimised, alongside an Electron_NotifyIconHostWindow. So it starts hidden to tray. A
second activation un-hides it but leaves IsIconic = True, so an explicit
ShowWindow(hwnd, SW_RESTORE) plus SetForegroundWindow is needed to get it on screen.
Worth knowing because "the process is running" reads as success while the user sees
nothing; I initially mis-reported it as working for exactly that reason.

Neither launch method is discoverable by a normal user, and the flags can't be attached
to an ordinary Start-menu or taskbar pin. Windows 11 also blocks programmatic pinning
(the Pin to taskbar verb is absent entirely, and Pin to Start fails with
E_ACCESSDENIED), so a wrapper shortcut can't be installed automatically either. Hence
the request for an in-app "Disable hardware acceleration" toggle.

7. Issue map, since these look like the same defect

Posting here rather than opening another issue, since the tracker already has a lot of
this. Grouped by what each one contributes:

Same mechanism, GPU crash plus package flagged:

• #81341 (this issue). Best evidence: CIG verified, ProcDump stack

ntdll!LdrAppxHandleIntegrityFailure, and the decisive 15/15 MSIX versus 0/15 non-MSIX
experiment. This should be the canonical one.

• #81745. CI blocks vk_swiftshader.dll in the GPU process on first in-app Browser

use; package flagged; app self-terminates. Names itself root cause for #49676.

• #80444. Same 0x060C201E, appxState=2, in-app Browser trigger, same

--disable-gpu workaround. Adds a regression signal: zero GPU crashes on 1.22209.3,
onset immediately after the 1.24012.1 auto-update. Four crashes in about 14 hours.

• #81123. Inline browser preview, GPU crash, Modified/NeedsRemediation.
• #81159. Same exit code, triggered by an in-page browser action.
• #81840. Same exit code but reports it persisting with hardware acceleration

disabled. The one datum that doesn't fit cleanly; see section 6.

Same end-state, mechanism not identified, plausibly this bug seen from above:

• #82381. Repeated NeedsRemediation on Win10 22H2, explicitly "no files modified on

disk", no Windows Update involved. Matches section 4 exactly: a stale flag, not damage.

• #81992. Repeated NeedsRemediation persisting even after a full OS reinstall.
• #81180. Reverts on every launch; CoworkVMService lock.
• #81756. Orphaned cowork-svc.exe locks the package (AppX 0x80073D02). Probably a

distinct fault, a file lock rather than a CI flag, but easily confused with this one.

• #81747. Installer 0x80073CF6, stuck NeedsRemediation after a "successful" install.

Also probably distinct, though it shares the misleading-success-log theme from
section 4.

• #70700. Same end-state attributed to a Windows LCU, currently labelled invalid.

That report is Server 2025, build 26100, KB5094125. I'm on Win11 25H2, build 26200,
a different KB, and I see the identical end-state with no LCU involved, so it may be
worth re-triaging as possibly this bug diagnosed one layer too high.

Not Claude, same rejection in other Chromium apps:

• openai/codex#34133. Identical

RequestedPolicy 8, ValidatedPolicy 1, 0xC0000428 and identical GPU exit code
101457950; relaunch fails with exit 18. Their package stayed Ok.

• OpenAI community thread.

ChatGPT/Codex desktop Store MSIX build, going to Modified, NeedsRemediation and
requiring repair and re-registration. Same MSIX escalation.

• Microsoft Q&A on Dropbox's bundled vulkan-1.dll.

Same 3033, with Microsoft-side responders calling it "likely a false positive". A
different context (not MSIX, not a Chromium GPU child), cited only to show that bundled
Vulkan DLLs commonly trip 3033.

8. What I'd ask for, ranked

1. Don't let a blocked GPU DLL brick the package. Chrome survives this 108 times. A

failed software-rasterizer load should degrade to "no GPU acceleration", not terminate
the app and leave the MSIX flagged as tampered. Highest value, and entirely within
your control.

1. Address the DLL, by whichever route is cheapest: drop MicrosoftSignedOnly on the GPU

process in the MSIX build (as you propose), don't ship the SwiftShader/Vulkan ICD
there, or gate the probe. Re-signing won't help, per section 1. Shipping
AppxMetadata\CodeIntegrity.cat may be worth evaluating, though note that Event 3010
for the missing catalog also fires when the app is working fine, so its absence isn't
sufficient on its own to explain the failure.

1. Self-heal the flag on startup: detect PackageStatus = 2 and clear it, or show a

precise message. Windows' generic Repair text can't fix this and actively pushes users
toward a destructive reinstall.

1. Ship a "Disable hardware acceleration" toggle, since the flag is otherwise unreachable

(section 6).

1. Make user data survivable: a supported data-preserving reinstall, session history kept

outside volatile package-local state, or an export/import. Today the documented
recovery destroys all Code-tab history with no warning (section 5).

1. Fix the misleading deployment logs. Events 400 and 649 report success on operations

that fix nothing (section 4).

1. Investigate the 1.24012 regression flagged in #80444.

---

*All event IDs, HRESULTs, registry values, signature types, mitigation states and module
lists above were observed directly on my machine; nothing is reconstructed from memory.
Where something is inference rather than observation I've tried to mark it, and section 6
records one inference I got wrong and withdrew. Diagnosis and write-up produced with
Claude Code, then adversarially reviewed by three non-Anthropic models, which is what
caught the WARP error. Local paths and identifiers redacted.*

Follow-up: the paired Event 3089 data, a signing hypothesis I tested and had to abandon, and one config flag worth checking

Posting separately rather than editing my earlier comment, because edits send no notifications to anyone subscribed here, and because one part of this is a hypothesis I raised and then killed. That sequence is more useful visible than tidied away.

Everything below was observed on the same machine as my earlier comment (Win11 25H2 build 26200.8893, Claude Desktop 1.24012.9.0 MSIX, Intel Arc Pro).

1. Event 3033 has a paired Event 3089 that nobody has posted yet

Each 3033 rejection is accompanied by Event 3089 carrying per-signature detail. For the rejected DLL, both signatures (TotalSignatureCount = 2) report identically:

Hash                  = 0D3AE9A848F7BD0AA665E09B3AFCF4036AD92E5B693C7084A87A569FC5D28EEE
PageHash              = false
SignatureType         = 1            (embedded)
ValidatedSigningLevel = 1
VerificationError     = 7
KnownRoot             = 1
PolicyBits            = 16
PublisherName         = Anthropic, PBC
IssuerName            = DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
NotValidBefore/After  = 2025-10-14 .. 2026-10-20

KnownRoot = 1 next to ValidatedSigningLevel = 1 is the interesting pair: the certificate chain is trusted, and the binary still validates at the lowest level. I am not interpreting VerificationError = 7 or PolicyBits = 16, since I could not find authoritative definitions for them.

Grouping every 3089 on this machine by publisher and profile:

Count  Publisher              PageHash  ValidatedSigningLevel  VerificationError
  366  <the Chrome vendor>    false     1                      7
    4  Anthropic, PBC         false     1                      7

Chrome's rejected copies produce an identical profile, which independently confirms the rejection does not depend on who signed the file.

Note also that Event 3089 fires only alongside rejections. There is no 3089 for a successful load, so the event log alone cannot compare blocked against allowed DLLs. That mattered, as follows.

2. A page-hash hypothesis, tested and refuted

PageHash = false plus STATUS_INVALID_IMAGE_HASH suggested to me that this load path requires page-hash validation, which an ordinary embedded Authenticode signature cannot supply, and that an MSIX would normally supply them via the AppxMetadata\CodeIntegrity.cat you found missing. That would have tied your catalog observation neatly into the mechanism.

It is wrong, and I want to save anyone else the detour.

Since signtool.exe is not installed here and certutil -dump does not surface the attribute, I parsed the PE security directory directly and searched the Authenticode blob for the page-hash OIDs 1.3.6.1.4.1.311.2.3.1 and 1.3.6.1.4.1.311.2.3.2:

| Binary | Loads in the CIG-enabled GPU process | Page hashes present |
|---|---|---|
| app\vk_swiftshader.dll | rejected | no |
| app\libEGL.dll | loads fine | no |
| app\libGLESv2.dll | loads fine | no |
| app\dxcompiler.dll | loads fine | no |
| app\vulkan-1.dll | not loaded in that process | no |
| Chrome's vk_swiftshader.dll (non-MSIX) | rejected | no |
| d3d11.dll, D3D10Warp.dll, dcomp.dll, ntdll.dll, kernel32.dll | n/a, Microsoft-signed | yes, all five |

The five Microsoft binaries coming back positive are the control that shows the parser works, so the negatives are real rather than a detection failure.

Every binary in the package lacks page hashes, including the three that load successfully in a process where MicrosoftSignedOnly = ON. So missing page hashes cannot be what distinguishes the blocked DLL from its neighbours, and a package-wide missing CodeIntegrity.cat cannot either, for the same reason: it is package-wide, while the failure is not.

There is a useful consequence. The blocked DLL and the DLLs that load are now shown to be indistinguishable in their signature properties: same publisher, same issuer, same signature type, same absence of page hashes. Whatever the discriminator is, it is therefore not a property of the signature. That removes the whole class of signing-based explanations, including my own, and leaves how the DLL is loaded as the remaining candidate. It also means re-signing almost certainly will not fix this.

I am not claiming to know the discriminator. I raised a load-ordering idea earlier and withdrew it as overstated, and I am not reviving it as settled. I would only say it is now the more plausible remaining direction, because the alternative it competed with has been eliminated.

3. AllowStoreSignedBinaries is OFF, and that looks like the actionable knob

Worth pulling out of my earlier comment, because I under-emphasised it. The full mitigation state on the GPU child is:

BinarySignature:
  MicrosoftSignedOnly      : ON
  AllowStoreSignedBinaries : OFF
  Audit                    : OFF
  AuditStoreSigned         : OFF

CIG has a variant that permits Store-signed binaries alongside Microsoft-signed ones. The GPU child is created with the strict form and without the Store allowance, even though every binary it needs to load comes from a signed MSIX package. If the MSIX build created the GPU child with the Store-signed allowance enabled, package binaries would be admissible without weakening the mitigation for anything else. That seems a smaller change than re-signing or restructuring the package, and it is checkable in your sandbox configuration.

I have verified the flag state. I have not verified that flipping it resolves the crash, and I cannot from outside.

4. Event 68 records the flag transitions, and independently corroborates that Repair cannot work

Microsoft-Windows-AppModel-Runtime/Admin Event 68 logs package status changes. Observed on 2026-07-30:

18:41:05  0x2 -> 0x80002 -> 0x2        Repair attempt 1: base returns to 0x2
18:41:07  0x2 -> 0x80002 -> 0x2        Repair attempt 2: base returns to 0x2
18:53:16 / 19:03:33 / 19:14:38         three further attempts, each back to 0x2
19:33:52  0x80002 -> 0x2 -> 0x0        the reinstall: base finally reaches 0x0
19:34:02  0x0 -> 0x80000 -> 0x0        healthy package afterwards, over a 0x0 base
20:34:17  0x2 -> 0x80002 -> 0x2        after the second rejection: 0x2 again

Five remediation attempts each return the base value to 0x2; only the reinstall reaches 0x0. This is a differently-shaped confirmation of what the thread already reports about Repair.

To be precise about what I am and am not saying: 0x80000 behaves as a transient bit in this trace, appearing over both a 0x2 and a 0x0 base and clearing within a second or two. I did not confirm these bit semantics against Microsoft documentation and am not asserting them.

5. Ordering at the failure, with the inference marked

20:34:10.583/.592/.603   Event 3010 x3   (CodeIntegrity.cat missing)
20:34:10.610             Event 3033 + Event 3089 x2   (rejection + signature detail)
20:34:16                 AppX container destroyed
20:34:17/18              Event 68 reports previous status already = 0x2

The flag must have been set to 0x2 between .610 and 20:34:17, because Event 68 at :17 reports it as the previous value. That interval is an inference from the surrounding records; the moment the flag is set is not itself logged, and I am not claiming the ordering proves causation.

Related, and worth flagging because it cuts against a tempting shortcut: Event 3010 for the missing catalog also fired at 20:25:37, nine minutes earlier, while the app was working normally. A missing CodeIntegrity.cat is therefore not sufficient on its own to produce the failure.

6. No crash artefact is produced locally

Verified counts:

WER Report.wer files mentioning the app                  : 0
Application Error / WER events 1000, 1001, 1026 for it   : 0
Files in the per-user CrashDumps directory for it        : 0

The package's own Crashpad\reports\ directory is empty apart from a 0-byte metadata and a 40-byte settings.dat.

I originally read this as "crashpad intercepted and uploaded the crash, so you already have this telemetry server-side". Three reviewers independently told me that is unsupported, and they are right: an empty crashpad directory is equally consistent with nothing ever having been captured. A failed LoadLibrary under CIG can also produce a clean exit rather than a crash, in which case there would be no crash to capture at all. I withdraw that reading.

What stands is the plain observation, and it has two consequences that do not depend on the withdrawn part:

• A user cannot easily produce a dump, which is presumably why this issue needed a manual ProcDump capture. #77768 independently reports "no crash dump" for the same family of crash.
• Monitoring built on Windows Error Reporting will not see this, so incidence is likely under-reported relative to the real rate.

Whether crashpad captured or uploaded anything is something only you can determine.

7. Upstream context: Chromium is removing the SwiftShader fallback anyway

Relevant to the "stop shipping the software rasterizer" option. Chromium has deprecated automatic WebGL fallback to SwiftShader and intends to remove it, explicitly because SwiftShader means JIT-ed code in the GPU process and is treated as a high security risk. A console warning has shipped since Chrome 130, WebGL context creation is intended to fail rather than fall back, and --enable-unsafe-swiftshader exists as the opt-in for anyone who still wants it. See the Intent to Remove: SwiftShader Fallback thread and docs/gpu/swiftshader.md.

So dropping the SwiftShader fallback from the MSIX build is not a workaround against the grain of upstream. It is where upstream is heading, and handling WebGL context-creation failure is the behaviour Chromium is asking embedders to adopt.

8. Further issues that belong in the cluster

Adding to the map in my earlier comment. All still open, none with a maintainer response:

• #80999 "hidden Browser-pane preview kills the app via Code Integrity block on packaged vk_swiftshader.dll, then Repair dialog". Same mechanism, and note hidden pane, so the trigger does not require a visible preview.
• #81398 "opening the in-app Browser pane crashes the GPU process (exit 101457950); app then cannot relaunch until MSIX re-add (reinstall loop)". Same exit code, and describes the reinstall loop directly.
• #77768 "recurring silent GPU-process crash kills entire app during web research (4-5x/day), no recovery, no crash dump". Corroborates section 6 independently, and reports a much higher frequency than my two occurrences.
• #56341 (closed, stale) Cowork spawnLocalProcess failing on enterprise Windows with WDAC kernel-mode enforcement. Different symptom, but the same broad family of code-integrity policy blocking a bundled component, so possibly worth revisiting alongside this.

One correction to the related list in the issue description: electron/electron#51761 looks like a different fault despite the similar symptom. It attributes GPU process init failure to orphaned S-1-15-* "zombie SIDs" in the app folder DACL, reproducible with icacls /grant "*S-1-15-2-999-999-999:...", with --disable-gpu-sandbox as the workaround. No Code Integrity, no signing level, no MSIX packaging involved. Probably worth unlinking to avoid muddying this diagnosis.

9. Three checks that would settle what I could not

1. ~~Enable the verbose Code Integrity channel and capture Event 3089 for a successful in-package DLL load.~~ Struck out: I have now run this, and it does not work. Don't spend time on it. Details below.
2. Check whether the GPU child can be created with the Store-signed-binaries allowance (section 3).
3. Confirm whether AppxMetadata\CodeIntegrity.cat is intentionally omitted from the MSIX, and what your signing pipeline does about page hashes. Section 2 shows page hashes are absent package-wide, so this is about whether the omission is deliberate rather than about explaining the selectivity.

10. Update: the verbose-channel test is a dead end, and that closes the last external avenue

I suggested Microsoft-Windows-CodeIntegrity/Verbose above as the way to get Event 3089 for a successful load. I have since run it, and it cannot answer the question on this build. Correcting that here so nobody repeats it.

It turned out not to need a crash reproduction at all, only a successful load, so a plain --disable-gpu launch was enough. Enable the channel with wevtutil sl ... /e:true /q:true, restart the app, capture, restore the channel.

Result, confirmed both by my harness and by reading the .evtx independently:

Channel total events : 2697
Event ID mix         : 3040 x1348, 3041 x1348, (one ID 0 record)
Event 3089 captured  : 0

The Verbose channel only carries cache-retrieval tracing, with no signature data at all:

Event 3040: "Code Integrity started retrieving the cached data of <file>"
            fields: FileNameLength, FileNameBuffer            (filename only)
Event 3041: "Code Integrity completed retrieval of file cache. Status 0xC0000225"
            fields: Status, CachedFlags, CacheSource, CachedPolicy, State, StateData

No PublisherName, no PageHash, no ValidatedSigningLevel, no VerificationError. The channel does cover the binaries of interest (32 records name the package, including dxcompiler.dll and dxil.dll, both vendor-signed and both loading fine), but without signature fields they can't be compared against the rejected DLL.

So on Windows 11 26200, the signature-level comparison between a rejected and an accepted in-package DLL is not obtainable from Windows event logs at all. Event 3089 exists only as a rejection artefact. Direct PE/Authenticode parsing (section 2) is the only external route, and that is already done: signature properties are identical across blocked and allowed binaries. Anything beyond this needs instrumentation inside the loader or Chromium, which is why item 2 above is now the highest-value remaining check.

Two tooling traps if anyone does try this, both of which bit me:

• Get-WinEvent throws on an analytic/debug channel without -Oldest ("can be read only in the forward chronological order"). My first draft omitted it under -ErrorAction SilentlyContinue, which swallowed the error and would have reported "no events captured", a false negative indistinguishable from a real result. I only caught it by reading the log independently instead of trusting my own harness.
• wevtutil sl /e:true on a Debug channel prompts "Enabling this type of log clears it... [y/n]" and hangs without /q:true.

---

Everything quoted here was read off this machine. Where a claim is inference I have said so, and section 2 and section 6 record two readings I withdrew. Diagnosis produced with Claude Code and then reviewed by three non-Anthropic models, which is what caught the crashpad overclaim and prompted the page-hash test that refuted my own hypothesis. Local paths and identifiers redacted.

Windows 10 data point on "sticky vs recoverable", and a second confirmation of the data loss

Adding to @DrRIH's sections 4 and 5, from the Windows 10 22H2 machine in my earlier comment (build 19045.7548, same package, same 1.24012.9.0).

The StateChange key is absent here, not set to 0

Current state on this machine:

Get-AppxPackage -Name Claude   ->  Status = Ok
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\
  Claude_1.24012.9.0_x64__pzs8sxrjxfjjc   ->  key does not exist

I went through the uninstall/reinstall cycle twice on 7/29, before your recovery method was known. So Remove-AppxPackage plus reinstall appears to discard the key with the registration rather than clear its value.

That is a third outcome next to "sticky" and "recoverable", and it has one practical consequence worth stating: a missing key is not evidence that a machine never hit this bug, so anyone surveying incidence via that key will undercount reinstalled machines.

Second confirmation of the data loss in section 5

Your section 5 holds on Windows 10 too. Under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\:

| | |
|---|---|
| Claude Extensions\ | gone |
| vm_bundles\ | gone |
| claude-code-sessions\ | present, but the oldest surviving entry is dated 2026-07-29 01:01, ten minutes before the crash in my earlier comment. Everything predating the reinstall is gone. |
| claude_desktop_config.json | present, but recreated rather than preserved |

So the reinstall advice in this thread has now demonstrably cost user data on at least two machines, on two different Windows versions. That seems worth weighting alongside the crash itself when this gets triaged.

One correction to my own earlier comment

I led with the Event 3010 / CodeIntegrity.cat correlation. Your section 2 shows page hashes are absent package-wide, including from the in-package DLLs that load fine in the same CIG-enabled process, and your section 5 notes 3010 also fires while the app is healthy. The missing catalogue therefore cannot be the discriminator, and I withdraw that part of the framing.

The 3033 block, the 101457950 / 0x060C201E exit, the Ok -> Modified, NeedsRemediation transition and the second-exact ordering all stand as observations. The catalogue reading does not.

Still reproduces on 1.24012.11.0 (released to my machine 2026-08-04), unchanged.
Adding three things this thread does not have yet: a datapoint that the condition
does not require VBS/HVCI, a workaround that keeps the MSIX build, and a
recovery path lighter than a full reinstall.

1. Confirmation on 1.24012.11.0, with VBS/HVCI and Smart App Control OFF

The original report ran with VBS/HVCI on. This machine has all of it off, and it
still reproduces deterministically — so the failure is not gated on HVCI or Smart
App Control, which widens the affected population.

| | |
|---|---|
| Claude Desktop | 1.24012.11.0 (MSIX), Claude_…_x64__pzs8sxrjxfjjc, SignatureKind = Developer |
| OS | Windows 11 25H2, build 26200.8875 |
| GPU | Intel Iris Xe, driver 32.0.101.7085 |
| HVCI / VBS | not running (Win32_DeviceGuard.SecurityServicesRunning = 0) |
| Smart App Control | off (VerifiedAndReputablePolicyState = 0) |
| Third-party WDAC | none (inbox policies only) |
| AV | Defender only |

Repro: launch normally (no extra flags) → open the in-app Browser → load any
content-heavy page → GPU process dies within ~2 minutes.

11:56:25  Starting app (1.24012.11, no flags)
11:56:52  [Preview] capturePreviewScreenshotIfChanged failed
11:57:40  [Preview] capturePreviewScreenshotIfChanged failed
11:58:20  CodeIntegrity 3010 ×3 — cannot load AppxMetadata\CodeIntegrity.cat, Status 0xC000003A
11:58:20  CodeIntegrity 3033 — claude.exe → app\vk_swiftshader.dll, signing level not met
11:58:21  main.log: GPU process gone { reason: 'crashed', exitCode: 101457950 }   (0x060C201E)

Raw 3033 event data (not posted in the thread so far):

FileNameBuffer  = …\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
ProcessNameBuffer = …\Claude_1.24012.11.0_x64__pzs8sxrjxfjjc\app\claude.exe
RequestedPolicy = 8          (SE_SIGNING_LEVEL_MICROSOFT)
ValidatedPolicy = 1
Status          = 3221226536 (0xC0000428, STATUS_INVALID_IMAGE_HASH)

Both preconditions are unchanged in 1.24012.11.0:

• AppxMetadata\CodeIntegrity.cat is still absent from the installed package

(checked on disk; the 3010 events fire three times per incident).

• The GPU child still runs with MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF

(Get-ProcessMitigation against the live GPU pid).

Package flipped to Modified, NeedsRemediation after the crash, same as reported.

2. Workaround that keeps the MSIX build (no security downgrade)

The thread's current workaround is to switch to the non-MSIX .exe build. For
anyone who has to stay on MSIX, avoiding the DLL load entirely also works:

--use-angle=d3d11
--disable-features=Vulkan,VulkanFromANGLE,WebGPU,WebGPUService,Dawn
--disable-gpu-compositing

Launched through Invoke-CommandInDesktopPackage so package identity, the GPU
sandbox and CIG all stay intact — I verified MicrosoftSignedOnly is still ON
on the GPU child under these flags. No --no-sandbox, no --disable-gpu-sandbox,
no RendererCodeIntegrity change.

A/B on the same machine, same day, same page (Keysight N9010A product page) in the
in-app Browser:

• 09:10 with the flags — pane visible, page refreshed, several successful preview

screenshots: 0 × CI 3033, 0 × GPU process gone, GPU pid unchanged throughout.

• 11:58 without the flags — crash chain above within ~2 minutes.

Two caveats worth knowing:

• It is per-launch, not a persistent setting. Anything that starts the app without

the flags (autostart, tray revive, protocol/deep-link activation) is exposed again.

• An MSIX update silently drops it. After updating 1.24012.9.0 → 1.24012.11.0 the

app relaunched itself ([updater] Version changed since last launch) with no flags,
and ran unprotected until it was manually restarted through the wrapper.

• I did not bisect which individual flag is load-bearing; the Vulkan/WebGPU/Dawn

disables are the ones that should matter.

3. Recovery may not need a full reinstall

Reported here as "only full reinstall recovers". In my case it did not:

• Settings → Repair reported failure. AppX log shows 0x80073D02 —

"cannot install because the following apps need to be closed: Claude…" — i.e. the
Register step (2 of 2) failed only because the app was still running, and the UI
surfaced that as a flat "cannot repair this app".

• Simply launching the app again afterwards brought the package back to Status = Ok

with no Remove-AppxPackage / reinstall.

Worth trying before a reinstall: fully exit the app (including tray), then launch
again, then re-check (Get-AppxPackage -Name Claude).Status.

4. On the suggested fix

SignatureKind on the installed package is Developer, and the GPU child has
AllowStoreSignedBinaries: OFF, so "distribute through the Store to reach Store
signing level" would not help by itself. Shipping the CodeIntegrity.cat catalog,
or not enabling MicrosoftSignedOnly for the GPU process in packaged builds, or
not probing the SwiftShader Vulkan backend at all in MSIX builds, all would.

Independently of the signing question: a blocked DLL load in a fallback graphics
backend should not terminate the whole app and leave the package in
NeedsRemediation. Chrome logs the identical 3033 for its own copy of this DLL and
survives, as the original report notes.

Correction to my earlier workaround, and what 1.24012.11.0 does and does not change

Two things: I have to withdraw a recommendation I made in my earlier comment, and report what I can and cannot establish about 1.24012.11.0. Windows 11 Pro 26200, same machine as before. (Assistant-assisted analysis; local paths and identifiers redacted.)

1. Withdrawing --disable-gpu — my verification method was invalid

I recommended launching with --disable-gpu --disable-software-rasterizer, and said it was verified because inspecting the live gpu-process modules showed no swiftshader module loaded.

That check does not test the flags. On 2026-08-04 this machine ran 1.24012.11.0 with a bare command line — no flags at all — and the live GPU child still showed zero swiftshader/vulkan modules. A flagless launch produces exactly the result I was reading as proof, so the reading distinguishes nothing. Most likely the module list simply reflects that nothing had yet triggered the fallback path that reaches this DLL, but whatever the reason, the check cannot separate "the flags worked" from "the flags did nothing." Every "verified module-clean" statement in my earlier comment should be disregarded.

To be precise about the scope of this retraction: I have not shown that --disable-gpu fails. I have shown that I never tested it. It is unproven, not refuted.

One further reason for caution, which I flag as conditional because I cannot verify the mapping: if Electron's app.disableHardwareAcceleration() results in --disable-gpu being applied — the Electron docs say only "Disables hardware acceleration for current app" and do not document the mechanism — then @relanderolli's measurement above bears directly on my flag, since they observed a GPU child on D3D10Warp.dll with zero nv*.dll that still died with 101457950. On that reading there is also no longer any conflict between my earlier result and #81840; my result was simply not evidence either way.

The flag set posted by @15230745073 above (--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE,WebGPU,WebGPUService,Dawn --disable-gpu-compositing) is better evidenced than mine — it targets the adapter probe rather than the rasterizer, and it is the only workaround in this thread supported by a same-machine, same-page A/B.

The general point, since it caught me: a clean module list at startup is not a test. The only sound check is CI 3033 after the Browser pane has actually loaded a page that exercises WebGPU.

2. 1.24012.11.0 — the read-only preconditions I checked are unchanged

I have not run a trigger test on 1.24012.11.0, so I am not reporting a reproduction. What I can report is that the conditions this thread identifies as necessary are all still present, which needs nobody to risk a crash:

| | 1.24012.9.0 | 1.24012.11.0 |
|---|---|---|
| AppxMetadata\CodeIntegrity.cat | absent | absent — zero .cat files anywhere under the install root |
| app\vk_swiftshader.dll | shipped, Status: Valid, SignatureType: Authenticode, CN="Anthropic, PBC" | shipped, same signer, 5,546,320 bytes, rebuilt 2026-08-03 |
| GPU child mitigation | MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF | identical (Get-ProcessMitigation on the live GPU pid) |
| app\version | 42.7.0 | 42.7.0 |

Two caveats on that table. The DLL carries a fresh build timestamp, so it is not necessarily byte-identical to the 1.24012.9.0 copy — I cannot compare, as the older package is gone from this machine; what I can say is that it is still shipped and still carries a third-party Authenticode signature rather than a Microsoft one. And the mitigation row describes the GPU child of a flagless launch, which is the default configuration users get.

The unchanged app\version is the part I would draw attention to. Per @vkwislacode's analysis above, Chromium's preload of vk_swiftshader.dll ahead of sandbox lockdown was narrowed in March 2026, and on their reading Electron 42.7.0 still carries that narrowing with no restored preload — that research is theirs, not mine. If so, the runtime side is unchanged between these two app versions. Consistent with @15230745073 reproducing the crash on 1.24012.11.0, and with #83744.

3. After the auto-update, the running instance had no launch flags

I want to be careful about what I actually saw here, because it is easy to overstate.

Observed, from main.log and the process list:

09:30:20  [updater] Update downloaded and ready to install { releaseName: 'Claude 1.24012.11' }
09:31:56  [updater-guard] restart deferred; 1 local session(s) still running
09:42:41  [updater] Version changed since last launch: 1.24012.9 -> 1.24012.11
09:42:41  [updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore

and afterwards the running main process had a bare command line — just the executable path, no switches — despite this machine normally starting the app through a wrapper that supplies them.

Not observed: I did not watch the transition, and the log shows the restart was deferred at 09:31:56 rather than forced. So I cannot say what path the process took between those entries, or that the update mechanism itself discarded the flags. Something between the update and 09:42:41 produced a flagless instance; which component did that, and whether a user action was involved, I do not know.

I am reporting it because @15230745073 above describes flags being lost across an update on a different machine, and because the practical consequence holds regardless of mechanism: after an update you may be running unprotected while believing you are not. Anyone relying on a per-launch workaround in this thread may want to check the live command line rather than assume, e.g.

Get-CimInstance Win32_Process -Filter "Name='Claude.exe'" | Select-Object ProcessId, CommandLine

Relatedly, and this one is a design consequence rather than an observation: switches cannot be added to a process that is already running, so restoring a flagged launch requires a full exit including the tray icon, not just reopening the window.

4. Control group, refreshed

Same 14-day CodeIntegrity/Operational window on this machine, exact counts:

282  chrome.exe   vulkan-1.dll
280  chrome.exe   vk_swiftshader.dll
  2  claude.exe   vk_swiftshader.dll

562 blocks against Chrome, no crashes. 2 against Claude, both fatal, both flipping the package to Modified, NeedsRemediation. The refusal is routine; the escalation is the defect. This matches the ratios @vkwislacode (275/276 vs 2) and @relanderolli reported on different machines and different Windows versions.

5. Updated issue map

The cluster has roughly doubled since I posted the last map, and the newer reports are almost entirely uncross-linked.

Same signature, filed since 2026-07-28:

• #83130 — independently derives the same chain, and adds a trigger detail I have not seen elsewhere: Cloudflare Turnstile appears to call WebGPU only intermittently, which would account for the widespread "same page crashes sometimes, loads fine other times" reports. Currently links to nothing.
• #83744 — 1.24012.11.0, current version
• #83473 — Repair fails and the reinstall hits 0x80073CF6; argues Store remediation cannot service a developer-signed package by design
• #83318, #83028, #81947, #82967, #81933, #83478, #83549, #83117 — same signature, varying detail

Auto-update interaction, which section 3 makes me think is worth looking at alongside this:

• #82134 — auto-update during a hang corrupts registration
• #81875 — auto-update removes the app outright

Previously mapped: #81745, #81123, #81840, #82381, #81992, #81180, #81756, #81747, #80999, #81398, #77768, #56341.

#77768 is the only issue in the cluster carrying triage labels (platform:windows, area:desktop), so it may be a better canonical target than this one.

Listed only so they stop being swept in — these look like different faults: #82227 (large transcript render), #83403 (usage-limit), #83453 (Linux), #82073 (Cowork VM HCS).

The bisect: of the seven components in the current workaround, only --disable-features=WebGPUService is load-bearing

@15230745073's 2026-08-04 comment gave the MSIX-preserving flag set and said plainly "I did not bisect which individual flag is load-bearing." This is that bisect, plus a confirmation against the app itself and a recovery that needs neither a reinstall nor a reboot.

Environment: Windows 11 Pro 10.0.26200 · Claude Desktop MSIX 1.24012.11.0 → 1.25927.0.0 (both tested, both crash) · Electron 42.7.0 · Chrome 151.0.7922.48 used as a safe control.

---

1. Only one of the seven components does anything

The workaround is three switches, but seven independently-removable components:
--disable-features= Vulkan, VulkanFromANGLE, WebGPU, WebGPUService, Dawn (five), plus
--use-angle=d3d11 and --disable-gpu-compositing. All seven were bisected.

An 18-arm design — baseline, full set, leave-one-out over each component, then each component alone. Leave-one-out identifies what is necessary; singles identify what is sufficient. 20 requestAdapter({forceFallbackAdapter:true}) calls per arm. Run entirely in Chrome, which takes this identical Code Integrity block routinely and survives it, so the whole matrix costs zero package risk.

Two independent full runs agreed on all 18 arms. Event counts were perfectly bimodal — always exactly 4, or exactly 0.

| Arm | CI 3033 | Verdict |
|---|---|---|
| baseline (no flags) | 4 | fires — positive control |
| full set (all seven) | 0 | protects |
| features only (no --use-angle, no --disable-gpu-compositing) | 0 | protects |
| leave-one-out minus Vulkan | 0 | still protects |
| leave-one-out minus VulkanFromANGLE | 0 | still protects |
| leave-one-out minus WebGPU | 0 | still protects |
| leave-one-out minus WebGPUService | 4 | protection collapses |
| leave-one-out minus Dawn | 0 | still protects |
| leave-one-out minus --use-angle=d3d11 | 0 | still protects |
| leave-one-out minus --disable-gpu-compositing | 0 | still protects |
| single: Vulkan | 4 | no |
| single: VulkanFromANGLE | 4 | no |
| single: WebGPU | 4 | no |
| single: WebGPUService | 0 | sufficient alone |
| single: Dawn | 4 | no |
| single: --use-angle=d3d11 | 4 | no |
| single: --disable-gpu-compositing | 4 | no |
| single: --disable-gpu | 4 | does not protect |

So the working flag set reduces to:

--disable-features=WebGPUService

--use-angle=d3d11 and --disable-gpu-compositing are inert here. This also independently reproduces two negatives already reported in #81745 — --disable-gpu and --disable-features=WebGPU,Vulkan --use-angle=d3d11 both fail to prevent the load.

--disable-gpu not protecting is worth dwelling on. It has been recommended and withdrawn in this cluster more than once, and it is the flag people assume the in-app hardware-acceleration toggle maps to (#81840). If that mapping holds, the toggle will not help either.

2. It is not the API being removed — the request simply never reaches the ICD

Captured from the page's own console:

| Arm | 3033 | navigator.gpu | calls | adapters |
|---|---|---|---|---|
| baseline | 4 | YES | 20 | 0 |
| --disable-features=WebGPUService | 0 | YES | 20 | 0 |
| --disable-features=WebGPU | 4 | YES | 20 | 0 |

The protective arm still exposes navigator.gpu and still calls requestAdapter twenty times. It doesn't work by amputating WebGPU — it stops the request reaching the SwiftShader ICD.

Note also that --disable-features=WebGPU does not even remove navigator.gpu in Chrome 151, which is probably why disabling the renderer-facing feature name has disappointed people. The service side is what gates the ICD load.

3. A single confirmation against the MSIX app — sandbox intact

This part is n=1 per arm. The bisect above is Chrome, replicated; what follows is one
protected run against one flagless control on the same version. Treat it as a confirmation
that the Chrome result transfers, not as an independent measurement.

Same version, same stimulus (open a WebGPU page in the in-app Browser pane), nine minutes apart:

| | flagless | --disable-features=WebGPUService |
|---|---|---|
| [Preview] Created session preview context | yes, 11:31:46 | yes, 11:39:30 |
| CI 3033 | 1 — vk_swiftshader.dll | 0 |
| GPU process | died | alive |
| Package | Modified, NeedsRemediation | Ok |
| GPU child MicrosoftSignedOnly | ON | ON |

The preview context — the event that preceded the crash by two seconds without the flag — was reached and nothing followed. Chrome's canary fired 4 × 3033 in the same window, so the machine was still blocking the DLL; the app simply stopped asking for it.

The mitigation stays on. This matters against #81745's finding that --disable-gpu-sandbox is the operative flag there — that author notes it "costs the GPU process sandbox." One switch on the feature list achieves the same outcome here with CIG untouched. (I did not test --disable-gpu-sandbox or --disable-software-rasterizer, so I am not claiming their result is wrong — only that a sandbox-preserving option exists.)

4. Recovery: one reversible DWORD, no reinstall, no reboot

This edits HKLM, so read it before you run it. It needs an elevated PowerShell, it
refuses unless the package is actually in the fault state, and it will not write unless the
backup export succeeded first.

#requires -RunAsAdministrator
# Recovers a Claude Desktop MSIX package stuck in "Modified, NeedsRemediation".
# Run in an ELEVATED PowerShell, with Claude Desktop fully exited (including the tray icon).

$pkgs = @(Get-AppxPackage -Name 'Claude' -Publisher 'CN="Anthropic, PBC"*')
if ($pkgs.Count -ne 1) { throw "Expected exactly 1 Claude package, found $($pkgs.Count). Stopping." }
$pkg = $pkgs[0]

# Refuse if the app is still running - the container must be free.
$live = @(Get-Process -Name claude -ErrorAction SilentlyContinue |
          Where-Object { $_.Path -like '*WindowsApps\Claude_*' })
if ($live.Count) { throw "$($live.Count) package process(es) still running. Exit the app first." }

$key    = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\$($pkg.PackageFullName)"
$regCmd = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\$($pkg.PackageFullName)"
if (-not (Test-Path $key)) { throw "No StateChange key for $($pkg.PackageFullName) - nothing to clear." }

$before = (Get-ItemProperty $key).PackageStatus
Write-Host "Status=$($pkg.Status)  PackageStatus=$before"

# GUARD: only touch a package that is actually broken. A non-zero PackageStatus does not by
# itself mean trouble - I observed 0x200000 while Get-AppxPackage still reported Ok.
if ($pkg.Status -eq 'Ok') { Write-Host 'Package is Ok. Nothing to do.'; return }
if ($before -eq 0)        { Write-Host 'PackageStatus already 0 - this is a different fault.'; return }

# Export FIRST, and abort if the export did not produce a file.
$bak = Join-Path $env:USERPROFILE ("claude-pkgstatus-backup-{0}.reg" -f (Get-Date -Format 'yyyyMMdd-HHmmss'))
& reg.exe export $regCmd "$bak" /y | Out-Null
if (-not (Test-Path $bak)) { throw 'Registry export failed - refusing to modify anything.' }
Write-Host "Backup: $bak   (double-click it to undo)"

Set-ItemProperty -Path $key -Name PackageStatus -Value 0 -Type DWord
Write-Host "PackageStatus $before -> $((Get-ItemProperty $key).PackageStatus)"
Write-Host "Status now: $((Get-AppxPackage -Name 'Claude').Status)"

Then relaunch. Worked twice on this machine, on two different package versions, neither
time needing a restart. This contradicts the "a reboot does not reliably help — only a Repair that re-downloads and re-adds the MSIX clears it" position in #83130, and my own earlier statement in this thread that the reboot was mandatory. Export the key first; double-clicking the .reg undoes it.

Do not use the Repair button Windows offers. It does not clear the tamper bit.

Two related observations:

• Recovery by full-exit-and-relaunch alone failed here — ActivateApplication threw 0x80073CFC with zero package processes live. Others report it working, so this varies by machine.
• The registry value tracks a bitmask: I observed 0x200000 present while the package still reported Ok. Only the low bit (0x2) accompanies the flip.

5. This is not a corrupt install

Reproduced on 1.24012.11.0 and 1.25927.0.0, same machine, three hours apart. The update changed nothing relevant: vk_swiftshader.dll is byte-identical in size (5,546,320), still Authenticode-signed CN="Anthropic, PBC" rather than at Microsoft level, still no CodeIntegrity.cat anywhere in the package, still Electron 42.7.0.

A fresh package from the official updater crashes identically. Advice in this cluster to reinstall is treating a symptom, and it costs users their local session history — -PreserveApplicationData fails 0x80073CFA on a store-signed package, so there is no data-preserving reinstall.

6. How to pass the flag at all (for #83028)

#83028 reports being unable to launch with flags because Windows blocks direct .exe invocation under WindowsApps. The MSIX declares no uap3:AppExecutionAlias, so arguments must go through COM IApplicationActivationManager::ActivateApplication (CLSID 45BA127D-10A8-46EA-8AB7-56EA9078943C) — as #81745 also notes. Invoke-CommandInDesktopPackage hangs indefinitely here and is not a usable substitute.

Whatever the fix, please expose this as a setting. A COM activation call is not a reasonable ask of an affected user.

---

Related reports

This cluster is heavily fragmented; these all appear to be the same defect or its direct consequences:

Core crash: #80444 · #80689 · #80978 · #80999 · #81123 · #81159 · #81275 · #81398 · #81578 · #81698 · #81745 · #81749 · #81840 · #81933 · #82967 · #83028 · #83117 · #83130 · #83478 · #83744 · #83835 · #83941 · #77768

Package wedged / recovery / data loss: #69987 · #81180 · #81306 · #81747 · #81756 · #81875 · #81947 · #81992 · #82134 · #82381 · #83318 · #83473 · #83893 · #83932

Two worth singling out:

• #83941 attributes the crash to a failed preview-screenshot capture. My logs corroborate the timing — [Preview] capturePreviewScreenshotIfChanged failed appears alongside both crashes — and add the missing link: the CI 3033 fires in the same window. The screenshot failure and the ICD block look like the same event seen from two layers.
• #83835 reports the identical exit code across NVIDIA and Intel adapters over four months, which is the strongest available argument that this is app-side rather than driver-specific.

Limits of this data

• The app-side confirmation is n=1 per arm. The Chrome bisect is n=2 across all 18 arms.
• No hit rate was measured. Flagless crashed on both attempts, but neither was a repeat of an identical stimulus, so that is 2-for-2, not a rate. The intermittency reported in #83130 (2 of 5 visits) is not contradicted.
• Chrome is 151.x; the app embeds Chromium 148. The bisect is strong evidence for the app, not proof — hence the separate in-app confirmation.
• One machine, one GPU (the cluster spans Intel Iris Xe, NVIDIA, and hybrid).
• Only probe level forceFallbackAdapter was bisected. The WebRTC + WebGPU path some reports describe was not.
• I did not test --disable-gpu-sandbox, --disable-software-rasterizer, or the in-app hardware-acceleration toggle.

Suggested fix, in preference order

1. Ship a CodeIntegrity.cat in the package so the bundled ICD passes CIG. The package currently contains zero .cat files.
2. Don't let a blocked ICD be fatal — Chrome takes this identical block hundreds of times on this machine without crashing. The defect is the escalation, not the block.
3. Expose a supported setting for the flag, so recovery doesn't require COM activation.
4. Guard the preview-screenshot path per #83941.

Follow-up: --disable-gpu-sandbox turns Code Integrity Guard off on the GPU process — plus independent confirmation of --use-angle=gl, and a scope correction to my own comment above

Three things, one of which affects a workaround people are already running.

---

1. Measured: what each workaround does to the GPU process mitigation

Four arms, same trigger (requestAdapter({forceFallbackAdapter:true}) × 20), each in its own
browser process with a fresh profile. MicrosoftSignedOnly read directly off that arm's own
GPU child by PID; 3033 events attributed by Execution ProcessID so a co-running browser
cannot contaminate the count.

| Arm | GPU pid | MicrosoftSignedOnly | CI 3033 | page STATS |
|---|---|---|---|---|
| baseline, no flags | 41668 | ON | 4 | calls=20 adapters=0 null=20 |
| --disable-features=WebGPUService | 42088 | ON | 0 | calls=20 adapters=0 null=20 |
| --use-angle=gl | 40660 | ON | 0 | calls=20 adapters=0 null=20 |
| --disable-gpu-sandbox | 37660 | OFF | 0 | calls=20 adapters=0 null=20 |

The measurement: --disable-gpu-sandbox leaves the GPU process running without the
Microsoft-signed-only binary signature policy. The other two silence the 3033 with the
mitigation still enforced. A live GPU pid was read in every row, so OFF is a real read, not
a failed one.

**What I am not claiming. I first wrote that it "lets the load succeed because nothing is
checking any more." That is not supported and I have removed it: adapters=0 on that arm too,
exactly as on the protected arms. If the ICD were loading successfully I would expect an
adapter. So the mechanism is not established** — CIG being off may be incidental to whatever
else changing the sandbox does to GPU process startup. What stands is the security-relevant
fact: this flag disables a process mitigation, and the other two do not.

That is worth knowing regardless of mechanism. #81745 flagged that it "costs the GPU process
sandbox"; this quantifies which specific protection is lost.

Check it on your own running instance:

$gpu = Get-CimInstance Win32_Process -Filter "Name='claude.exe'" |
       Where-Object { $_.CommandLine -match '--type=gpu-process' } | Select-Object -First 1
(Get-ProcessMitigation -Id $gpu.ProcessId).BinarySignature |
  Format-List MicrosoftSignedOnly, AllowStoreSignedBinaries

2. --use-angle=gl independently confirmed; --use-angle=d3d9 did not reproduce

@nobrainermedia reported in #81275 that --use-angle=gl survives the trigger that kills every
D3D backend on Intel Arc. It reproduces here too (row 3 above): 0 × 3033, CIG still ON.

But be careful how much weight that carries — and I nearly overstated it. Their machine is
Intel Arc integrated (drivers 32.0.101.8724 / 8860); mine is Intel Arc Pro, driver
32.0.101.8517. Same vendor, same GPU family. This is a same-family replication on a
different driver version and a different trigger, not the cross-vendor confirmation I first
wrote it up as. It still moves --use-angle=gl from one machine to two, and the triggers
differ, which is worth something — but someone on NVIDIA or AMD reproducing it would be worth
considerably more.

--use-angle=d3d9, reported working in #80444, did not protect here: 4 × 3033, identical
to baseline. I want to be careful with that. #80444's trigger was ordinary web search on a
Cloudflare-protected page; mine is an explicit forced fallback-adapter request. A flag that
steers the WebGL/compositing backend could matter for one and not the other. This is a
non-reproduction on a different stimulus, not a refutation.

3. Scope correction to my earlier comment

My bisect covered one trigger: requestAdapter({forceFallbackAdapter:true}). That was in
the limits, but the headline read broader than the evidence.

Established: for a forced fallback-adapter request, WebGPUService is the only one of the
seven components that matters. It also holds on the WebRTC + WebGPU path — 2 clean runs,
calls=20 adapters=0, 0 × 3033, against a same-session baseline control that fired 4.
*(Disclosure: the first attempt at that arm came back VOID — it did not get its own browser
process, so its flags were never applied. It is recorded as VOID in the sweep CSV and was
re-run twice; only the re-runs are cited here.)*

Not established: that it covers the triggers most people actually hit — Cloudflare
Turnstile (#80689, #81275), WebGL capability probes (#81275), MediaPipe tasks-vision (#83318),
or a failed preview-screenshot capture (#83941).

4. Hypothesis, not a finding: why reports may be so inconsistent

On this machine, which has working hardware WebGPU:

| Trigger | CI 3033 | adapters returned |
|---|---|---|
| plain requestAdapter() | 0 | 20 (real hardware adapters) |
| powerPreference:'low-power' | 0 | 20 |
| forceFallbackAdapter:true | 4 | 0 |
| WebRTC + forceFallbackAdapter | 4 | 0 |

*(Rows 1, 2 and 4 are from the trigger sweep; row 3 is the baseline arm of the mitigation
table in section 1. All four are 20 reps, PID-attributed, each in its own browser process.)*

Ordinary WebGPU use never touches SwiftShader here — a hardware adapter is returned and the ICD
is never consulted. The blocked load required something to ask for a fallback adapter.

The speculative part, offered as a hypothesis to test rather than a result: if a machine has
no hardware WebGPU adapter available, or it is blocklisted, then a plain requestAdapter()
would fall back on its own and no page would need to do anything unusual. That would predict
easier reproduction on integrated-Intel-only (#83028, "no workaround") and on hybrid laptops
running on the iGPU (#81578 identifies iGPU-only compositing as the failing configuration).
I have not tested this — I have no hardware that lacks WebGPU.

And one data point already cuts against the simple version of it. @nobrainermedia's machine
is Intel Arc, like mine, and crashes on ordinary content; mine has working hardware WebGPU and
needs an explicitly forced fallback. Same GPU family, different behaviour — so adapter
availability alone cannot be the whole discriminator. Driver version (8517 here vs
8724/8860 there) and page content are both still in play.

Cheap check for anyone affected: open chrome://gpu in the app's Browser pane and look at
whether WebGPU reports a hardware adapter. If it does not, and the hypothesis holds, you should
reproduce far more readily than I can.

Credit I skipped earlier

• #83130 identified the discriminator behind "Repair works" vs "Repair does nothing" —

whether the Register step can actually run, matching 0x80073D02.

• #81947 found the step that makes re-registration succeed:

Stop-Service CoworkVMService -Force before Add-AppxPackage -Register.

• #81840 appears settled by three independent reports (#80444, #80689, #81840): the in-app

hardware-acceleration toggle does not map to --disable-gpu — the GPU child runs
--use-angle=d3d11-warp-webgl, loads D3D10Warp.dll, and dies anyway.

Method and limits

Chrome 151.0.7922.48, Windows 11 Pro 10.0.26200, Intel Arc Pro Graphics, driver
32.0.101.8517 (no discrete GPU), 20 reps/arm, one arm per browser process, fresh profile
each, events attributed by PID.

• Chrome, not the Electron app. The app is Chromium 148; these arms are 151.
• n=1 per arm for the mitigation table and the trigger sweep. The L5 WebGPUService result

here is n=2 plus a control. The seven-component bisect in my earlier comment was one
PID-attributed 18-arm run plus an earlier unattributed 18-arm run that agreed on every arm —
the second predates the attribution fix, so it is corroboration rather than a second
independent measurement.

• The WebGL-only arm is uninterpretable — my probe does not emit its stats line on that

path, so I cannot show the WebGL code ran at all. Not evidence in either direction.

• Mechanism for --disable-gpu-sandbox is unexplained, as above.
• One machine, one GPU, and one that has working hardware WebGPU — which per section 4 is

probably why my trigger has to be synthetic in the first place.

The two tests I most want from someone else

1. --disable-features=WebGPUService against a real content trigger — a Turnstile page,

#81275's reproducing site, or #83318's MediaPipe page. My probe is synthetic and that is the
weakest link in the chain.

1. --use-angle=gl vs --disable-features=WebGPUService head-to-head, one machine, one

trigger, both directions. Two workarounds, two mechanisms, no comparison yet.

Confirmed on a second, very different machine: Windows 10 Pro 19045 + AMD Radeon integrated graphics (so not Win11/Intel-Arc/VBS-specific). Claude Desktop MSIX 1.26832.0. 9/9 browser-preview crashes since Jul 25, all with exit_code=101457950 (0x060C201E). At the exact second of each crash, CodeIntegrity/Operational logs the same pair: Event 3033 (claude.exe attempted to load app\vk_swiftshader.dll 'did not meet the Microsoft signing level requirements') + Event 3010 x2 (AppxMetadata\CodeIntegrity.cat unable to load, 0xC000003A - the file is absent from the package, verified on disk). vk_swiftshader.dll Authenticode: Valid, CN='Anthropic, PBC' - not Microsoft level. On this machine the app hangs rather than self-terminating, which then cascades into the updater uninstalling the package (0x80070020 -> RemoveForAllUsers) - detailed in #81875, which appears to share this root cause. Two AMD driver versions (31.0.21924.61, 31.0.21925.1001) behave identically, consistent with the packaging diagnosis.

Workaround confirmed on the second machine as well (Win10 19045 + AMD Radeon iGPU, reported above): replaced the MSIX install with the non-MSIX build ('Claude Setup.exe --exe', v1.26832.0). Browser preview now opens and renders with no GPU-process death and no new CodeIntegrity 3033 - previously 10/10 previews were fatal on this machine (last MSIX crash 22:56, exe build installed 22:57, preview verified working minutes later). Also closes the loop on #81875: with no MSIX package to flip to NeedsRemediation, the uninstall/reinstall treadmill is gone.

Confirming the CIG + missing-catalog diagnosis on 1.26832.0.0 (Windows 11 10.0.26200, Intel iGPU, Smart App Control off, HVCI on). Same 3010 0xC000003A / 3033 pair, same outcome.

Four things I didn't find in this thread or #83130 — all small, but each cost me hours, so posting in case it saves someone else the detour.

1. The installed package is byte-identical while Windows calls it Modified.

I verified every file in the install against the signed AppxBlockMap.xml (per-block SHA-256, the same blocks the signature covers):

BlockMap declares : 2257 files
On disk           : 2259 files   (the 2 extra are AppxBlockMap.xml + AppxSignature.p7x)
content-modified  : 0
missing           : 0
size mismatch     : 0

So Modified, NeedsRemediation is a false tamper verdict derived entirely from the CI failure — nothing on disk is actually altered. Worth establishing before anyone burns time hunting for corruption, a bad download, or AV interference.

2. Windows names the offending binary in the package-status key — and patching that key is futile.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc contains:

PackageStatus : 2
BinaryName    : ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
BinaryHash    : {69, 248, 139, 152...}

That's a direct, machine-readable causal link from the 3033 block to the Modified flag — useful for triage/telemetry, since (as #83130 notes) Crashpad produces nothing.

Setting PackageStatus back to 0 reports success but does not hold: Microsoft-Windows-AppModel-Runtime shows the status flapping 0x2 ↔ 0x80002 on every subsequent activation attempt. It is re-derived, not stored. Not a workaround.

3. --disable-software-rasterizer does not prevent the load.

Tested with the argument confirmed delivered to the process. The app still died in ~20 s, PackageStatus went 0 → 2 again, and a fresh 3033 was logged. The flag governs the SwiftShader rasterizer fallback; the load here comes from Vulkan ICD enumeration via the packaged app\vk_swiftshader_icd.json, which that flag doesn't gate. (--disable-gpu / --in-process-gpu target the right layer, but I have not verified them.)

4. Caution for anyone taking the non-MSIX / portable workaround recommended above.

Remove-AppxPackage on the MSIX deregisters the manifest-declared uap3:Protocol Name="claude", and that deletes the entire HKCU\Software\Classes\claude ProgID — including the registration a non-MSIX or portable install had already made for itself, because both live at the same key.

Result: claude:// deep links and OAuth callbacks fail silently after you uninstall the MSIX. Nothing errors; the callback just never arrives.

Fix is to re-create the ProgID pointing at the non-MSIX executable:

$exe  = '<path>\claude.exe'
$root = 'HKCU:\Software\Classes\claude'
New-Item -Path "$root\shell\open\command" -Force | Out-Null
Set-ItemProperty -LiteralPath $root -Name '(default)'    -Value 'URL:Claude Protocol'
Set-ItemProperty -LiteralPath $root -Name 'URL Protocol' -Value ''
Set-ItemProperty -LiteralPath "$root\shell\open\command" -Name '(default)' -Value ('"' + $exe + '" "%1"')

Suggest verifying claude:// still resolves after any Claude package removal.

I can independently reproduce what appears to be the same issue on current Claude Desktop 1.26832.0.0 on Windows x64.
A reinstall temporarily restores the package to Status: Ok, but during normal Claude Code/Desktop use it transitions live to:
Modified, NeedsRemediation
I monitored the transition in PowerShell:
12:05:41 | STATUS=Ok | VERSION=1.26832.0.0 | CLAUDE_PROCESSES=12
12:06:42 | STATUS=Modified, NeedsRemediation | VERSION=1.26832.0.0 | CLAUDE_PROCESSES=2
Five seconds before the package status changed, Windows CodeIntegrity/Operational logged:
Event 3010 x3: unable to load
...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
with status 0xC000003A
Event 3033: claude.exe attempted to load
...\app\vk_swiftshader.dll
which did not meet Microsoft signing-level requirements.
After reinstall, while the package is still Status: Ok, I confirmed:
AppxMetadata = False
CodeIntegrity.cat = False
AppxSignature.p7x = True
AppxBlockMap.xml = True
vk_swiftshader.dll = True
So the missing AppxMetadata/CodeIntegrity.cat is present before the failure state occurs, rather than being deleted during corruption.
I also captured the reproduction with Sysinternals Process Monitor. I did not observe a write/delete/rename operation against the Claude package that would explain the transition; the failure coincides with the GPU process accessing vk_swiftshader.dll / Windows Code Integrity validation rather than another process visibly modifying the MSIX contents.
Windows Defender showed no threat detection or remediation events during the failure window.
Windows Settings → Repair fails with “We couldn't repair this app”. Re-running the Claude installer over the existing installation restores it in ~20 seconds and preserves chat/context data, but the failure subsequently recurs.
This therefore looks consistent with #81341 / #80999 rather than conventional package-file corruption, and confirms the issue still reproduces on 1.26832.0.0.

Two additions: a datapoint on 1.28929.0.0, and a positive control that is still
inside MSIX — every control in this thread so far leaves MSIX (Chrome, the --exe
build), which leaves open the question of whether this is fixable without doing that.

1. Unchanged on 1.28929.0.0

Same machine as my 2026-08-04 comment
(Windows 11 25H2 26200.8875, Intel Iris Xe, HVCI not running, Smart App Control off).
Claude Desktop 1.28929.0.0, MSIX, SignatureKind = Developer. All three checkable
links in the chain are unchanged:

| Link | Check | Result |
|---|---|---|
| CIG on the GPU child | Get-ProcessMitigation -Id <gpu pid> | MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF |
| App ships mitigating defaults? | search app\resources\app.asar (40 MB) | zero occurrences of disable-features or use-angle |
| Catalog present? | AppxMetadata\CodeIntegrity.cat | still absent on disk |

To be explicit about what this is not: I did not re-run the destructive no-flag
reproduction on this version — I did that on 1.24012.11.0 (reported above) and it
costs a NeedsRemediation package each time. Three unchanged links is strong evidence,
not proof.

2. A positive control that stays inside MSIX

OpenAI.Codex 26.803.10989.0 is on this same machine: also Electron, also MSIX, and it
ships the same DLL. Side by side:

| | Claude Desktop 1.28929.0.0 | OpenAI.Codex 26.803.10989.0 |
|---|---|---|
| app\vk_swiftshader.dll | present | also present |
| AppxMetadata\CodeIntegrity.cat | absent | present |
| SignatureKind | Developer | Store |

Two things follow.

Shipping the catalog is sufficient, and it does not require dropping the DLL or
leaving MSIX. A sibling Electron MSIX app on the same Windows install, under the same
CI policy, with the same vendor-supplied SwiftShader ICD, does not hit this — because
the package carries a CodeIntegrity catalog, so the DLL satisfies the GPU process's
signing-level requirement. That makes "ship AppxMetadata\CodeIntegrity.cat" (already
suggested in the original report) the smallest fix that keeps MSIX, keeps CIG enforced
on the GPU process, and needs no Chromium flag changes.

Corollary worth stating, because it is easy to get backwards: the continued presence
of vk_swiftshader.dll in a build says nothing about whether this is fixed. Codex still
ships it. I had been using "DLL still in the package" as a cheap staleness check for new
Claude builds and had to discard that — the catalog is the discriminator, not the DLL.

For anyone reproducing the comparison:

foreach ($n in 'Claude','OpenAI.Codex') {
  $p = Get-AppxPackage -Name $n
  [pscustomobject]@{
    Package = "$n $($p.Version)"
    SignatureKind = $p.SignatureKind
    Swiftshader = Test-Path (Join-Path $p.InstallLocation 'app\vk_swiftshader.dll')
    CiCatalog   = Test-Path (Join-Path $p.InstallLocation 'AppxMetadata\CodeIntegrity.cat')
  }
}

Confirmed on 1.28929.0 (current Store/MSIX build) — the CIG kill described in the OP is still present, and CodeIntegrity events are second-exact with both crashes on this machine. Adding one new datapoint: a lighter, MSIX-compatible mitigation that has held so far.

Environment: Windows 11 26100 (10.0.26100.8972), i5-12500 / UHD Graphics 770 only (no dGPU), Intel driver 32.0.101.7088 (newest Intel offers as of 2026-08), 3440×1440 @ 100 Hz, 16 GB RAM, Defender only.

Crash ↔ preview ↔ CodeIntegrity timeline (2/2 crashes)

main.log:

2026-08-12 22:09:14 [PreviewContext] Opened preview user tab (tab-2)
2026-08-12 22:10:14 GPU process gone: { type:'GPU', reason:'crashed', exitCode: 101457950 }   # +60 s

2026-08-13 02:29:56 [Preview] Created browser preview
2026-08-13 02:30:08 GPU process gone: { type:'GPU', reason:'crashed', exitCode: 101457950 }   # +12 s

Microsoft-Windows-CodeIntegrity/Operational, second-exact with both:

2026-08-12 22:10:13  Event 3033 + 3010 ×3 + 3089 ×2
2026-08-13 02:30:08  Event 3033 + 3010 ×3 + 3089 ×2

3033: claude.exe (...\WindowsApps\Claude_1.28929.0.0_x64__pzs8sxrjxfjjc\app\claude.exe)
      attempted to load ...\app\vk_swiftshader.dll that did not meet the
      Microsoft signing level requirements.
3010: unable to load ...\AppxMetadata\CodeIntegrity.cat — Status 0xC000003A

Control group reproduced here too: Chrome 151 on the same machine logs the identical 3033 for its own vk_swiftshader.dll every ~5 minutes and never dies — non-MSIX, exactly as the OP describes.

Consistent with the OP's analysis

• No Crashpad dump (Crashpad\reports empty) and no WER entry — loader-level kill, not a normal exception.
• No TDR (no Event 4101/4102); 2.2–2.5 GB physical RAM free at both crash moments (not OOM); driver already the newest available.
• Aftermath variant here: the Electron main process lingered as a zombie; the next MSIX register attempt failed with 0x80073D02 until leftovers were killed, then recovered after "ACLs repaired" (did not reach NeedsRemediation on this machine).

Mitigation datapoint (MSIX-compatible, no reinstall)

Toggling off the preview feature "hardware acceleration for the built-in browser" relaunches the GPU process with --use-angle=d3d11-warp-webgl. WebGL then goes through inbox D3D11 WARP (Microsoft-signed) instead of the Vulkan/SwiftShader fallback, so CIG never sees vk_swiftshader.dll:

• Since the toggle (~2026-08-13 04:14): zero claude.exe 3033 events, zero GPU crashes; preview warmup has run clean.
• Observation window is still short; will report back if it recurs. May be useful for users who need to stay on the Store/MSIX build and can't switch to the --exe installer.

Same signature also reported in #85967, #86248, #85424, #83744, #81840 — may help triage/dedup.

Independent confirmation of the root cause on a second machine — with to-the-second Code Integrity log correlation, a deterministic trigger (Google Sign-In pages), and a verified step-by-step workaround using the official installer's undocumented --exe switch.

Environment

• Windows 11 Home 10.0.26200 (25H2), desktop RTX 5080 (driver 32.0.16.1088 / 580.88), Intel Core Ultra 9 285K, Parsec Virtual Display Adapter present (ruled out — see below)
• Claude Desktop MSIX (Claude_..._pzs8sxrjxfjjc, SignatureKind=Developer — installed from claude.ai download, not the Store)
• 10 documented crashes, always: GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } (= 0x060C201E), whole app dies within the same second, package flagged NeedsRemediation → RepairPackageOperation in AppXDeploymentServer log ~30-60 s after each crash. No WER, no Event Log Application entries, empty Crashpad.

1. Code Integrity events correlate with every crash to the second

Four crashes on 2026-08-13 at 15:34:21, 16:04:19, 17:43:15, 17:49:50 (local). Microsoft-Windows-CodeIntegrity/Operational has, at exactly those timestamps, Event 3033:

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

each accompanied by 3× Event 3010:

Code Integrity was unable to load the \...\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.

Verified on the live GPU child process (Get-ProcessMitigation): MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF. vk_swiftshader.dll Authenticode signer is "Anthropic, PBC" (valid, but not a Microsoft signing level), and AppxMetadata\CodeIntegrity.cat does not exist in the package — still missing in 1.30096.1.0 MSIX as of 2026-08-13. This independently confirms the OP's WinDbg analysis (ntdll!LdrAppxHandleIntegrityFailure) and #85901.

2. New datapoint: deterministic trigger — Google Sign-In / anti-bot GPU fingerprinting

Every crash was triggered by a page running GPU fingerprinting (Google botguard / GSI One Tap / Cloudflare Turnstile). Renderer console sequence, identical each time, ~1 s before death:

[GSI_LOGGER] ... One Tap / FedCM ...
Provider's accounts list is empty.
[GSI_LOGGER]: FedCM get() rejects with NetworkError: Error retrieving a token.
WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat   (×~20)
The powerPreference option is currently ignored when calling requestAdapter() on Windows. (crbug.com/369219127)
A valid external Instance reference no longer exists.                     (Dawn/WebGPU)
WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
→ main.log: GPU process gone { reason: 'crashed', exitCode: 101457950 }

Notes: it also crashed on a plain google.com/search results page (botguard probes there too), so this is not OAuth-specific — the WebGL/WebGPU probe burst is what makes the GPU process attempt the SwiftShader load. This matches #85145 (Google OAuth), #80520 (Supabase login), #86146/#80444 (Turnstile). FedCM itself is not the mechanism — just a marker of the login path.

Regression timeline on this machine: zero crashes through July (1.22209.x → 1.24012.9, heavy daily use); first crash ever 2026-08-03 23:40, ~3.5 h after auto-update 1.24012.9 → 1.24012.11; persisted through 1.26832.0 and 1.28929.0. NVIDIA driver updated mid-crash-cluster (changed nothing), Windows CU came later, Parsec VDD unchanged since April, and DLL-injection was ruled out (module enumeration across all 15 Claude processes: no third-party DLLs). Consistent with OP: disabling hardware acceleration does not help (#80689, #86265) because the failure is the DLL load in the GPU process, not rendering itself.

3. Verified workaround: official bootstrapper's --exe switch (Squirrel build)

The public installer (claude.ai/api/desktop/win32/x64/setup/latest/redirect → Claude Setup.exe, ~7 MB Go bootstrapper) defaults to MSIX, which is why "reinstall from the website" never fixes this. But its strings reveal supported switches: --exe, --msix, --msix-path, --all-users, --uninstall ("ERROR: --exe and --msix cannot both be specified", "Offering Squirrel fallback", "User chose Squirrel fallback").

"Claude Setup.exe" --exe

installs the classic Squirrel build to %LOCALAPPDATA%\AnthropicClaude\ (it removed the MSIX registration itself; all user data survived — %APPDATA%\Claude and ~/.claude are shared between builds, no re-login needed).

Result: same CIG policy on the Squirrel build's GPU process (MicrosoftSignedOnly: ON), then opened the page that previously killed the app 100% of the time (app.base44.com/register): full GSI/FedCM sequence appeared in the console — GPU process survived, no crash, no new 3033 events, app fully functional. MSIX: 10/10 fatal on this machine; Squirrel: 0 so far. Confirms OP's 15/15 vs 0/15.

Ask

Ship a valid AppxMetadata\CodeIntegrity.cat (or a Microsoft-signed/store-signed SwiftShader, or drop the MicrosoftSignedOnly mitigation on the GPU process in MSIX), and until then please document --exe — this bug destroys the MSIX package on every occurrence (NeedsRemediation → Repair loop) and has repeatedly corrupted users' local session indexes.

(Separate issue seen alongside, not the crash cause: TypeError: Cannot destructure property 'preloadScripts' of 'binding.startupData' as it is null in sandboxed renderers — that's an Electron ≥42.3.3 regression from electron/electron#51602 / #51831 affecting sandboxed child WebContentsViews/popups, tracked in #79846; it never kills a process.)

Additional evidence: Claude Desktop 1.30096.5 MSIX pure startup crash + clean A/B test

Title
Claude Desktop 1.30096.5 MSIX crashes on startup due to Code Integrity rejection of vk_swiftshader.dll (Event 3033/3010); official Squirrel build of the exact same version works on the identical machine

Environment

• Claude Desktop: 1.30096.5.0 (MSIX)
• PackageFullName: Claude_1.30096.5.0_x64__pzs8sxrjxfjjc
• Install path: C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc
• Same machine used for A/B test
• VBS running, HVCI / Memory Integrity not running
• No IFEO or Exploit Protection entries targeting claude.exe

Symptoms
After successful MSIX installation, Claude Desktop launches and crashes within a few seconds.
Package status becomes Modified, NeedsRemediation. Reinstall does not fix it.

Code Integrity evidence

• Event ID 3033:

claude.exe attempted to load
...\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

• Event ID 3010:

Code Integrity was unable to load
...\AppxMetadata\CodeIntegrity.cat
Status: 0xC000003A

• The entire AppxMetadata directory does not exist (Test-Path and Get-ChildItem both confirm this).

• vk_swiftshader.dll itself has a valid Authenticode signature:
• Signer: Anthropic, PBC
• Issuer: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
• Status: Valid

(This is distinct from satisfying the required Microsoft Code Integrity signing level.)

Key A/B test (same machine, same version)

| Build | Result |
|-------|--------|
| MSIX (1.30096.5) | Crashes within seconds (3033 + 3010) → Modified, NeedsRemediation |
| Squirrel / EXE (Claude Setup.exe --exe, same version 1.30096.5) | Launches successfully and remains stable (multiple Claude processes stay alive) |

• Same PC, same Windows installation, same Claude version, same GPU/drivers, same user account.
• Only difference is packaging: MSIX vs official Squirrel/EXE.
• After installing the Squirrel build, the broken MSIX package was automatically removed (Get-AppxPackage Claude returns nothing).

This forms a very clean isolation: the problem is MSIX-specific (Code Integrity / packaging), not application code, GPU drivers, or general system configuration.

Additional note
Chrome on the same machine also generates Event 3033 for its own vk_swiftshader.dll / vulkan-1.dll, but does not crash.

Workaround
Install the official Squirrel/EXE build using:
Claude Setup.exe --exe

Suspected area
The evidence strongly suggests an MSIX-specific Code Integrity / packaging compatibility issue (missing AppxMetadata\CodeIntegrity.cat + vendor-signed vk_swiftshader.dll under Microsoft signing level requirements).

This report adds a pure startup reproduction on the latest build (1.30096.5) with a rigorous same-machine A/B test, complementing the existing findings in this thread.

Independent confirmation on a different GPU vendor and on current builds — same root cause, same second-exact Code Integrity signature. Adding the data points that were not in the thread yet.

Environment: Windows 11 Pro 26200, desktop i9-9900K, NVIDIA GeForce GTX 1080 (drivers 560.94 and 582.66 both affected) + Intel UHD 630 iGPU; Claude Desktop MSIX Claude_<ver>_x64__pzs8sxrjxfjjc, every version from 1.24012.9 through 1.30096.5 (2026-08-17) still affected. Package folder has no AppxMetadata at all; app\vk_swiftshader.dll is intact (all 85 blocks match AppxBlockMap.xml, Authenticode valid, Anthropic PBC).

Kills: 11 on this machine since 2026-07-31 (8 spontaneous, 3 deliberate reproductions today), each taking down every running Claude Code session and subagent. main.log shows the same GPU process gone: { reason: 'crashed', exitCode: 101457950 } (= 0x060C201E), then nothing until manual relaunch.

Trigger: the in-app Browser pane loading a page that runs a Cloudflare challenge / Turnstile widget (an "Just a moment…" interstitial on a third-party site, our own sites' Turnstile forms). Those pages probe WebGPU including the fallback adapter, so Dawn loads SwiftShader. Isolated navigator.gpu.requestAdapter() / requestDevice() on the hardware adapter and WebGL contexts do not crash the pane; the challenge page does, 4/4 today. Renderer log at the crash second: powerPreference option is currently ignored when calling requestAdapter() ×2 → A valid external Instance reference no longer exists → WebGL: CONTEXT_LOST_WEBGL.

Not the GPU / not the driver: reproduced with the Intel iGPU disabled in Device Manager (NVIDIA-only), identical crash. Zero TDR / driver-reset events in the System log at any crash time.

GPU child (procdump -e -t attached to --type=gpu-process), 2026-08-17 18:19:52: two first-chance E06D7363 _com_error, then unhandled 0x060C201E raised in ntdll!LdrAppxHandleIntegrityFailure, called under LdrLoadDll ← KERNELBASE!LoadLibraryExA with the path …\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll on the stack, below dxgi.dll frames. Same second, Microsoft-Windows-CodeIntegrity/Operational:

3033 Error   Code Integrity determined that a process (...\app\claude.exe) attempted to load ...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
3010 Warning Code Integrity was unable to load the ...\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.   (×3)

Every crash inside the CI log's retention window (2026-08-09, 08-10, 08-17 ×4) has the 3033 event at the same second.

Browser process: procdump on the main process caught it dying with 0xC000001D (illegal instruction, i.e. a CHECK/FATAL) at claude.exe+0x6dd36fa (1.30096.5) about one second after the GPU child died — consistent with "GPU process isn't usable. Goodbye." The window closes on its own; leftover session child processes then make the Settings "Reset/Repair" fail until killed.

Happy to share the GPU-child and browser-process dumps privately if useful. Moving to the non-MSIX build as the workaround, per the thread.

Same failure on Windows 11 26200 with a discrete NVIDIA GPU (RTX 4070 Ti SUPER, driver 32.0.15.9649), MSIX build 1.30096.5.0, SignatureKind: Developer. Adding four things this thread doesn't have yet, including a working command-line mitigation for people who can't switch to the --exe build.

1. The CIG block itself is benign — a same-machine control proves it

I decoded the raw event fields rather than reading the message text. Event 3033 carries:

RequestedPolicy  = 8          (SE_SIGNING_LEVEL_MICROSOFT)
ValidatedPolicy  = 1
Status           = 3221226536 (0xC0000428, STATUS_INVALID_IMAGE_HASH)

and the paired 3089 shows CI read the certificate perfectly well — PublisherName = Anthropic, PBC, IssuerName = DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, KnownRoot = 1, validity 2025-10-14 → 2026-10-20, VerificationError = 7.

So this is not a broken signature. RequestedPolicy = 8 means the loader was asked for Microsoft signing level. No vendor Authenticode certificate can ever satisfy that — re-signing vk_swiftshader.dll, or shipping the missing AppxMetadata\CodeIntegrity.cat, cannot fix this, because the requested level is Microsoft, not Store.

The control that settles it: on this same machine, Google Chrome (non-MSIX, C:\Program Files\Google\Chrome\Application\chrome.exe) produces 569 identical 3033 blocks with zero crashes. Full breakdown of every 3033 event in my log:

| Count | Blocked file | Requesting process | RequestedPolicy |
|---|---|---|---|
| 285 | vulkan-1.dll | chrome.exe | 8 |
| 284 | vk_swiftshader.dll | chrome.exe | 8 |
| 5 | vk_swiftshader.dll | claude.exe (MSIX) | 8 |
| 1 | vulkan-1.dll | claude.exe (MSIX) | 8 |

Chrome: 569 blocks, 0 crashes. Claude Desktop: 6 blocks, 6 crashes — 1:1, every single one.

This matches the ntdll!LdrAppxHandleIntegrityFailure frame already identified in this issue: the block is routine and non-fatal outside an MSIX container, and fatal inside one. The bug is the MSIX loader's integrity-failure escalation path, not the DLL.

2. Renaming vk_swiftshader.dll does not work — it just moves which DLL it dies on

The widely shared workaround (renaming vk_swiftshader.dll and vk_swiftshader_icd.json to .off) did not stop the crashes here. With both files renamed, the next crash blocked vulkan-1.dll instead, same RequestedPolicy = 8, same exitCode: 101457950. Chromium simply falls one step further down the same fallback chain and dies at the next non-Microsoft-signed DLL.

3. Windows actively reverts the rename — it isn't auto-update that undoes it

Several reports here assume a staged update restores the DLL. That's not what happens. Renaming files inside C:\Program Files\WindowsApps\... flips the package to Status: Modified, NeedsRemediation, and Windows' own MSIX remediation restores the original filenames, unprompted, with no update involved.

I verified the restored file is a genuine copy, not a re-download artifact — the remediated vk_swiftshader.dll and my renamed .off copy are byte-identical:

837ED0FD403148C9DB7804C55F0699AD37143DE6B541DE1EA700A1665FB9F553  vk_swiftshader.dll
837ED0FD403148C9DB7804C55F0699AD37143DE6B541DE1EA700A1665FB9F553  vk_swiftshader.dll.off

This is also, I think, the mechanism behind the "forces MSIX repair cycles" symptom in #85540 and the "orphaned processes block MSIX re-activation" symptom in #87388: the rename workaround puts the package into a permanent modify/remediate loop. Anyone who applied it should undo it — it costs package integrity and buys nothing.

4. Working mitigation without leaving MSIX: launch with GPU switches

If Chromium never attempts those loads, CI has nothing to block and the fatal path is unreachable. Launching the packaged executable directly accepts command-line switches and — importantly — keeps full package identity:

--use-angle=d3d11
--disable-features=Vulkan
--disable-software-rasterizer

Verified the switches reach the GPU process (--type=gpu-process --use-angle=d3d11 ... --disable-features=...,Vulkan) and that MSIX identity and data virtualization are intact, so settings and history are not split to a second location:

[MSIX] Package family from native API: Claude_pzs8sxrjxfjjc
[updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore
[MSIX] Filesystem virtualization active — ...\LocalCache\Roaming\Claude exists

The package ships no AppExecutionAlias, so a shortcut has to target the executable inside the package directory. Resolving it at launch time via Get-AppxPackage keeps it working across version updates:

$pkg = Get-AppxPackage -Name 'Claude' | Select-Object -First 1
Start-Process -FilePath (Join-Path $pkg.InstallLocation 'app\Claude.exe') -ArgumentList @(
    '--use-angle=d3d11'
    '--disable-features=Vulkan'
    '--disable-software-rasterizer'
)

Stable here so far. This is a mitigation, not a fix — the underlying issue is that a blocked DLL load kills the entire application.

Suggested fixes, in order of preference

1. Don't let a blocked module load be fatal. Chrome demonstrates on the same machine that the correct response is to mark the backend unavailable and continue on D3D11. Whatever escalates through LdrAppxHandleIntegrityFailure inside the MSIX container needs to be caught.
2. Don't probe backends that can never load under CIG. In an MSIX/CIG build, vulkan-1.dll and vk_swiftshader.dll are unreachable by construction, on every machine. Compiling those switches in for packaged builds removes the whole failure class.
3. At minimum, don't take the whole app down with the GPU process. Losing every open session to a GPU child crash is the part that actually hurts, independent of this root cause.

Re-signing the DLL and shipping CodeIntegrity.cat are both dead ends — worth saying explicitly, because the missing catalog (event 3010, 0xC000003A) looks like the cause and isn't. Chrome has no MSIX package at all and hits the identical block.

Follow-up on the command-line mitigation from @aPipixia123456 — it was not sufficient for the Cloudflare-challenge trigger, but an extended switch set is. Same machine as my comment above, now on MSIX 1.32352.0.0 (auto-updated tonight; still no AppxMetadata).

Three switches alone → still fatal. Launched app\Claude.exe --use-angle=d3d11 --disable-features=Vulkan --disable-software-rasterizer (verified on the GPU child's command line: --use-angle=d3d11 --disable-features=...,Vulkan), opened a page behind a Cloudflare "Just a moment…" challenge in the Browser pane → within 4 s: CI Event 3033 for app\vk_swiftshader.dll (same RequestedPolicy path), GPU process gone: exitCode 101457950, app dead. Reason: that trigger calls navigator.gpu.requestAdapter() and asks for the fallback adapter, so Dawn loads SwiftShader on its own path — --disable-features=Vulkan / --disable-software-rasterizer cover Skia/ANGLE Vulkan and the WebGL software fallback, not the WebGPU fallback adapter. Triggers that only probe WebGL (Google Sign-In in the comment above) never reach it, which is why the three switches held there.

Adding the WebGPU switches → survives. Launched with

--use-angle=d3d11 --disable-features=Vulkan,WebGPUService --disable-blink-features=WebGPU --disable-software-rasterizer

(renderers get --disable-blink-features=WebGPU, the GPU child gets --disable-features=...,Vulkan,WebGPUService). In the pane navigator.gpu still exists but requestAdapter() returns null in ~1 ms; the same Cloudflare page then logs Failed to create WebGPU Context Provider ×2, no CI 3033, GPU process stays alive, the challenge even passes and the site renders. Deterministic on this machine: 5/5 fatal with the original trigger before, 0/1 with the extended set (will report if that changes). MSIX identity, Cowork and user data untouched.

Practical shape (resolves the package path at launch, survives updates):

$pkg = Get-AppxPackage -Name 'Claude' | Select-Object -First 1
Start-Process (Join-Path $pkg.InstallLocation 'app\Claude.exe') -ArgumentList '--use-angle=d3d11','--disable-features=Vulkan,WebGPUService','--disable-blink-features=WebGPU','--disable-software-rasterizer'

Caveat: this removes WebGPU from the in-app browser entirely, and every launch has to go through this command (a Start-menu launch has no switches). Still a mitigation; the fix remains "a blocked DLL load must not take the app down".

1.32885.1.0: a trigger outside the Browser pane, and a same-machine CIG observation

Fourth occurrence on this machine (Windows 11 Pro 26200). Three things worth adding: the trigger surface may be wider than the Browser pane, one observation about what CIG does and does not block here, and a set of newer reports carrying this symptom without this mechanism.

1. This occurrence did not involve the Browser pane

#87052 reproduces this crash through the Browser pane, using the preview_start tool explicitly. This occurrence appears not to have.

What I can show: no Browser-pane server was recorded as running. The last [Launch] Updating active servers store line anywhere in the log before the crash is 2026-08-14 14:45, reading count: 0, five days earlier. The Turnstile widget rendered in the app's own main window during Claude's authentication challenge:

16:22:53  Turnstile iframe detected. Removing error overlay.
16:22:54  Blocked permission check { permission: 'media',
            requestingOrigin: 'https://challenges.cloudflare.com/',
            topFrameUrl: 'https://claude.ai/api/challenge_redirect?to=https%3A%2F%2Fclaude.ai%2Fchat%2F...' }
16:22:57  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

Four seconds from iframe to dead GPU, matching the "1 to 4 seconds after navigation" window in #87052.

Two caveats, so nobody over-reads this. A second app instance launched inside that same four seconds (Starting app / Not main instance, returning early / second-instance: suppressing duplicate argv), and it is most likely what drove the navigation — I cannot show it was irrelevant. And a [WarmLifecycle:preview] Warming up session line appears at 09:16 the same morning, seven hours earlier, so I can say no preview server was recorded active, not that no preview machinery existed in the process. Someone with a cleaner reproduction should confirm before this is treated as established.

If it does hold, a fix scoped only to the preview pane would not cover it.

2. A CIG-enforcing GPU child on this machine did load a vk_swiftshader.dll

Three copies of vk_swiftshader.dll exist on this machine. CodeIntegrity 3033 counts, last 30 days:

| Origin | Bytes | Authenticode signer | 3033 |
|---|---|---|---|
| Chrome 151.0.7922.169 | 5,457,560 | CN=Google LLC | 461 |
| Claude 1.32885.1.0 (MSIX) | 5,546,832 | CN="Anthropic, PBC" | 5 (each fatal) |
| Edge 151.0.4129.78 | 4,723,528 | CN=Microsoft Corporation | 0 |

These browsers see very different usage on this machine, so the counts are not a controlled comparison — the zero is not by itself evidence. The controlled part is this: on 2026-08-05 I ran the same probe (requestAdapter({forceFallbackAdapter:true}) ×20) in Edge with a fresh --user-data-dir, attributing events by Execution ProcessID. The Edge GPU child had MicrosoftSignedOnly = ON, vk_swiftshader.dll appeared in its loaded modules, and zero 3033 were attributed to that run.

So the block is not unconditional under CIG: a GPU child with MicrosoftSignedOnly enforcing did load a file of this name on this machine.

What I cannot claim is that the signer is the reason. The Edge binary differs from the packaged one in build, package context and policy as well as certificate, so signer is not isolated from those. One thing is still worth saying: Chrome's Google-signed copy is rejected here too, and that signature is valid and current — so "use a more reputable signer" is not on its own the answer.

What this does not show. Edge returned adapters=0, null=20 — no working adapter was obtained on any of the 20 calls, so this is evidence about the load being permitted, not about a functioning software-WebGPU path. The three files are different builds, not one binary with three certificates: the byte sizes differ and Edge 151 is not Chromium 148. It is n=1, one machine, and Edge has since moved from 151.0.4129.59 to .78. Someone able to test a Microsoft-signed and a third-party-signed build of the same Chromium revision would settle what this cannot.

The package still ships zero .cat files and has no AppxMetadata directory on 1.32885.1.0. Shipping a CodeIntegrity.cat is the mechanism intended for exactly this case, and looks like the most direct thing to try.

Not a user workaround — swapping Edge's copy into the package is itself the tamper trigger, the install root is TrustedInstaller-owned, and the ABI pairing is unsupported. The user-side mitigation remains --disable-features=WebGPUService, which keeps CIG enforced.

3. This occurrence, for the record

App auto-updated 1.32352.1 → 1.32885.1 at 00:53; the instance running at crash time carried no mitigation switches. Signature identical to this issue: exit 101457950, CodeIntegrity 3033 on app\vk_swiftshader.dll at 16:22:57, registry PackageStatus = 2 with BinaryName = …\app\vk_swiftshader.dll, package Modified, NeedsRemediation.

Windows then ran two Register operations of its own (AppXDeploymentServer/Operational event 400 at 16:23:03 and 16:24:01, each preceded by 649 ACLs repaired successfully). Both reported success; the package was still Modified, NeedsRemediation afterwards. On this machine, setting PackageStatus = 0 returned Status: Ok immediately and the app launched — no reboot needed, which is the first time I have confirmed that here.

4. Newer reports that may belong here

None of these mention vk_swiftshader in the body — they carry the symptom without the mechanism documented in this thread, which may be why they keep being filed separately:

Same crash signature (101457950 and/or Turnstile in the body): #87052 (has repro), #85424, #81698, #81836, #80306

Possibly a different route to the same end state — these reach Modified, NeedsRemediation around Cowork/update activity rather than a GPU crash, and 5 of 6 carry the area:cowork label: #87610, #87969, #86530, #87097, #53247, #84851. I classified these from labels and body text rather than reading each in full, so treat it as a hint for triage, not a finding.

Authored by AI (Claude - Opus 5 w. ultracode-thinking), approved by me - a human :)

---

Independent confirmation of the CIG / vk_swiftshader.dll diagnosis — 13 crashes, 13 matching Code Integrity events, 1:1

I've been tracking this crash on a separate machine since 2026-07-27 and reporting it on #81275,
where I had it filed as a GPU/WebGL problem. This issue's diagnosis is correct and mine was
wrong. Here is the verification, plus a control that I think closes it.

13 crashes ↔ 13 CodeIntegrity 3033 events, same second, no exceptions

Every GPU process gone … exitCode 101457950 on this machine has a Code Integrity 3033 at the
same second — and the retained log contains exactly 13 of them for claude.exe. No 3033
without a crash; no crash without a 3033.

Code Integrity determined that a process (…\Claude_<ver>_x64__pzs8sxrjxfjjc\app\claude.exe)
attempted to load …\app\vk_swiftshader.dll that did not meet the Microsoft signing level
requirements.                                                            [Event ID 3033]

Code Integrity was unable to load the …\AppxMetadata\CodeIntegrity.cat catalog.
Status 0xC000003A.                                                       [Event ID 3010]

| crash (main*.log) | CI 3033 | | crash | CI 3033 |
|---|---|---|---|---|
| 2026-07-27 16:23:08 | 16:23:08 | | 2026-08-07 16:55:50 | 16:55:49 |
| 2026-07-27 16:29:09 | 16:29:09 | | 2026-08-13 20:09:04 | 20:09:04 |
| 2026-07-27 17:06:05 | 17:06:05 | | 2026-08-14 19:53:09 | 19:53:09 |
| 2026-08-05 12:42:58 | 12:42:58 | | 2026-08-15 13:55:03 | 13:55:03 |
| 2026-08-05 12:52:08 | 12:52:08 | | 2026-08-18 19:30:14 | 19:30:13 |
| 2026-08-07 16:31:16 | 16:31:15 | | 2026-08-19 21:25:35 | 21:25:35 |
| 2026-08-07 16:35:13 | 16:35:13 | | | |

On this machine: vk_swiftshader.dll is 5,546,832 bytes, Authenticode Valid, signer
CN="Anthropic, PBC" … OID.2.5.4.15=Private Organization. AppxMetadata\CodeIntegrity.cat is
absent — the entire AppxMetadata directory is absent from the package.

⭐ Control: non-MSIX Chrome hits the identical block and does not die

On the same machine, same GPU and driver, Google Chrome 151.0.7922.138 (non-MSIX) logged the
same 3033 against its own vk_swiftshader.dll — and kept running.

⇒ The signing block is generic Chromium-under-CIG behaviour. It is fatal only inside the
MSIX container. That makes this a packaging/signing defect, not a GPU, driver or Chromium bug
— and it means no GPU-side change can fix it.

Why there is no crash dump — this is important for triage

I spent weeks reporting "no minidump, no WER entry, Crashpad\reports empty, 13/13" as a mystery.
Under this diagnosis it isn't one: **the process is killed at DLL load time, so there is no
fault and no exception to capture. Anthropic has no crash telemetry for this by construction**
— which likely explains why an issue with this many duplicates has gone unacknowledged.

Nine builds of evidence that no renderer-side change helps

Same deterministic repro, every build, ~30–35 s from page load to whole-app death:

https://www.printables.com/model/81725-motorized-ikea-snudda-turntable

| build | result | notable |
|---|---|---|
| 1.24012.9 → 1.30096.5 (6 builds) | ⛔ | Electron 42.7.0, ANGLE 2.1.27535 throughout |
| 1.32352.1 | ⛔ | Electron → 42.9.2, ANGLE → 2.1.27552 — no effect |
| 1.32885.1 | ⛔ | app.asar down to 28.86 MB from 38.2 (~25% of the bundle) — no effect |

Consistent with the diagnosis: neither the graphics stack nor app code is where the fault lives.

GPU process switches here, in case they're useful — note there is no --use-angle or --use-gl:

--gpu-preferences=SAAAAAAAAADgAAAEAAAAAAAAAAAAAGAAAQAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAQAAAAAAAAABAAAAAAAAAACAAAAAAAAAAIAAAAAAAAAA==
--enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,IsolatesPriorityUseProcessPriority,PdfUseShowSaveFilePicker
--disable-features=DropInputEventsWhilePaintHolding,LocalNetworkAccessChecks,NetworkServiceSandbox,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TraceSiteInstanceGetProcessCreation

Retracting a red herring I published

On #81275 I reported that every crash was preceded by exactly 19
getInternalformatParameter WebGL warnings, and treated that invariant as the strongest lead.
It is a symptom of the page's capability probing, not the fault — and it stopped appearing
entirely from 1.28929.0 onward while the crash continued unchanged. Anyone triaging on that
signature will find nothing on current builds and may wrongly conclude the bug is gone.

The ask

Ship an AppxMetadata\CodeIntegrity.cat covering vk_swiftshader.dll, or drop/replace the
vendor-signed binary. That is a build-packaging change rather than a code change, and it should
be verifiable against the public repro above in under a minute.

Repro is deterministic here and I have logs for all 13 crashes — happy to run anything specific.

Independent corroboration: a Microsoft-signed vk_swiftshader.dll loads where the Google-signed one is blocked, same browser, same policy

This is corroboration, not a new diagnosis. @aPipixia123456 already established the substance from the raw event fields — RequestedPolicy = 8 is the Microsoft signing level, so no vendor Authenticode certificate can satisfy it. That argument stands on its own and does not need an experiment. What follows is an empirical check of it from the other direction, plus a same-host control that removes a variable my own earlier comment could not.

Earlier in this thread I reported that Edge's Microsoft-signed vk_swiftshader.dll loads under an enforcing CIG while Chrome's Google-signed copy is blocked, and I had to concede the obvious objection: three different files from three different products, so the signer was never isolated from the build.

This is a tighter version of that experiment. It holds the host, the CIG policy, the machine and the probe constant, and swaps the DLL. It does not hold the binary constant — the two files are different builds (5,457,560 vs 4,723,528 bytes), so signature is still not isolated from build. What it removes is the cross-product variable: one browser, one policy, one machine.

Method. Replace Chrome's own vk_swiftshader.dll with Edge's, run the same WebGPU probe (requestAdapter({forceFallbackAdapter:true}) ×20) in Chrome, restore, repeat. CodeIntegrity 3033 events attributed by System/Execution/@ProcessID to that arm's own pids — never a bare count, since ordinary browsing generates ~15 chrome 3033 events a day on this machine. Windows 11 Pro 26200, Chrome 151.0.7922.169, Edge 151.0.4129.78.

| Arm | vk_swiftshader.dll in Chrome's directory | 3033 | swiftshader module in the GPU child |
|---|---|---|---|
| A0 baseline | Chrome's own — CN=Google LLC | 4 | not loaded |
| A1 test | Edge's — CN=Microsoft Corporation | 0 | loaded |
| A2 restore-control | original restored, SHA-256 verified | 4 | not loaded |

Zero foreign events, zero suspect arms, Chrome version identical across all three, final restore hash-verified. This is one run per arm (n=1), and the underlying trigger is intermittent — so read the table as a single consistent observation, not as a measured rate.

The module column is the part that matters. A silent 3033 on its own would be ambiguous — Chrome might simply have rejected a foreign DLL before Code Integrity ever got involved, which would make A1 meaningless.

It didn't, and this was measured rather than inferred. In A1 the module was resolved to a specific process and that process interrogated directly:

swiftshader module in pid 40816
  --type=gpu-process
  Get-ProcessMitigation -Id 40816 -> MicrosoftSignedOnly = ON, AllowStoreSignedBinaries = OFF

So the Microsoft-signed binary was mapped into a GPU child with CIG actively enforcing. The load was permitted, not skipped. (Signers were also checked per arm in the same run — Get-AuthenticodeSignature returned Valid with the CNs shown in the table.)

A2 reproducing A0 is what I would expect if nothing drifted in Chrome, the machine or CI policy between arms. With one run each it is a consistency check, not a control in any statistical sense.

What this does and does not establish

It does not prove the certificate alone is responsible. Edge 151.0.4129.78 and Chrome 151.0.7922.169 are different builds, so the two files differ in more than their signature. What it shows is narrower and still useful: a Microsoft-signed vk_swiftshader.dll loads in a CIG-enforcing Chromium GPU child on a machine where a Google-signed one is refused. On this machine, at least, the refusal is not simply a fixed property of the SwiftShader ICD or of the WebGPU path — some binary of that name was permitted to load under the same enforcing mitigation.

The settling experiment — the same Chromium revision signed both ways — cannot be built outside Microsoft.

What this means for the catalogue idea

I previously suggested shipping an AppxMetadata\CodeIntegrity.cat as the most direct remedy. I now think that is incomplete on its own, though I want to be careful not to overstate it.

The 3033 events here carry RequestedPolicy 8, which is the Microsoft signing level. My understanding is that a Store catalogue validates below that — I have not verified that myself and would welcome correction from anyone who has. What is reported rather than inferred: in the equivalent Codex case (openai/codex#34133) @vkwislacode describes a catalogue that is present and valid, with the load still refused.

But there is a second variable I should not skip past: the GPU child here also has AllowStoreSignedBinaries: OFF. CIG has a Store-signed-permitting variant, and Chromium is not using it. So the honest statement is not "no signing route exists" - it is that the Store-signing route is closed by how the mitigation is configured, not by signing being unobtainable. A catalogue combined with AllowStoreSignedBinaries enabled on the GPU child looks like it may be worth testing. I have no way to test it from outside Chromium, so I offer it as a direction rather than a recommendation.

That leaves three candidate directions rather than two, and I have no way to test the first:

1. Ship a catalogue and have the GPU child permit Store-signed binaries.
2. Don't let the GPU child reach the bundled SwiftShader ICD at all.
3. Survive the refusal. Chrome takes this identical block ~461 times a month on this machine and never dies. On the app side, each of the four occurrences I have log coverage for began with a single 3033 and the GPU child died within 11 seconds — I have no counter-example, but four is not a demonstration that every such refusal is fatal.

I would rather be corrected here than have effort spent down a path this evidence cannot actually rule in or out.

A negative result worth recording

Cloudflare's official Turnstile demo (demo.turnstile.workers.dev) did not reproduce anything here: 6 reps, no flags, widget verifiably rendered 6/6, 0/6 produced any 3033. I can't say why from 6 null reps. The point worth recording is only this: a clean run against a demo page is not evidence that a mitigation works.

Scripts and raw per-arm CSVs available if useful.

Reading back over the thread — corrections and credit

Several comments landed while I was running this, and two of them change what I would have claimed.

#87638 got to the auth-webview trigger before I did. My previous comment reported a crash from Claude's own Cloudflare challenge rather than the Browser pane, on 08-19. #87638 was filed on 08-18 with the same finding — the app's own claude.ai auth webview, 3033/3010 with per-second correlation, on 1.32352.1 — and it already carries has repro. Credit there, not here.

@aPipixia123456 argues the catalogue route is a dead end, and the argument is stronger than mine. Their point: RequestedPolicy = 8 is the Microsoft signing level, so neither re-signing nor an AppxMetadata\CodeIntegrity.cat can satisfy it, because a Store catalogue is a lower level. My section above hedges toward "the Store route is closed by how the mitigation is configured, since AllowStoreSignedBinaries is OFF" — those aren't contradictory, but they point different ways. If enabling that CIG variant is not something Chromium will do, their conclusion is the operative one and mine is a technicality. I'd defer to them unless someone can show the allow-store variant is actually reachable here.

@imitakov83's mechanism explains a null result I couldn't account for. They found --disable-features=Vulkan and --disable-software-rasterizer cover Skia/ANGLE Vulkan and the WebGL software fallback but not the WebGPU fallback adapter, because Dawn loads SwiftShader on its own path — so a trigger that only probes WebGL never reaches it. That is almost certainly why the Cloudflare demo page above rendered a widget 6/6 times and produced nothing: an explicit-render demo widget doesn't take the WebGPU path. It also means their extended switch set, not the shorter ones, is the one worth recommending to users.

@InfiniteBSOD's 13/13 correlation supersedes my 4/4. I hedged that four fatal occurrences don't establish that every 3033 is fatal. They have 13 crashes against 13 CI events on a separate machine, no 3033 without a crash and no crash without a 3033, across nine builds including an Electron bump to 42.9.2. That is the stronger version of the same claim, and their explanation for the missing crash dumps — the process is killed at DLL load time, so there is no exception to capture — accounts for a "no minidump" mystery that spans several issues in this cluster, and for why telemetry would show nothing.

Newer report that looks like this one: #87638 (has repro, auth webview). I also checked #88138 (Ok → Modified, NeedsRemediation on first launch) — despite the identical end state its body contains no vk_swiftshader, no 3033 and no 101457950, and it carries area:cowork, so it looks like the Cowork/update route rather than this one. Worth keeping those two routes apart during triage.

Independent corroboration, second machine, same signature — plus two data points this thread may not have yet.

Env: Claude Desktop 1.34493.1.0 MSIX (Claude_1.34493.1.0_x64__pzs8sxrjxfjjc, SignatureKind=Developer), Windows 11 Pro 26200.9168, RTX 5080 Laptop + Intel iGPU. SAC off, machine UMCI off.

Three identical kills in 2 days (2026-08-21 18:00:44, 08-22 21:45:04, 08-22 22:43:25), each: 3× CodeIntegrity 3010 on AppxMetadata\CodeIntegrity.cat, status 0xC000003A (STATUS_OBJECT_PATH_NOT_FOUND — the directory does not exist) → 3033 on app\vk_swiftshader.dll (RequestedPolicy=8, ValidatedPolicy=1, status 0xC0000428; 3089 shows the embedded Anthropic/DigiCert Authenticode is valid) → GPU exit 101457950 (0x060C201E) → package flips Modified, NeedsRemediation → 5× AppModel-Runtime error 0x3CFC (ERROR_NEEDS_REMEDIATION) denying GPU relaunch within ~450 ms of the 3033 → whole app dies. Triggers observed: a Cloudflare Turnstile challenge frame on claude.ai (WebGL) and browser-preview page loads. 12+ preview creations without a SwiftShader load ran clean — the load is the trigger, not the preview.

Data point 1 — the shipped MSIX has no catalog at all. The app's own repair cache (%LOCALAPPDATA%\ClaudeDesktopRepairCache\1.34493.1\Claude.msix, 247,405,438 bytes, SHA-256 AD5EAD595FEC1977C0CCB1D7FAB3BE040773B716451431DBD6BAB457BA31A55C, signature valid) contains 2,819 zip entries and zero AppxMetadata/* entries. It also contains a leftover [Content_Types].old — a re-pack footprint, consistent with a signing pipeline that bypassed SignTool's APPX catalog generation. Installed tree matches the MSIX byte-for-byte (SHA-256 identical for claude.exe, vk_swiftshader.dll, libEGL.dll, libGLESv2.dll, ffmpeg.dll, AppxBlockMap.xml, AppxManifest.xml) — no local tampering; the defect ships from the vendor. Deployment log confirms the package came from https://downloads.claude.ai/releases/win32/x64/... on 2026-08-21.

Data point 2 — repair is structurally cosmetic. Three distinct remediations (Remove+Add, RegisterByPackageFullName repair loop, Add from RepairCache — all "finished successfully") plus a reboot; AppxMetadata\ is still absent afterward with Status=Ok, and the next SwiftShader load kills the app again. Nothing to restore: the catalog was never in the package.

Corroborating the CIG analysis: live GPU child on this machine (Get-ProcessMitigation): MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF — so a Developer-signed catalog alone may stop the AppX integrity kill (LdrAppxHandleIntegrityFailure / NeedsRemediation) without clearing the 3033. Fix likely needs both: ship the catalog and tolerate the failed SwiftShader load (as unpackaged builds and Chrome do — same 3033 pair fires on Chrome here ~daily, 221×/218× in 17 days of CI log retention, always benign). Controls: OpenAI Codex MSIX on the same machine (Electron, Developer-signed) ships AppxMetadata\CodeIntegrity.cat, zero 3010 events; Nahimic DLL blocks (88×, three apps) never fatal.

Evidence gathered in a read-only forensics session with Claude Code; full command list available on request.

Confirming this on discrete NVIDIA hardware, on a newer app build, with one difference from the original report that I think widens the repro: the crash does not require a browser preview.

Environment

• Windows 11 Home Single Language 10.0.26200
• Claude Desktop 1.34493.1.0 (MSIX), package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
• NVIDIA GeForce RTX 3070, driver 32.0.16.1088 (also present: AMD Radeon iGPU, Parsec Virtual Display Adapter)
• VBS running, HVCI on, CodeIntegrityPolicyEnforcementStatus = 2
• Defender only, no third-party AV/EDR

Same fingerprint, same exception code

GPU process exited unexpectedly: exit_code=101457950     (0x060C201E)
GPU process launch failed: error_code=18   (x5)
FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418 GPU process isn't usable. Goodbye.

CodeIntegrity/Operational, same second as the FATAL line:

08:31:23  Event 3010: unable to load ...\AppxMetadata\CodeIntegrity.cat  Status 0xC000003A
08:31:23  Event 3033: claude.exe attempted to load ...\app\vk_swiftshader.dll
                      that did not meet the Microsoft signing level requirements
08:31:23.739  FATAL: GPU process isn't usable. Goodbye.

AppxMetadata\ does not exist at all in the installed package on this machine — the catalog is absent rather than unreadable, consistent with the original report.

New data point 1: fires without any browser preview

The original report is preview-triggered and deterministic on preview. Here, most crashes correlate with Browser-pane use, but not all. Example — cold start with no browser interaction, crash 37 seconds later:

08:22:00  Starting app { appVersion: '1.34493.1', isPackaged: true }
08:22:35  [updater] Checking for updates
08:22:37  GPU process gone: { reason: 'crashed', exitCode: 101457950 }

12 app-fatal GPU crashes in %LOCALAPPDATA%\Claude\Logs\main.log since 2026-08-21.

New data point 2: CI block fires far more often than it kills

116 Event 3033 records naming vk_swiftshader.dll on this machine, against 12 app-fatal crashes in the same window. So the rejection is survivable most of the time and only sometimes escalates to the five-failed-relaunch fatal path. Whatever distinguishes the fatal cases may be a useful narrowing signal.

New data point 3: --disable-gpu makes it worse, as predicted

Running Claude.exe --disable-gpu --disable-gpu-compositing still reaches Goodbye. — expected, since disabling hardware acceleration pushes Chromium harder onto SwiftShader, i.e. the blocked DLL. Matches the amplification noted in #89250.

Recovery behaviour matches

Register and RegisterByPackageFullName with RepairAppRegistrationOption both report success and do not restore launchability. Only Remove-AppxPackage + reinstall (which carries ForceApplicationShutdownOption) recovers. Once broken, the app launches and silently exits before showing a window — no error, no dialog, no Application Error event, no Crashpad dump. 12 reinstalls in ~36 hours.

Ruled out locally

Riot Vanguard (uninstalled, vgk gone), per-app GPU preference (tested against both adapters — byte-identical exit code either way), Defender ASR rules (none configured), Controlled Folder Access (off), IFEO entries for Claude (none), process mitigation policy (DisallowChildProcessCreation NOTSET, BlockDynamicCode NOTSET), AppInit_DLLs (empty), disk space (162 GB free), memory pressure (~1.5 GB tree RSS, 16 GB free).

Possibly related

nvspcap64.dll (NVIDIA overlay capture hook) is also Event 3033 blocked in claude.exe on this machine, non-fatally. Probably unrelated to the fatal path, but noting it since this is NVIDIA hardware and the original report was Intel — if the overlay hook is a second CIG-rejected injection into the same process, it may be worth a look.

Happy to provide full main.log, CodeIntegrity event export, or a GPU-child dump privately.

Confirming this on a different GPU vendor and a much newer build — the diagnosis in the opening
post holds unchanged.

Environment: Windows 11 26100, Claude Desktop 1.37937.1.0 MSIX (yours was 1.24012.9.0, so
this survived ~13 releases), AMD Radeon RX 7700 XT, driver 32.0.31041.1004 (yours was Intel —
so it is not vendor-specific). Three crashes in three hours, all second-exact on CodeIntegrity 3033
for app\vk_swiftshader.dll. AppxMetadata\ does not exist in the installed package here either —
only AppxSignature.p7x, AppxBlockMap.xml, AppxManifest.xml.

Three things I did not see in the thread that may save others time:

1. There is a Windows event that names the culprit directly — but it is ETW-only.
Microsoft-Windows-AppModel-Runtime Id=8, fired 271 ms before the first 0x3CFC:

Application Claude_1.37937.1.0_x64__pzs8sxrjxfjjc was terminated with error 0xC0000462 because of a problem with the application binary ...\app\vk_swiftshader.dll. It may be unsigned, contain an untrusted signature, corrupt or illegally modified.

Get-WinEvent -LogName Microsoft-Windows-AppModel-Runtime/Admin | Where Id -eq 8 returns zero —
it is never persisted. Two weeks of post-hoc log analysis here missed it entirely. It only appears
in a live ETW session, which is much cheaper than ProcDump for anyone reproducing this:

logman create trace ClaudeAppX -ets -p "{F1EF270A-0D32-4352-BA52-DBAB41E1D859}" 0xffffffffffffffff 0xff -o appx.etl
# reproduce, then:
logman stop ClaudeAppX -ets ; Get-WinEvent -Path appx.etl -Oldest | Where-Object Id -eq 8

2. Negative result — the Exploit Protection override does NOT work. Worth recording so others
do not lose an evening on it:

Set-ProcessMitigation -Name claude.exe -Disable MicrosoftSignedOnly

It writes the IFEO policy correctly (stored policy then reads MicrosoftSignedOnly : OFF), but
after a full application restart the newly created GPU process still measures
MicrosoftSignedOnly = ON. Chromium applies the mitigation from inside the child at runtime, so an
IFEO override cannot lift it. (Note the parameter is MicrosoftSignedOnly on this build —
BlockNonMicrosoftBinaries is rejected by the cmdlet's ValidateSet.)

3. Nothing is actually modified, which is why Repair cannot work. At the instant Windows reports
Modified, NeedsRemediation, verifying every file against the package's own AppxBlockMap.xml
gives 3054 files, 0 problems; ACLs match baseline; Get-AuthenticodeSignature on the DLL is
Valid, signer CN="Anthropic, PBC". Repair flips the status back to Ok by rewriting every file
(all 3056 mtimes change), so it is cosmetic — the next WebGPU adapter request brings it straight
back.

Also matching #58009 on this machine: the "Claude in Chrome" extension cannot connect at all under
MSIX ([Chrome Extension MCP] Failed to copy native host binary: EBUSY ... chrome-native-host.exe),
which removes the obvious "just drive an external browser instead" workaround for packaged installs.

Additional reproduction on Claude Desktop 1.40609.0.0 (Windows MSIX, x64). This appears to match the failure mode reported here, including the runtime mitigation state.

Reproduced twice on 2026-08-31

Two separate crashes in the same day produced the identical GPU-process signature:

2026-08-31 13:30:42 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

2026-08-31 14:24:10 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

For the second occurrence, the app log shows a Browser preview was created five seconds earlier:

14:24:05 [Preview] Created browser preview
14:24:10 GPU process gone: exitCode 101457950

Code Integrity events at the exact crash second

Microsoft-Windows-CodeIntegrity/Operational at 2026-08-31 14:24:10:

Event 3033:
claude.exe attempted to load
...\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

Event 3010 x3:
Code Integrity was unable to load
...\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
Status 0xC000003A.

The packaged vk_swiftshader.dll itself has a valid embedded Authenticode signature:

Status        : Valid
SignatureType : Authenticode
Signer        : Anthropic, PBC
Issuer        : DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1

AppxMetadata\CodeIntegrity.cat is absent in this installed package:

Test-Path "$($pkg.InstallLocation)\AppxMetadata\CodeIntegrity.cat"
# False

Runtime GPU-child mitigation

While Claude was running normally, before opening Browser Preview, I identified the live claude.exe --type=gpu-process child and queried it directly with Get-ProcessMitigation.

Observed:

BinarySignature:
MicrosoftSignedOnly      : ON
AllowStoreSignedBinaries : OFF

So the runtime mitigation state also matches the condition described in this issue.

Downstream lifecycle behavior observed after the second crash

At 14:24:11, one second after the GPU crash:

• Windows AppModel Runtime Event 217: the Claude Desktop AppX container was destroyed.
• CoworkVMService logged Persistent RPC: connection ended: failed to read length: EOF.

Shortly after:

Claude.exe            : absent
CoworkVMService       : Running
cowork-svc.exe        : still alive
Get-AppxPackage Claude: Modified, NeedsRemediation

On an earlier same-signature crash at 13:30, Cowork subsequently received a stop request and shut down cleanly. On the 14:24 occurrence, no corresponding Cowork stop request was observed, so the downstream cleanup path appears to have diverged even though the upstream GPU crash signature was the same.

I am not claiming the Cowork cleanup divergence or the Modified transition mechanism is explained by the GPU/CIG finding; I am reporting those as downstream observations only.

Current assessment

Confirmed on this machine:

• Claude Desktop 1.40609.0.0
• Browser Preview immediately precedes one reproduced crash
• Code Integrity Event 3033 blocks packaged vk_swiftshader.dll
• Event 3010 reports missing AppxMetadata\CodeIntegrity.cat
• GPU child exits with 101457950
• GPU child mitigation is MicrosoftSignedOnly=ON, AllowStoreSignedBinaries=OFF

The second occurrence additionally propagated into AppX/Cowork cleanup failure and Modified, NeedsRemediation package state.

I can provide the timestamped log excerpts and Windows event details if useful.

Two mechanism details this thread does not appear to cover yet — searched the OP and all 28 comments, and gpu-recovery, Sentry, and streak return zero. Neither is about the crash itself; both are about why it stays invisible. Confirmed on 1.40609.0.0, four crashes between 2026-08-30 and 2026-09-01.

1. The built-in auto-recovery cannot fire for this crash pattern

The app already ships a guard that disables hardware acceleration after repeated GPU deaths, along with a user-facing notice localized into twelve languages ("Claude crashed because of repeated graphics problems in the previous session, so hardware acceleration has been turned off."). It did not trigger once across four crashes.

From the bundled main-process code, the startup marker requires at least 3 GPU deaths, and the streak counter resets when deaths are more than 5 minutes apart (3e5 ms):

if (n - zdn > 3e5 && (eV = 0), zdn = n, eV += 1, ...)      // window reset
if (!(e >= 3)) { ... "consumed startup marker below threshold" ; return }   // threshold

The crashes here were hours to days apart — 08-30 17:11, 08-30 21:40, 08-31 22:35, 09-01 00:22 — so the counter never accumulated past one and the marker was discarded at every launch. The detector assumes a rapid crash loop; this failure is a slow drip, which is exactly the shape most of this thread describes.

Persisting the death count across sessions, or widening the window substantially, would let the existing safety net actually engage. (With the caveat in section 3 that the mitigation it engages does not fix this crash.)

2. Crash telemetry reports the fact but not the cause

Each of the four crashes produced a Sentry event roughly one second into the following launch — 4 for 4, with zero events across the other ~12 launches in the same log, so the correlation is clean. The payload:

[error] Sentry caught: {
  eventId: '8b9201c11fcb4b22b02d19627fc8a021',
  type: 'Unknown',
  value: 'No message',
  stack: undefined
}

No type, no message, no stack. Aggregate telemetry can therefore show these crashes occurring at whatever rate they occur, while carrying nothing that points at Code Integrity, vk_swiftshader.dll, or a signing-level mismatch. That may explain part of any gap between how often this is hit in the wild and how it ranks internally — the automated signal records that something died, and nothing about why.

3. Disabling hardware acceleration does not mitigate this

Consistent with #89250. Tested on 1.40609.0.0 with isHardwareAccelerationDisabled: true genuinely applied — note the in-app toggle silently fails to write it, which I have filed separately as #91147, so this required patching config.json externally with the app closed.

With the setting active and verified (GPU process on --use-angle=d3d11-warp-webgl, WebGL reporting Microsoft Basic Render Driver), navigator.gpu remains exposed, requestAdapter() still reaches the blocked SwiftShader path, and the app still terminated. Crash #4 in the list above was this configuration.

One detail for anyone instrumenting this: requestAdapter() resolves to null about a second before the process dies. It resolves precisely because the SwiftShader load was blocked, so any check that looks only at the resolved value will record this as a successful graceful fallback rather than an imminent crash.

Confirming your analysis on a newer build and a different GPU vendor — plus one data point I have not seen reported on this issue or the related threads: Repair does not restore the catalog.

Environment

| Item | Value |
| --- | --- |
| Claude Desktop | 1.40609.0.0 (MSIX, Claude_1.40609.0.0_x64__pzs8sxrjxfjjc) |
| Claude Code | 2.1.247 |
| OS | Windows 11 Pro, build 10.0.26200 |
| GPUs | AMD Radeon(TM) Graphics (iGPU) 32.0.21045.5002 + NVIDIA GeForce RTX 5090 32.0.16.1088 |
| Free RAM at crash | ~55 GB of 63 GB |

Same signature as yours. The Browser pane opened an external Cloudflare-protected page, the GPU process died about 4 s later with exitCode: 101457950 (0x060C201E), and the app terminated. Microsoft-Windows-CodeIntegrity/Operational in the same second: 3010 ×3 against AppxMetadata\CodeIntegrity.cat with Status 0xC000003A, and 3033 naming app\vk_swiftshader.dll. No BSOD, no Event ID 41, no 1001 — purely app-level, as you found.

So this is not limited to the 1.24012.x builds or to Intel Arc: it reproduces on a build eleven versions later, on an AMD iGPU + NVIDIA discrete pair.

The new part: Repair is not a fix

A Settings → Apps → Claude → Advanced options → Repair does re-download the .msix, re-register the package and restore launchability. It does not restore the catalog. After a successful Repair on 1.40609.0:

$pkg = (Get-AppxPackage -Name *Claude*).InstallLocation
Test-Path "$pkg\AppxMetadata\CodeIntegrity.cat"        # -> False, still absent
Test-Path "$pkg\app\vk_swiftshader.dll"                # -> True (5,550,416 bytes)
Get-AppxPackage -Name *Claude* | Select-Object Status  # -> Ok

The next Browser-pane page that touches WebGL crashes the app again.

This follows directly from your finding that the catalog is missing inside the downloaded MSIX: Repair re-downloads the same defective package, so there is nothing for it to restore. It also matches @HBCreAtiveD's report on #80444 that a full reinstall from downloads.claude.ai does not create AppxMetadata either, as long as the reinstall stays on the MSIX channel.

Practical consequence: the "just run Repair" workaround circulating on #80444 and the other threads recovers the package from appxState=2, but it does not stop the crash recurring. Only your non-MSIX (--exe) workaround actually removes the failure path.

One addition to the fix list

Worth stating explicitly alongside the asks you already have: Repair should restore the catalog once it ships. Otherwise anyone who hits this stays broken through every Repair cycle, and the failure stays invisible to Get-AppxPackage, which reports Status: Ok the whole time.

Consolidation

I have posted on #80444 suggesting this issue be treated as the canonical one for the root cause. The forensics here — live Get-ProcessMitigation on the GPU child, the catalog missing inside the MSIX, the ProcDump/WinDbg ntdll!LdrAppxHandleIntegrityFailure bucket, and the Chrome control group — are ahead of anything on that thread, but the same defect is currently spread across #80444, #80468, #81159, #81698, #81836, #82967 and #83478, which makes the true scale of it hard to see.

Correction to my earlier comment, section 3.

I cited the GPU process running --use-gl=angle --use-angle=d3d11-warp-webgl, and WebGL reporting ANGLE (Microsoft, Microsoft Basic Render Driver ... D3D11), as evidence that isHardwareAccelerationDisabled: true had taken effect. That inference was wrong. I never captured a before-state, and there had already been a GPU crash ~4 minutes before I observed those flags — so Chromium had almost certainly fallen back to software rendering on its own, which it does after GPU process crashes.

Two observations since:

1. The identical flags are present right now with the config key absent from config.json (verified in both the %APPDATA% path and the MSIX-redirected LocalCache copy), following an unrelated crash earlier today. So those flags do not indicate the app setting at all.

1. d3d11-warp appears zero times in the application bundle, so the app is not passing it. Chromium is selecting WARP itself.

What the correction does not change: "isHardwareAccelerationDisabled": true genuinely was present in config.json at the time of the crash I reported — that was verified directly by reading the file, in both paths, independent of the WARP flags. So the conclusion in section 3 stands: the setting does not mitigate this crash.

If anything the finding is stronger than I framed it. Since Chromium had already fallen back to software rendering before that crash, the app died in a session that was already software-rendering, with the app-level setting also applied. Neither Chromium's own GPU-crash fallback nor the application setting prevents it — navigator.gpu stays exposed and requestAdapter() still reaches the blocked SwiftShader load either way.

Sections 1 and 2 of that comment (the [gpu-recovery] threshold and reset window, and the empty Sentry payload) are unaffected — both were read directly from the bundled code and the app log rather than inferred. Re-verified today: still zero gpu-recovery entries across the full log, with GPU deaths hours apart, so that guard has still never fired here.

Apologies for the noise; better to correct a wrong mechanism in the thread than leave it standing.

Another confirmed reproduction of exactly this mechanism, with a few extra data points (x64, NVIDIA, HVCI/CIG, and the crash reproduces with hardware acceleration disabled).

Environment

• Windows 11 Pro 10.0.26200.9168 (x64), VBS/Code Integrity active
• Claude Desktop MSIX Claude_1.40609.1.0_x64__pzs8sxrjxfjjc (app 1.40609.1, Claude Code 2.1.255), installed via Claude Setup.exe, Status Ok between crashes
• NVIDIA GeForce RTX 4070 Ti (driver 32.0.15.9186 from Jan 2026, later 32.0.16.1656 from Aug 2026, same result) plus an idle AMD Radeon iGPU (no display attached)
• No DisplayLink, no Windows display-driver TDR events, no WER crash record for claude.exe, no Crashpad report written

Crash (3/3 browser preview opens on 2026-09-02, previously 40+ preview opens in July on 1.22209.x with zero crashes)
main.log each time: [Preview] Created browser preview then 2-7 s later

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Renderer log at the same second: A valid external Instance reference no longer exists. (Dawn), and in two of three cases The powerPreference option is currently ignored when calling requestAdapter() on Windows immediately before, i.e. WebGPU adapter discovery is the trigger. The whole app process tree dies in the same second (AppModel-Runtime event 217 "Destroyed Desktop AppX container" logged at the crash timestamp).

Code Integrity correlation (Microsoft-Windows-CodeIntegrity/Operational), all three crashes, same second as the GPU exit:

3010  Code Integrity was unable to load the ...\Claude_1.40609.1.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.   (x3)
3033  Code Integrity determined that a process (...\Claude_1.40609.1.0_x64__pzs8sxrjxfjjc\app\claude.exe) attempted to load
      ...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.

vk_swiftshader.dll, vulkan-1.dll, libGLESv2.dll, dxcompiler.dll, ffmpeg.dll in the package are all Authenticode-signed by Anthropic, PBC. Brave on the same machine logs the identical 3033 for its own vk_swiftshader.dll / vulkan-1.dll every ten minutes and never dies, so the MSIX loader escalation is the differentiator, as described above.

Hardware acceleration off does not help. With Help > Disable Hardware Acceleration (config isHardwareAccelerationDisabled: true, GPU process running --use-gl=angle --use-angle=d3d11-warp-webgl), the very next browser preview crashed identically with the same 3033/3010 events. So this is not a driver issue and the in-app toggle is not a workaround for this bug.

Post-crash state (matches #80444 / #84992): AppModel-Runtime status for the package sits at 0x2; every click on the tile runs RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption (deployment log 603/649, "Trying to repair ACLs"), which reports success but leaves status 0x2 and the app still does not launch. Only a fresh Add from the .msix (Claude Setup.exe) clears it to 0x0. Reboots do not clear it.

Notes for anyone working around it

• Invoke-CommandInDesktopPackage hangs indefinitely on this machine (the process is created, cmdlet never returns).
• Launching ...\WindowsApps\Claude_<ver>\app\Claude.exe directly from an unpackaged shell does get full package identity here (AppModel-Runtime 201 [FinishPackageActivation]), so extra Chromium switches can be passed that way. I am testing --disable-features=WebGPUService --disable-blink-features=WebGPU to keep WebGPU/Dawn from ever probing the Vulkan/SwiftShader DLLs while keeping the Browser tool; will report back.
• The bootstrapper has an --exe switch ("forcing Squirrel install"), but that build blocks Cowork (#79307), so it is not a real option for Cowork users.

Suggested fix remains as in the OP: ship the GPU-side DLLs at the required signing level / with a valid AppxMetadata\CodeIntegrity.cat, or drop MicrosoftSignedOnly on the GPU child in the MSIX build, and make a GPU-process death non-fatal like Chrome.

Confirming this on Windows 11 Home 25H2, build 26200.9168, Claude Desktop MSIX 1.40609.1.0.

Same signature: CodeIntegrity 3033 blocking app\vk_swiftshader.dll from
claude.exe, 3010 x3 on AppxMetadata\CodeIntegrity.cat (0xC000003A), package
then flagged Modified, NeedsRemediation.

Trigger: Claude Code session doing repeated site reviews (SEO work against a
site I own). Crashed multiple times in one afternoon, each time requiring a
full remove and reinstall. Not Cowork, two Code projects open.

Additional data points:

1. Repair is useless and misleading. Settings > Advanced options > Repair

first fails outright, then after the processes exit it reports success
(AppXDeploymentServer 400 + 613, "finished successfully", ACLs repaired)
but the Modified bit never clears. Only Remove-AppxPackage +
-PreserveApplicationData then reinstall recovers it.

1. Not Smart App Control. I turned SAC off entirely (registry

VerifiedAndReputablePolicyState 1 -> 0, confirmed, rebooted). The crash
recurred identically with SAC off. Consistent with CIG being the enforcing
mechanism, but worth stating since the "Learn more about Smart App Control"
link in the shell's error dialog sends people down that path. I gave up a
security feature chasing it.

1. The shell's "Can't open this app" dialog has a dead Advanced options

button, so the suggested fix cannot be reached from the dialog itself.

1. Possibly relevant: this machine has Intel Arc Software leftovers stuck in

WindowsApps\Deleted, failing to delete on a loop with error 0x12C. If a
degraded Intel graphics driver is pushing Chromium onto the SwiftShader
fallback, that would explain why some machines hit this constantly and
others never do.

Environment: Surface Pro 9, Intel graphics.

A second trigger for the same signing gate: an externally-injected DLL (Windows Auto Super Resolution), with the identical RequestedPolicy/Status fields

Reporting a variant on a Copilot+ ARM64 device. I'll separate what I measured from what I'm inferring.

The rejected module is not vk_swiftshader.dll. It is SuperResExt.dll from the Microsoft package Microsoft.AutoSuperResolution_1.0.1.0_arm64__8wekyb3d8bbwe, which Windows Auto Super Resolution injects into the GPU child. The crash happens at GPU-process init / launch — no window is ever drawn — not on a WebGPU/Vulkan browser-preview probe. vk_swiftshader.dll (5.0.0) is present in my Claude package but was never rejected, and I see no Event 3010.

The signing gate is identical to the one decoded in this thread. Event 3033 raw fields for my own claude.exe, six occurrences, all identical:

| Time | Process | File | RequestedPolicy | ValidatedPolicy | Status |
|---|---|---|---|---|---|
| 13:50:38–13:50:39 ×6 | claude.exe | SuperResExt.dll | 8 | 1 | 0xC0000428 |

RequestedPolicy 8 = SE_SIGNING_LEVEL_MICROSOFT, Status 0xC0000428 = STATUS_INVALID_IMAGE_HASH. Six rejections, six GPU-process crashes in main.log, then FATAL: GPU process isn't usable. Goodbye. with exit_code=101457950 / 0x060C201E.

Same-machine MSIX-vs-non-MSIX control, same DLL, same policy fields, same 24 hours:

| Process | 3033 rejections | Packaging | Outcome |
|---|---|---|---|
| msedgewebview2.exe | 292 | non-MSIX | survives, no crashes |
| claude.exe | 6 | MSIX | dies, 6 crashes |

292→0 versus 6→6 — the same shape as the Chrome control already in this thread.

Deterministic three-state A/B (Claude Desktop 1.52386.3.0 arm64 MSIX, Electron 44.2.0 / Chromium 152.0.7977.76; ASUS UX3407QA, Snapdragon X X1-26-100, Adreno X1-45 driver 31.0.152.1, Windows 11 26200 ARM64, HVCI + Secure Launch active):

| ASR state | claude.exe 3033 | Result |
|---|---|---|
| Package registered (Windows default) | 36 over 2 days | dies at launch |
| Toggled Off in Settings > Display > Graphics, rebooted | 12 | still dies — the Settings toggle does not stop injection |
| Package removed, rebooted | 0 | launches normally, 9-process tree, GPU sandbox enabled |

Re-registering ASR restores the failure. Proton Pass 1.40.0.0 (x64 MSIX, different vendor and Electron version) fails and recovers identically. VS Code (arm64, non-MSIX) is unaffected throughout.

Flag bisect (packaged exe launched directly from WindowsApps): no flags → crash; --use-angle=d3d11-warp → crash (WARP is Microsoft's CPU rasteriser and never touches the Adreno path, so this rules out the GPU driver and the D3D11 rendering path); --in-process-gpu → works; --disable-gpu-sandbox → works, hardware acceleration intact.

---

A data point for the CodeIntegrity.cat discussion above

@aPipixia123456 argued that shipping the catalog would not help, since RequestedPolicy=8 is the Microsoft signing level and a Store catalog validates below it. The ASR package is an interesting counter-example, measured on this machine:

Get-ChildItem <ASR package>\AppxMetadata
CodeIntegrity.cat 12548 bytes (present)

Get-AuthenticodeSignature on every DLL in that package:
SNPE.dll NotSigned
SnpeHtpV73Stub.dll NotSigned
SuperResExt.dll UnknownError CN=TestAzureEngBuildCodeSign
(subject = issuer, untrusted root)

So a shipping Microsoft Store package contains two unsigned DLLs and one test-signed DLL, and ships a catalog — and those load fine in that package's own context. That suggests catalogs do vouch for sub-Microsoft-level binaries within their own package boundary.

For contrast, on the same machine:

Test-Path <Claude package>\AppxMetadata\CodeIntegrity.cat -> False
Test-Path <ASR package>\AppxMetadata\CodeIntegrity.cat -> True

That independently confirms the missing-catalog reports here.

What I am not claiming: that a catalog would let vk_swiftshader.dll pass RequestedPolicy=8 inside the GPU child. That is the open question and I can't answer it. I'm only noting that the "a catalog can't vouch below the Microsoft level" premise doesn't match what ASR's package does inside its own context.

What this variant does establish: SuperResExt.dll is only loadable where its own package catalog is in scope. When ASR injects it into a foreign MSIX process, that catalog is out of scope, the DLL is evaluated on its embedded signature (a test cert chaining to an untrusted root), and it's refused — with the same policy fields as the bundled-DLL case. Because the module comes from an OS package rather than Claude's bundle, no app-side packaging or signing change can prevent this particular trigger.

Filed the OS-side behaviour with Microsoft via Feedback Hub. Details and controls also at electron/electron#53859 and electron/electron#52700. Happy to share the full CodeIntegrity export or run further diagnostics on this hardware.

One risk none of the remediation steps discussed in this thread mention: if you're about to run a repair/reinstall loop to clear the Modified, NeedsRemediation state, back up ~/.claude first.

@strumienapp's data point above (Squirrel build shares ~/.claude with the MSIX build, no data loss) is reassuring for a build switch - but a straight MSIX repair/reinstall is a different operation, and it has a separate, confirmed failure mode: #62997 documents that a Claude Desktop reinstall can destroy Code chat history (transcripts + Recents) while regular Chat history, project files, and memory all survive intact. That issue is closed but the underlying reinstall behavior it describes hasn't changed as far as I can tell, and it isn't specific to this CIG/vk_swiftshader bug - it can happen on any reinstall. Given how many people on this thread are already several repair cycles deep (@lucasmiachon-blip's "three distinct remediations," @MatusPohorenec's catalog-not-restored finding), that's a second, unrelated way to lose data while fixing the first problem.

I wrote up the CIG root cause end-to-end (matches this issue's diagnosis) plus a small PowerShell script that checks a machine for this exact risk and backs up ~/.claude before you touch Remove-AppxPackage or run Repair: https://github.com/sifatahmedsrk52-cyber/claudeguard - the root-cause writeup and the manual fix (switch to the unpackaged/Squirrel build, same as confirmed working in this thread) are free in the README, the diagnose+backup tooling itself is a paid download now since people wanted more than just the writeup.