Windows: hidden Browser-pane preview kills the app via Code Integrity block on packaged vk_swiftshader.dll, then "Repair" dialog

+1 — independent repro on a consumer machine, which rules out two confounds in the original report.

Same signature: GPU process gone: { reason: 'crashed', exitCode: 101457950 } (0x060C201E) from a Browser-pane preview, then Modified, NeedsRemediation and the Repair dialog.

| | #80999 original | here |
|---|---|---|
| Windows | 11 Enterprise 26100, corporate-managed | 11 Home 26200, personal |
| Security | CrowdStrike, Trellix, BeyondTrust | Defender only |
| VBS / HVCI | disabled | enabled |
| GPU | Intel UHD + NVIDIA T1200 | AMD Radeon iGPU + RTX 4070 Ti |
| Version | 1.24012.1.0 / 1.24012.9.0 | 1.24012.9.0 |

Preconditions confirmed here:

SignatureKind                  : Developer
AppxMetadata\CodeIntegrity.cat : MISSING
app\vk_swiftshader.dll         : Authenticode Valid, CN="Anthropic, PBC"
Get-ProcessMitigation -System  : ASLR NOTSET

The minidump contains no vendor GPU driver modules at all (only dxcore.dll/dxgi.dll) — consistent with the GPU process already being on the software path when it died.

Run-up, from [process-memory] (once/min):

11:32:46  total=2171MB  eproc=10          <- steady state, 20 min flat
11:33:43  [PreviewContext] Opened preview user tab
11:35:45  total=2652MB  eproc=14
11:36:42  total=3016MB  eproc=16          <- GPU proc RSS 150MB -> 248MB
11:38:48  *** GPU process gone, exitCode 101457950 ***

Second crash 12 min later, same shape. children(0)=0MB throughout — Claude Code subagents were running the whole time and never enter the app's process tree, so the growth is purely Browser-pane renderers.

Repair race reproduced too (#63397): 0x80073D02 x4 before one succeeded. -ForceTargetApplicationShutdown avoids it.

Windows logged the mechanism directly, at the exact crash second, on both crashes — so this is observed here rather than inferred.

Microsoft-Windows-CodeIntegrity/Operational:

11:38:48  Event 3010 (x3)  Code Integrity was unable to load ...\Claude_1.24012.9.0
          _x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.

11:38:48  Event 3033       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.

Same second, app log:

2026-07-25 11:38:48 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

0xC000003A is OBJECT_PATH_NOT_FOUND — catalog confirmed absent on disk. Second crash at 11:50:46 is identical (3x 3010 + 1x 3033).

Environment delta is in my comment above; the short version is that it reproduces with no third-party EDR and with HVCI enabled, on a different GPU vendor pairing.

Event-log exports and a minidump of the second crash are available if useful.

Workaround worth listing: use the claude-in-chrome extension instead of the in-app Browser pane.

It drives real Chrome via the native-messaging host, so no electron_renderer is created inside Claude Desktop, the GPU process never falls back to SwiftShader, and vk_swiftshader.dll is never image-mapped. The trigger isn't present. WebFetch/WebSearch cover read-only cases.

For agent work, restate the constraint in subagent prompts — the previews get opened by subagents, and children(0)=0MB means they never appear in the app's process tree, so this misreads as "too many agents" and sends you tuning concurrency instead.

Workaround, not a fix. Also note chrome-native-host.exe can be left file-locked after a crash (#68956).

Confirming this on a consumer machine with no EDR and no hybrid graphics, which should rule out
the security stack and the GPU-switching angle as confounds.

Same fingerprint

AppxMetadata folder is empty — CodeIntegrity.cat is absent here too, and Code Integrity
blocks vk_swiftshader.dll at the exact second of each GPU-process death. Three for three:

21:09:46  CodeIntegrity 3033  claude.exe -> vk_swiftshader.dll blocked
21:09:46  CodeIntegrity 3010  AppxMetadata\CodeIntegrity.cat  Status 0xC000003A   (x3)
21:09:46  main.log: GPU process gone: exitCode 101457950

21:42:39  CodeIntegrity 3033 + 3010 x3 (same)
21:42:40  main.log: GPU process gone: exitCode 101457950

22:25:43  CodeIntegrity 3033 + 3010 x3 (same)
22:25:43  main.log: GPU process gone: exitCode 101457950

Followed by the AppX cascade you documented: 603/607 → 638
(Running apps: {Claude_pzs8sxrjxfjjc!Claude}) → 419/404 0x80073D02, plus 8104
(Failed to set the Trust Label ... 0x80070057) and 8107 (Illegal non-AppStore or
non-AppInstaller package integrity validation attempted).

Recovery here: automatic remediation, no manual reinstall, no reboot

Worth adding because it differs from your recovery path. I only clicked the taskbar icon; no
installer was run by hand (there is no ClaudeSetup.log on this machine at all). Windows drove
the whole thing:

22:25:43  GPU crash, app dies
22:25:48  taskbar click -> RegisterByPackageFullName (ForceTargetApplication) -> 400/613 success
22:26:04  taskbar click -> Register again -> success
22:26:14  Windows escalates: RepairPackageOperation
          665: "starting Add operation on package Claude_1.24012.9.0_..."
          854: https://downloads.claude.ai/releases/win32/x64/1.24012.9/Claude-<hash>.msix
          ^ Windows re-downloaded the full MSIX itself
22:29:39  666: Add operation SUCCEEDED (overall time 204953 ms)
22:29:39  665: "starting Register operation" (the second half of the repair)
22:29:40  9645/9641: 0x80004004 Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude
22:29:40  638 -> 419 -> 404: 0x80073D02

So the self-block you describe reproduces exactly — but only the Register half failed. The
Add had already completed, which is presumably why the package ended up Status: Ok here
instead of bricking. The app launched normally afterwards.

That suggests the difference between "recovers by itself" and "unlaunchable until clean-boot
reinstall" may just be whether the Add half of the repair finishes before the Register half hits
the still-running process — i.e. a race, not an environmental difference.

What this environment removes as a confound

| | Original report | Here |
| --- | --- | --- |
| Security stack | CrowdStrike + Trellix + BeyondTrust, corporate-managed | Windows Defender only, unmanaged consumer machine |
| GPU | Hybrid: Intel UHD + NVIDIA T1200 | AMD Radeon 780M, integrated only — no hybrid switching |
| OS | Windows 11 Enterprise 26100 | Windows 11 Pro 26200 |
| App | 1.24012.1.0 / 1.24012.9.0, Developer-signed sideload | 1.24012.9.0, Developer-signed sideload |

Also reproduced across two AMD driver versions (32.0.22029.9039 → 32.0.31021.5001), so it is
not a driver regression.

WebGL burst immediately before each death

2026-07-25 21:09:46  21 x WebGL warnings, incl. CONTEXT_LOST_WEBGL: loseContext: context lost
2026-07-25 21:42:39  19 x WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
                       (incl. "... when EXT_color_buffer_float is not enabled")
2026-07-25 21:42:39  The powerPreference option is currently ignored when calling requestAdapter()
                       on Windows. See https://crbug.com/369219127

Consistent with the SwiftShader-fallback path: context is lost, Chromium reaches for the software
renderer, the DLL load is blocked, the GPU process dies.

Useful contrast: a GPU crash not on this path is survivable

22:19:21  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34 }
22:19:35  [WarmLifecycle:preview] Warming up session ...
<app kept running>

No browser pane open, no CodeIntegrity 3033 at that timestamp, exitCode 34 instead of
101457950 — and the app respawned the GPU process and carried on. So the app's GPU-crash
recovery works fine in general; it is specifically this blocked-DLL path that is fatal.

One caution on version

The delay between opening the pane and the crash varied a lot here — 6.5 min, 43 s, 1 s — so the
trigger looks page-driven (whatever pushes the renderer into SwiftShader) rather than tied to pane
creation. On this machine 1.24012.1 happened not to crash, but given #80444 and your own 1.24012.1
data, I'd read that as which sites were visited, not as a version boundary. Flagging it so nobody
chases a false regression point.

Workaround note

Settings > Apps > Claude > Advanced options > Repair clears the Modified flag, but since the
catalog is missing from the MSIX itself, it does not stop the crash. Blocking the browser pane
outright does — in Claude Code, permissions.deny: ["mcp__Claude_Browser"].

Environment

| Item | Value |
| --- | --- |
| App | Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer |
| Claude Code CLI | 2.1.219 |
| Electron node | 24.18.0 |
| OS | Windows 11 Pro 10.0.26200 |
| CPU | AMD Ryzen 7 7840HS |
| GPU | AMD Radeon 780M (integrated, sole adapter) |
| GPU driver | 32.0.22029.9039 and 32.0.31021.5001 — both affected |
| AV | Windows Defender only |
| RAM | 28 GB, ~18.5 GB free at crash time |

Confirming the same root-cause chain on another environment, this time Windows Server 2022 Standard 10.0.20348.5139.

Reproduction

• Claude Desktop MSIX 1.24012.9.0, SignatureKind: Developer
• The app worked immediately after reinstall/restaging.
• After using the in-app Browser/preview, Claude exited and every subsequent activation showed the Windows repair/reinstall dialog.
• This reproduced on two separate reinstall cycles. Disabling Claude auto-updates did not change the result; no package update occurred between reinstall and failure.

Exact Windows fingerprint

At the failure second:

CodeIntegrity 3010 (x2)
...\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
Status 0xC000003A

CodeIntegrity 3033
claude.exe attempted to load ...\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements

The package then reported:

Status: Modified, NeedsRemediation

Subsequent activations logged AppModel-Runtime Event 6 / 0x3CFC: machine-level package status check failed and the application could not be started.

Independent checks

• claude.exe and vk_swiftshader.dll both have valid Authenticode signatures from Anthropic.
• Both binaries match the signed AppxBlockMap.xml exactly (0 mismatched blocks; 3,554 blocks for claude.exe, 85 for vk_swiftshader.dll).
• Microsoft Defender recorded no detection or remediation involving Claude.
• DISM /Online /Cleanup-Image /CheckHealth reports no component-store corruption.
• There is no effective AppLocker rule set and no enforced user-mode WDAC policy.

An in-place rollback to 1.24012.1.0 restored package status to Ok. A multi-profile launch test then completed without new Code Integrity or AppModel errors. We are avoiding the in-app Browser pane; I am not claiming .1 fixes the underlying packaging issue, since this issue already demonstrates the same chain there.

This adds Windows Server 2022 to the affected environments and independently confirms that the Browser/SwiftShader path, not auto-update or profile data, is the trigger.

Cross-reference sweep: this is now a multi-report Windows incident

I searched the repository on 2026-07-28 for vk_swiftshader.dll, 101457950 / 0x060C201E, CodeIntegrity.cat, NeedsRemediation, and Browser/preview GPU failures. At least 21 open issues appear to be part of this incident cluster.

1. Direct Code Integrity / SwiftShader evidence

These independently document the late vk_swiftshader.dll load, Code Integrity rejection, and/or the resulting NeedsRemediation state:

• #80999
• #81341
• #81745

2. Same Browser -> GPU death -> AppX activation/repair damage

These report the same in-app Browser/preview trigger, fatal GPU failure, and package activation or repair failure:

• #80444
• #80978
• #81123
• #81159
• #81398

3. Same Browser-pane + exit-code fingerprint

These independently report the in-app Browser/preview followed by GPU exit 101457950 / 0x060C201E and loss of the desktop app:

• #80483
• #80689
• #80701
• #81204
• #81275
• #81578
• #81749
• #81840

4. Same fatal GPU / relaunch cluster, with a less explicit trigger or integrity trace

• #77768
• #81358
• #81664
• #81698
• #81836

This spans Windows 10, Windows 11, and Windows Server 2022; Intel, AMD, NVIDIA, hybrid graphics, and WARP/software rendering; Defender-only and enterprise-managed machines; and desktop builds including 1.24012.1 and 1.24012.9. Disabling hardware acceleration has also reproduced the same failure, so a GPU-driver-only explanation does not fit the combined evidence.

The reports point to two related product defects:

1. a late SwiftShader/WebGPU fallback load colliding with the GPU child's Microsoft-signed-only mitigation; and
2. Claude Desktop escalating a GPU-child failure into a browser-process fatal plus an AppX repair/activation failure instead of recovering as Chromium normally does.

One reporter in #81398 verified that the official non-MSIX EXE build survives the same multi-window workload with zero Code Integrity 3033 events. That is a useful packaging control, but it is a community workaround, not an official fix.

I found no linked fix PR or maintainer acknowledgement in this cluster yet. Could these reports be consolidated under a single tracked regression, assigned the Windows/Desktop labels and an owner, and given a confirmed safe-build or remediation status?

Adding one more data point on the browser-process crash mechanism — a case with an actual Crashpad dump, which several reports here noted they were missing.

From anthropics/claude-code#81664 (my own report, same fingerprint, Intel UHD integrated graphics): a repro produced a Crashpad .dmp, parsed directly from the minidump streams (no debugger/symbols available):

• ExceptionCode: 0x80000003 (EXCEPTION_BREAKPOINT) — not an access violation.
• Faulting module: Claude.exe itself.
• Crashing thread: CrBrowserMain — the browser process's own main UI thread, not the GPU child process.
• The dump's ProcessId matches the main/browser process, not the GPU process.

This lines up exactly with the LOG(FATAL) << "GPU process isn't usable. Goodbye." mechanism described above: once Chromium exhausts its GPU-mode fallback ladder, the browser process deliberately self-terminates via a CHECK()/IMMEDIATE_CRASH()-style breakpoint trap on its main thread — which is why the whole app dies hard instead of just losing/respawning the GPU child. Whether Crashpad manages to catch that trap before the process fully unwinds looks timing-dependent, which would explain why it's absent in most other reports here.

Trigger in my repro was a Browser-pane viewport resize (resize_window), consistent with anything that forces the pane's compositing surface to reallocate while it's already destabilized — in my case, by the app's own internal preview-thumbnail capture failing on a hidden pane just beforehand.

Independent confirmation on a different Windows SKU and build.

Environment: Windows 11 Home 26200 (reporter: 11 Enterprise 26100),
Claude 1.24012.9.0, Intel i5-12400, 64 GB RAM. No managed policy configured
(SOFTWARE\Policies\Claude absent), so this is not enterprise-config-specific.

Same 3033, same DLL:

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

Runtime confirmation that the catalog is absent. The report infers this
from inspecting the MSIX; here Windows says so directly at load time —
three of these fired in the same second as the 3033:

Id=3010 Code Integrity was unable to load the
...\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
catalog. Status 0xC000003A.

0xC000003A is STATUS_OBJECT_PATH_NOT_FOUND — the file isn't there, rather
than being present-but-invalid. That supports fix suggestion #2 specifically.

The remediation loop is visible in AppXDeploymentServer/Operational. The
same version was re-Added four times in under two hours, bracketed by repair
operations — consistent with the Modified-flag path in the report rather than
with ordinary updates, which would install differing versions:

20:28:33 RepairPackageOperation
20:28:52 Add Claude_1.24012.9.0 <- same version
20:34:41 RepairPackageOperation
20:34:59 Add Claude_1.24012.9.0 <- same version
22:14:59 ResetPackageOperation
22:15:18 Remove -> StageUserData -> Register
22:17:53 Remove

Each deployment carried ForceTargetApplicationShutdownOption, so any running
session was terminated.

Two notes for anyone else collecting evidence:

1. Nothing appears in Reliability Monitor. Across 90 days there is not a

single APPCRASH, AppHang, MoAppCrash or Application Error naming claude.exe
— consistent with an AppModel integrity kill rather than a fault. Users
hitting this will reasonably conclude "no crash was logged" and look
elsewhere.

1. Microsoft-Windows-CodeIntegrity/Operational is 1 MB circular. On a

machine where AV AMSI components log heavily, it retained only ~2.5 hours
here — my own crash-storm evidence from two days earlier had already rolled
off. Worth raising it to 20–50 MB before trying to reproduce, otherwise
the 3033/3010 pair will likely be gone by the time you look.