[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.