[BUG] Claude Desktop — recurring silent GPU-process crash kills entire app during web research (4-5×/day), no recovery, no crash dump

Confirming the same crash signature on a second machine, but with a later onset.

Environment

• Surface Pro 11 (Snapdragon X / Windows on ARM64)
• Windows 11
• Claude Desktop 1.24012.9 (MSIX)

This first began on this machine on 2026-07-25; it had not manifested here previously, even though this issue was opened about two weeks earlier. It recurred on 2026-07-26 at approximately 06:59 local time during Preview/web-research activity.

Relevant log sequence:

2026-07-26 06:58:31 [Preview MCP] javascript_tool timed out after 30000ms
2026-07-26 06:59:10 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

The exit code matches this report exactly: 101457950 / 0x60C201E. After the crash, Claude Desktop could not be relaunched; the Windows package later reported Modified, NeedsRemediation, and a normal reboot was required to clear the stuck state.

Unlike the original report, Crashpad generated an approximately 35.6 MB .dmp file. I can provide a sanitized log excerpt or the dump privately if an Anthropic maintainer requests it. I am not attaching the dump publicly because it may contain sensitive application state.

The delayed onset could indicate a recent Desktop rollout/update or a newly exercised Preview/browser path, but that is only a hypothesis.

Follow-up after correlating the rotated Claude logs with Windows power/display events:

• At 2026-07-24 22:43:05, Claude logged: [updater] Version changed since last launch: 1.24012.1 → 1.24012.9.
• On 1.24012.1, the logs contain 12 browser-preview creation events from July 22–24 with no matching reason: 'crashed', exitCode: 101457950 failure.
• On 1.24012.9, there are 20 browser-preview creation events and five distinct crash times between July 25–26, all with the exact 101457950 / 0x60C201E signature. (Some log records are duplicated, so raw line counts are higher.)
• The first matching crash occurred 51 seconds after a browser preview was created; the second occurred 3 seconds after preview creation. The latest was preceded by [Preview MCP] javascript_tool timed out after 30000ms.
• The crashes occurred on both battery and AC power. There was no Windows power transition, display-driver reset/Event 4101, WHEA event, or DxgKrnl error within ±2 minutes of the crash times.
• The recently modified power-plan values are Sleep=Never, lid-close=Do Nothing, display timeout, and brightness. There are no explicit overrides for GPU preference, PCIe Link State Power Management, or processor boost.

This makes the 1.24012.9 update plus the Preview/browser path a materially stronger correlation than the power-plan changes. The no-sleep/lid settings could increase process lifetime and exposure to the bug, but there is no evidence of a power transition directly causing the crashes. This is correlation, not yet proof of causation.

Likely the same root cause as #81341, where I have just posted a measured breakdown: Chromium's Code Integrity Guard (MicrosoftSignedOnly = ON, AllowStoreSignedBinaries = OFF, measured live on the running GPU child) refuses the package's own Authenticode-signed app\vk_swiftshader.dll with 0xC0000428 (CodeIntegrity event 3033, RequestedPolicy 8 vs ValidatedPolicy 1) when Dawn probes for a SwiftShader fallback adapter. The GPU process exits 101457950 / 0x060C201E and the browser process then reaches IntentionallyCrashBrowserForUnusableGpuProcess().

Two points from that comment that may be useful here:

• Stock Chrome on the same machine takes the byte-identical refusal 275 times without crashing, so the block is routine and the fatal escalation is the actual defect.
• No Chromium or Electron bump fixes it. Chromium's 2022 preload workaround (51c97ad46b7b) was deliberately narrowed in March 2026 (97b3f5d7800fde085af53b1b7455b730c215a874), and Electron 42.7.0 already ships the narrowed Chromium 148.0.7778.280.

Full detail, including the ERROR_PACKAGES_IN_USE repair loop that produces the "reinstall the application" dialog: #81341.

Root cause identified — see this comment. Electron 42.7.0 does not honour app.disableHardwareAcceleration() on Windows (fixed in 42.7.1); the GPU process then loads vk_swiftshader.dll, which Code Integrity Guard rejects because the MSIX ships no AppxMetadata\CodeIntegrity.cat. The trigger analysis in the body of this comment is superseded.

Edited 2026-08-01. This comment has been substantially corrected after I ran an independent verification pass over every factual claim in it. Five of eight claims were wrong or overstated — including two I had asserted confidently. Corrections are folded in below; a summary of exactly what changed is in the follow-up comment, and the original text is in this comment's edit history.

Independent occurrence on a different OS with a completely different trigger, producing the identical exitCode: 101457950 (0x060C201E) and the same total-loss outcome. Posting because two unrelated triggers converging on the same result points at the handler rather than the trigger.

Impact — this is the part that hurt

Three Claude Code sessions were live. All died. Two were mid-turn, each frozen on a user message that never got a reply. In one of them the message the user had just submitted was lost and re-sent by the client, leaving a duplicate in the transcript. Session history survived only because it is journalled to disk independently of the crash path.

There was no warning, no degraded mode, and no indication of what happened — from the user's side the window simply vanished.

Environment

• Windows 11 Pro 26200 (vs. Windows 10 19045 in the original report)
• Claude Desktop 1.24012.9.0 — MSIX, Developer-signed / sideloaded (SignatureKind: Developer, IsDevelopmentMode: False, AppxSignature.p7x present, installed under WindowsApps)
• Hybrid graphics laptop: NVIDIA GeForce RTX 5070 Laptop GPU (driver 32.0.16.1088, 2026-07-22) + AMD Radeon 610M integrated (driver 32.0.21045.1000, 2026-07-23)
• AV: Bitdefender 30.0.32.153 (Windows Defender not running — AMRunningMode: Not running)

What happened

2026-08-01 02:47:50 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Immediately before it, in Microsoft-Windows-CodeIntegrity/Operational, same second:

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

Provenance note: I captured that event text verbatim at 08:33 the same morning. The log has since rolled (see the retention section) and the record no longer exists, so it cannot be re-read now. Everything below that depends on its exact wording rests on that one contemporaneous capture.

vk_swiftshader.dll is SwiftShader's Vulkan ICD — Chromium's bundled software renderer (confirmed from the shipped binary: ProductName: SwiftShader Vulkan Dynamic Link Library, © 2018 Google Inc., exports vk_icdGetInstanceProcAddr, with vk_swiftshader_icd.json beside it). With it blocked, GPU-process creation failed. Windows refused creation 5× with 0x3CFC / ERROR_NEEDS_REMEDIATION, then the app wrote a crashpad dump and terminated with GPU process isn't usable. Goodbye.

Windows subsequently flagged the package Modified / NeedsRemediation and its auto-repair retried Register six times (02:48:39 → 03:02:52) before a manual MSIX reinstall resolved it.

On the trigger — weaker than I first claimed

In the surrounding window Code Integrity was also rejecting Bitdefender's AMSI provider in bulk (369 blocks of antimalware_provider64.dll vs 1 for vk_swiftshader.dll across that log; a further 372 in a later 90-minute window). I originally presented this as the likely cause. It does not hold up as well as I implied, and I want to be explicit about that rather than leave the tidier version standing:

• The provider is not a stale leftover, and I should not have called it one. It is the registered, current, shipping component (HKLM\SOFTWARE\Microsoft\AMSI\Providers → that exact path; only one dlls_* directory exists), and its ordinary Authenticode signature is valid (Bitdefender SRL via DigiCert, timestamp-countersigned to 2029). It fails a different bar: a provider loaded into a protected host process needs an anti-malware/ELAM signing level.
• It is not failing everywhere. The DLL is currently loaded successfully in ~25 live processes. Only the load into svchost.exe is rejected. So "AMSI is broken machine-wide" — which my first version implied — is wrong.
• Its failure is therefore structural and constant, while vk_swiftshader.dll failed exactly once and has not failed since. A direct collateral-rejection mechanism would predict repeated hits on Claude. The data does not show that.

Net: the AMSI correlation is real but the causal link is not demonstrated, and on closer inspection the evidence runs against it. Treat the trigger as unexplained.

**One lead I have not examined, flagged for completeness:** this is a hybrid-graphics machine, and Windows Update history shows a driver storm on 2026-07-29 23:02–23:31 — roughly 90 failed (ResultCode 4) attempts including the AMD graphics driver, several succeeding only on retry, with amdkmdag.sys registered from two different driver stores that evening. That is ~27 hours before the crash. There are no TDR events and nothing GPU-related in the System log at 02:47, so this is a background suspect only — but it is a more conventional explanation for a GPU-process failure than anything above, and I raise it rather than leave it out.

Requests (in priority order)

1. Don't treat GPU subprocess loss as fatal. Degrade to a mode that stays alive without the GPU process.

Caveat worth stating: the natural "fall back to software rendering" answer routes through vk_swiftshader.dll — the very DLL that was blocked here. Under this failure mode that path is unavailable, so a robust fallback is one that doesn't depend on loading it (app.disableHardwareAcceleration() / --disable-gpu territory). I have not verified which path this Electron build takes when the GPU process dies at launch; flagging it as a question, not a claim.

1. Retry with backoff, not 5 immediate attempts. The block was transient — it has not recurred since.
2. Flush pending user input before terminating, so the client doesn't have to re-send and duplicate it.
3. Surface the fault instead of vanishing silently.
4. Put the cause in the crash report. exitCode: 101457950 (0x060C201E) is opaque; the Code Integrity 3033 event names the blocked DLL and made this diagnosable in minutes. Capturing recent 3033/3010 entries at crash time would remove the dependency on a log that rolls (below).

Repro hint for QA

Block app\vk_swiftshader.dll from loading — a WDAC/Code Integrity policy will do it deterministically — and launch the app.

• Expected: the app stays up without the GPU process, or reports a graphics fault and continues degraded.
• Actual: whole process tree exits with exitCode: 101457950 (0x060C201E).

("Expected: falls back to SwiftShader" is not a valid expectation under this repro — SwiftShader is the blocked component.)

The log-retention hazard, measured

Microsoft-Windows-CodeIntegrity/Operational ships with maxSize: 1052672 (1 MB), retention: false (circular). At this machine's event rate that is about 50 minutes of history — measured at 09:58 the same morning, the log spanned only 08:35:29 → 09:25:05 (OldestRecordNumber 7060; records 1–7059 purged, no archived copy, no log-clear event).

The 02:47 crash events were present at 08:33 and gone by 09:58. The user reports an earlier occurrence whose evidence was lost the same way.

This is the argument for request #5: asking a reporter to retrieve Code Integrity events after the fact will routinely arrive too late on any machine with a noisy AMSI provider.

What is not ruled out

Correcting my own earlier over-claiming here too:

• Memory — I said "ample free RAM." That was a post-hoc reading and it was not ample: commit charge sits at 90.9% of the commit limit with ~3.7 GB headroom, and Memory Compression holds a 2.7 GB working set. The sound exculpatory evidence is different: zero Resource-Exhaustion-Detector (2004) events in a System log retained back to 2026-07-29 22:06, which fully covers the crash window.
• Windows Update — I said the last update was "two days before." Get-HotFix reports date-only, midnight-stamped values and does not list driver updates at all. KB5101684 is independently confirmed at 2026-07-29 23:13 (~27 hours before, not two days); KB5101711 has no entry in the 128-record Windows Update history and its timestamp is unverified. The driver storm noted above was invisible to the method I used.
• AV generally — Windows Defender is genuinely not running, so "ruling out Defender" is vacuous on this host. That does not rule out AV as a factor; it only means the wrong product was checked.

There is no OS-level crash on this machine at any point: no Event 41 / 1001 / 6008, no MEMORY.DMP, no minidumps, and uptime is continuous from 2026-07-29 23:20. Whatever happened at 02:47 was contained to this application.

Root cause identified — see this comment. Electron 42.7.0 does not honour app.disableHardwareAcceleration() on Windows (fixed in 42.7.1); the GPU process then loads vk_swiftshader.dll, which Code Integrity Guard rejects because the MSIX ships no AppxMetadata\CodeIntegrity.cat. The trigger analysis in the body of this comment is superseded.

(Rewritten 2026-08-01. An earlier version of this comment carried its own errors — it misquoted my request #1 and repeated a claim about the AV component that further checking refuted. Rather than stack corrections, I ran an independent verification pass over every factual claim in the original report and folded the results into that comment directly. This note now just records what changed and why, so the edit history is auditable.)

I put each factual claim in my report above through a separate adversarial check against the live machine — the instruction being to refute the claim, not confirm it. Five of eight did not survive intact. Listing them because a reader who saw the first version deserves to know which parts moved, and because two of them are the kind of error worth naming out loud.

| Claim | Verdict | What was wrong |
|---|---|---|
| vk_swiftshader.dll is SwiftShader's Vulkan ICD | confirmed | — |
| …therefore "fall back to software rendering" is circular | refuted | Chromium ships SwiftShader in every build. It was bundled, not active — the running GPU process carried no --disable-gpu / --use-angle=swiftshader (0 of 15 command lines). Asking for a software fallback is a real state change, not a no-op. It remains true that this particular fallback path was unavailable while the DLL was blocked, which is what request #1 now says. |
| AV provider is the sole registered AMSI provider | partly wrong | It is sole for 64-bit processes. A second registration exists in the 32-bit hive (WOW6432Node\...C92 → antimalware_provider32.dll). |
| …and it therefore never loads | wrong | It is loaded successfully in ~25 live processes right now. Only the load into svchost.exe is rejected. My first version implied AMSI was broken machine-wide. It isn't. |
| Its Authenticode signature is valid; rejection is at a higher bar | confirmed | — |
| The two DLLs failed different signing levels (Windows vs Microsoft) | unverifiable now | The Bitdefender half is confirmed across all 372 surviving events. The Claude half rests entirely on my own verbatim capture at 08:33 — the log has since rolled and the record is gone, with no archive. Stated as provenance in the main comment rather than presented as re-checkable. |
| Package is "manifest-registered"; ~5 of 6 packages lack a .cat | wrong on both counts | It is Developer-signed and sideloaded (SignatureKind: Developer, IsDevelopmentMode: False, AppxSignature.p7x present) — manifest-registered would mean SignatureKind: None and no signature blob. And "5 of 6" was an unrepresentative draw: the real rate is 90 of 163 packages (55.2%), and it tracks signing kind — Store-signed packages have the catalog in 66 of 67 cases, Developer-signed lack it in 12 of 18. The conclusion (the 3010 warning isn't the root cause) may still stand, but not on the reasoning I gave. |
| main.log shows exactly one GPU crash | confirmed | — |
| Log capped at 1 MB / ~50 min, now raised to 64 MB | confirmed | — |
| Memory and Windows Update correctly ruled out | wrong | "Ample free RAM" was a post-hoc reading and inaccurate (commit charge at 90.9% of limit). The sound evidence is the absence of Resource-Exhaustion-Detector events. And Get-HotFix — the method I used — doesn't list driver updates, which hid a driver storm on 2026-07-29 (~90 failed attempts including the AMD graphics driver, amdkmdag.sys registered from two different driver stores that evening, ~27 hours before the crash). |

Two things I'd draw out of that:

The AMSI theory is weaker than I presented it, and I've said so in the main comment. The provider's rejection is constant and confined to one host process; Claude's DLL failed once. That pattern argues against the collateral-damage mechanism I proposed, not for it.

I had omitted a materially relevant environment fact: this is a hybrid-graphics laptop (NVIDIA RTX 5070 Laptop + AMD Radeon 610M integrated), with a recent, partly-failed graphics driver update. For a GPU-process crash that is arguably more relevant than anything I originally wrote about, and it is now in the Environment section. I have no evidence tying it to the crash — no TDR events, nothing GPU-related in the System log at 02:47 — so I raise it as an unexamined lead rather than a theory.

None of this changes what the issue is about. Whatever blocked that DLL, the application's response was to terminate the whole process tree and take three live sessions with it. That part needed no correction.

Root cause found — and it reproduces

Third occurrence on this machine, this time with the Code Integrity log enlarged beforehand so nothing rolled. Every link below is backed by a direct measurement on the host; no inference steps are left open. This supersedes the trigger analysis in my two comments above, which was wrong.

The chain

User sets isHardwareAccelerationDisabled: true
  → Claude Desktop calls app.disableHardwareAcceleration()
  → ★ Electron 42.7.0 bug: does not fully disable GPU on Windows
  → GPU process spawns anyway; WebGPU remains available
  → Preview pane creates a session preview → WebGPU requestAdapter()
  → software path → loads the Vulkan software ICD = vk_swiftshader.dll
  → GPU process runs under Code Integrity Guard
  → vk_swiftshader.dll is Anthropic-signed, not Microsoft-signed
  → MSIX package has no AppxMetadata\CodeIntegrity.cat to vouch for it
  → DLL rejected → GPU process creation fails ×5 → browser process terminates

Evidence per link

1. Electron version — the app ships 42.7.0. From the package itself, app\version:

42.7.0

Electron 42.7.1 release notes:

"Fixed app.disableHardwareAcceleration() not fully disabling GPU hardware usage on Windows starting from Electron 38."

So on 42.7.0 the setting is accepted and does not take effect. That is why disabling hardware acceleration did not prevent the crash — it never actually applied.

2. The GPU process runs under Code Integrity Guard. Get-ProcessMitigation on the live GPU process:

BinarySignature:
  MicrosoftSignedOnly      : ON
  AllowStoreSignedBinaries : OFF

MicrosoftSignedOnly: ON is literally what the event text means by "Microsoft signing level requirements."

3. The blocked DLL is Anthropic-signed, and nothing vouches for it.

vk_swiftshader.dll
  Authenticode : Valid
  Signer       : CN="Anthropic, PBC", O="Anthropic, PBC", ...
  IsOSBinary   : False

For an MSIX package, AppxMetadata\CodeIntegrity.cat is what normally grants package binaries the elevated signing level. This package has no AppxMetadata directory at all (Developer-signed sideload; SignatureKind: Developer, AppxSignature.p7x present). Hence the same-instant 3010:

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

I previously dismissed that 3010 as chronic background noise. That was wrong. Across 165 minutes of log it fires exactly three times — all three within the same second as the crash. It is not noise; it is the missing link in the validation.

4. The trigger is the preview pane, and it is deterministic. Across the entire renderer log, WebGL/WebGPU initialisation appears at exactly two timestamps — both crashes, nothing else:

2026-08-01 02:47  →  23 events   (crash #1)
2026-08-01 10:41  →  23 events   (crash #3)

And immediately before the second:

10:41:50  [Preview] Created session preview context {previewId: 'preview-local_ac266265-...'}
10:41:55  23 × WebGL/WebGPU events → GPU process gone, exitCode 101457950 (0x060C201E)
10:41:55  [Preview] capturePreviewScreenshotIfChanged failed: UnknownVizError

Five seconds from preview context creation to GPU-process death.

Two independent fixes, either sufficient

1. Bump Electron to 42.7.1. The user-facing "disable hardware acceleration" setting then actually works, and the WebGPU software path is never entered.
2. Ship the MSIX with AppxMetadata\CodeIntegrity.cat. Anthropic-signed binaries then satisfy Code Integrity Guard, and the DLL loads regardless of which rendering path is chosen.

(1) is the smaller change. (2) removes the whole class — any Anthropic-signed DLL loaded into the CIG-protected GPU process is currently exposed to this, not just SwiftShader.

Verified workaround, for anyone hitting this now

Launching the app with an explicit --disable-gpu — the same thing the Electron fix does internally — resolves it on this host:

• GPU subprocess falls to --use-angle=d3d11-warp-webgl
• vk_swiftshader.dll is not loaded by any process
• Zero 3010/3033 events since the change
• Package status stays Ok; no new crash dumps; no GPU fatals

No security mechanism has to be weakened to achieve this — Code Integrity, the GPU sandbox, and AV all stay on. Anyone tempted to "fix" this by disabling Code Integrity or passing --no-sandbox should not: it lowers security and does not address the cause.

Corrections to my earlier comments

For the record, since I posted them: the anti-malware/AMSI correlation I described was not the cause. At the moment of the third crash the AMSI event count was one — Claude's own. The bursts sit over an hour either side. That line of analysis is dead, and the two comments above are corrected accordingly.

Also: main.log alone under-reports this. It records "GPU process gone" but not the subsequent fatal, so a reader of that log concludes the app survived. The crash dumps and the AppModel 0x3CFC records show otherwise. If the crash reporter surfaced the Code Integrity state and the fallback-exhaustion path, this would have been a ten-minute diagnosis instead of a day.