[BUG] Windows Desktop destroys its own crash evidence — and the first GPU-process dump shows D3D12Core raising a non-continuable fail-fast (0x060C201E)

## Why this is not a duplicate of the `101457950` cluster

#81698 and its duplicates (#81159, #81836, #83478, #84992, #82967, #68049) report *that the GPU process crashes*. Every one of them carries logs and none carries a dump — and this issue explains why that is structural rather than accidental.

Three behaviours here are, as far as I can find, **unreported**:

1. the app **deletes the previous crash report one second after its next start**;
2. **Crashpad uploads are off in the shipped configuration**, so nothing was sent before that deletion;
3. **an entire crash class is never captured by Crashpad at all**, because it arrives via `RaiseFailFastException`.

I also have what that cluster is missing — **a dump of the GPU process itself** — so the root cause is included below rather than split off. Five crashes on one machine in 19 hours, reproducible on demand.

---

## 1. The crash report is deleted at the next start

NTFS USN journal, volume C:, verbatim:

```
USN 20507971232 .dmp "File create" 2026-08-24 22:05:44
USN 20516708616 .dmp "File delete | Close" 2026-08-24 22:36:05
```

`main.log` records `Starting app` at **22:36:04**. `settings.dat` and `metadata` are rewritten in the same second, and every `Starting app` in the journal carries the same signature — this is the ordinary startup path, not a one-off. Confirmed live on a later crash: report written 00:15:30, copied out by a scheduled job at 00:18:00, and gone from `Crashpad\reports\` after the 00:46 relaunch.

**Why other reports still show a dump present, which is consistent rather than contradictory.** Two accidents preserve it: the user inspects `Crashpad\reports\` *before* relaunching, or the app cannot relaunch at all. The second is common here — after a crash the package is left `Modified, NeedsRemediation` (5 of 5 crashes; 0 of 1 clean exits), so the app refuses to start and the evidence survives by luck. Fix the flag and the evidence disappears every time instead.

**Suggested fix:** retain the last N reports, or move them aside at startup rather than deleting. This is the cheapest change in the whole cluster, and it is what would make every other report investigable.

## 2. Uploads are disabled in the shipped configuration

`…\Packages\Claude_\LocalCache\Roaming\Claude\Crashpad\settings.dat`, 40 bytes, parsed against Crashpad's `Settings::Data` (`magic | version | options | padding | last_upload_attempt | client_id`):

```
options = 0x00000000 -> uploads_enabled bit = 0
last_upload_attempt = 0 -> not one upload ever attempted
```

Re-verified after each of five crashes; the file is rewritten at every app start and returns with the same value.

**This is not user configuration.** I checked every location the documented `disableEssentialTelemetry` setting could occupy — four user-level config files, all ten JSON configs inside the MSIX container, machine policy keys, and environment variables. **Zero occurrences of "telemetry" in any of them.** So either `uploads_enabled=0` is the packaged Windows default, or a consent path silently fails to set the bit. The Crashpad client ID is stable across repairs, so this is verifiable server-side; I can supply mine privately.

## 3. Crashpad cannot capture this crash class at all

The GPU process dies from `0x060C201E`, which is **an exception code, not an exit code** — a process killed by an unhandled exception exits with the exception code, which is why Electron logs it as `exitCode`. From the GPU-process minidump:

```
ExceptionCode : 0x060C201E (= 101457950)
ExceptionFlags : 0x1 EXCEPTION_NONCONTINUABLE
NumberParameters : 0
ExceptionAddress : ntdll.dll+0x1111B0
```

`RaiseFailFastException` deliberately bypasses SEH frames and the unhandled-exception filter, so **Crashpad's handler never runs**. Across five crashes Crashpad captured the *browser* process every time and the GPU process **zero** times.

Four mechanisms were needed to obtain one dump:

| Mechanism | Captured the GPU process? |
|---|---|
| Crashpad (shipped) | **no** — browser process only, 5/5 |
| WER LocalDumps for `claude.exe`, `DumpType=2` (armed and verified working with a deliberate test crash) | **no** |
| Windows Silent Process Exit monitoring | **no** — it captured 11 *other* `claude.exe` processes in the same second, not that one |
| procdump attached to the GPU process | **yes** — 68.5 MB |

Worth knowing on your side: asking reporters for "the crash dump" will keep returning browser-process dumps. Only an attached debugger gets this one.

---

## 4. Root cause: `D3D12Core.dll` raises the fail-fast

Module-mapped stack of the raising thread (no symbols available to me):

```
ntdll.dll+0x18A3D8
ntdll.dll+0x1111B0 <- the raise
ntdll.dll+0x11137B
D3D12Core.dll+0x31D7E8 <- the caller
ntdll.dll+0x8EDC1
ntdll.dll+0x8E3B9
ntdll.dll+0x9264A
```

Non-continuable, zero parameters, raised from ntdll on behalf of `D3D12Core.dll`: a deliberate unrecoverable abort by the **Direct3D 12 runtime**. The loaded copy is the system one, `C:\Windows\System32\D3D12Core.dll` version **10.0.26100.8972** — the app package ships **no Agility SDK redistributable**, so it is the OS runtime that aborts, not a bundled one.

**This is almost certainly not a GPU driver bug.** The same code is reported across:

| Issue | GPU | Arch |
|---|---|---|
| #81698 | NVIDIA RTX 5080 Laptop | x64 |
| this one | Intel Arc iGPU (Arrow Lake-HX) | x64 |
| #68049 | Qualcomm Adreno X1-85 | **ARM64** |
| (reported elsewhere) | AMD Radeon hybrid | x64 |

Four vendors, two CPU architectures, one identical code — and #68049 reproduced it across two different WHQL drivers **and** a clean reinstall, then was closed as invalid. I initially suspected my Intel adapter was the discriminating factor; the cross-vendor spread says it is not.

## 5. Why the app dies instead of recovering

The browser process **does** attempt to relaunch the GPU process. It fails below the app's own logging, which is why no relaunch appears in `main.log`. Millisecond-ordered, from `Microsoft-Windows-AppModel-Runtime/Admin`:

```
02:03:29.000 GPU process gone: exitCode 101457950
02:03:29.522 ┐
02:03:29.533 │ 5 × AppModel-Runtime Id=6, 0x3CFC:
02:03:29.535 │ "Cannot create the process for package because an error was
02:03:29.542 │ encountered while checking the machine-level package status"
02:03:29.544 ┘
02:03:32.987 Destroyed Desktop AppX container
```

Five relaunch attempts in 22 ms, every one failing in **MSIX packaged-process creation**. Only then does the browser execute its terminal `CHECK`:

```
ExceptionCode : 0x80000003 STATUS_BREAKPOINT
ExceptionAddress : Claude.exe+0x5E8A6C9
```

**Byte-identical across three independent browser-process dumps** (07:09:48, 00:15:30, 02:03:29). The same five-error burst appeared at the 22:05:43 crash, so it is reproduced, not a single observation.

So the missing fallback is not a compositing-policy choice — **recovery is attempted and is structurally impossible on the MSIX build.**

One detail that sharpens this: **`vk_swiftshader.dll` (5.5 MB) ships inside the app package**, as do `libEGL.dll` / `libGLESv2.dll` (ANGLE 2.1.27552). The software rasterizer is on disk and is not reached. The GPU child's command line carries no `--disable-software-rasterizer`, no `--disable-gpu-compositing` and no ANGLE override, so whatever forecloses the fallback ladder is in browser-process code or inside the opaque `--gpu-preferences` blob.

## 6. The crash flags the package (this is #84992's cause, not a separate fault)

| Event | Outcome | Package afterwards |
|---|---|---|
| crash ×5 | tree died | **flagged `Modified, NeedsRemediation`** — 5 of 5 |
| clean exit (full `beforeQuit`/`onQuitCleanup`) | graceful | **clean** — next run started normally |

Between one repair and the next crash there was **not a single Claude deployment operation**, so the flag arrives with no servicing involved. The AppX container is destroyed one second *after* the tree dies, and the first repair attempt then hits `AppModel-Runtime #67: Failed with 0x5 … current 0x280002, desired 0x480002`.

Recovery is then blocked by your own packaged service, confirmed three times: three auto-repairs, all `RegisterByPackageFullName` **with** `ForceTargetApplicationShutdownOption`, all `#400 success`, flag unchanged. Only Settings → Repair cleared it — specifically its **`Add`** step, which re-downloads and re-stages the payload. And at 22:08:40 the SCM recorded `CoworkVMService` failing to disarm its own recovery actions (`Access is denied`, cf. #88073) and then being reinstalled with `auto` start by the same Register — so the service re-arms itself on every registration, which is why the Repair block returns.

---

## 7. Trigger and reproduction

**Four of five crashes follow the creation of a preview surface by 4–8 seconds:**

| # | Time | Preview event | Gap | GPU RSS before → after |
|---|---|---|---|---|
| 1 | 07:09:48 | `[Preview] Created browser preview` | 8 s | 403 → 542 MB |
| 2 | 22:05:43 | `[PreviewContext] User tab denied — over cap { openTabs: 9 }` | 17 s | (last sample 55 s early) |
| 3 | 00:15:30 | `[Preview] Created browser preview` | 7 s | 165 → 311 MB |
| 4 | 01:31:11 | `[Preview] Created session preview context` | **4 s** | — |
| 5 | 02:03:29 | `[Preview] Created session preview context` | 5 s | 135 → 244 MB |

At crash 5, in the same second:

```
02:03:29 [info] GPU process gone: { reason: 'crashed', exitCode: 101457950 }
02:03:29 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
error: [Error: UnknownVizError] { [message]: 'UnknownVizError' } }
```

`capturePreviewScreenshotIfChanged` is a GPU read-back of the preview surface — matching #82967, and matching the independent report of crashes during Cloudflare Turnstile challenge rendering.

**Repro:** run an agent task that opens a web page in the Browser pane, on a run with live preview surfaces. Crashes 3, 4 and 5 were produced deliberately within three hours.

**Stated with its limits:** preview creation alone is not sufficient — six creations across the log produced two crashes on 08-24, and creations *without* a GPU allocation burst never killed anything. The consistent shape is *creation → a burst of roughly +110…+146 MB in the GPU process → fail-fast within seconds*.

**Uptime is not a factor:** the five runs lived 69 h 58 m, 5 h 01 m, 1 h 39 m, and two shorter ones. Run identity established by PID continuity, not by `Starting app` lines — the log contains suppressed second-instance launches that make those lines unreliable.

---

## 8. Full environment

| | |
|---|---|
| **Claude Desktop** | **1.34493.1.0** (MSIX, `Claude_…_x64`), installed from `downloads.claude.ai`, not the Store |
| **Electron** | **42.9.2** · **Node 24.18.1** |
| **Claude Code CLI** | 2.1.240 (bundled builds present: 2.1.235, 2.1.237) |
| **OS** | Windows 11 Pro **26200.9168**, DisplayVersion **25H2** |
| **Desktop App Installer** | 1.29.290.0 |
| **VCLibs / WindowsAppRuntime** | 14.0.33728.0 / 7000.785.2325.0 |
| **CPU** | Intel Core Ultra 9 275HX (Arrow Lake-HX) |
| **RAM** | 95.4 GB total, 63 GB free at time of writing; 49.7 GB free at crash 1 |
| **GPU in use by the GPU process** | **Intel Arc iGPU**, driver **32.0.101.8826** (2026-05-29), `PCI\VEN_8086&DEV_7D67`, INF section `ARLS_IG_wNext` |
| **GPU present but idle** | NVIDIA RTX 5080 Laptop, driver **32.0.16.1078** (2026-07-12), `PCI\VEN_10DE&DEV_2C19` |
| **Per-app GPU preference** | **none set for Claude** — Windows chose the iGPU |
| **System D3D** | `D3D12Core.dll` **10.0.26100.8972** · `D3D12.dll` 10.0.26100.8972 · `d3d11.dll` 10.0.26100.8972 · `dxgi.dll` **10.0.26100.9168** · `DXCore.dll` 10.0.26100.8972 · `ntdll.dll` 10.0.26100.8972 |
| **App-shipped graphics** | `libEGL.dll` / `libGLESv2.dll` **ANGLE 2.1.27552** (git `717d90d3aa17`) · `d3dcompiler_47.dll` 10.0.26100.7705 · **`vk_swiftshader.dll` 5.0.0** · `vulkan-1.dll` |
| **HAGS / TDR** | `HwSchMode`, `TdrLevel`, `TdrDelay`, `TdrDdiDelay` — **all unset (OS defaults)** |
| **Display at crash** | single panel, 2560×1440, over HDMI |

## 9. Ruled out, each measured

| Hypothesis | Verdict |
|---|---|
| GPU driver fault | **no** — same code on four vendors, two architectures; #68049 across two WHQL drivers + clean reinstall |
| TDR / display reset | **no** — `Display` and `nvlddmkm` events = 0 at every crash. (Caveat: `Microsoft-Windows-Dxgkrnl/Admin` does not exist on this machine, so the kernel graphics side is unchecked rather than clean) |
| Hardware / WHEA | **no** — 0 events |
| Out of memory | **no** — 49.7 GB free of 95.4 GB at crash 1; whole Electron tree 4,064 MB |
| GPU memory leak | **not the mechanism** — crashes at 542, ~202, 311 and 244 MB; a run that exited cleanly peaked higher (372 MB) than one that died |
| Long uptime | **no** — 70 h, 5 h, 1 h 39 m |
| Storage / power / graceful quit | **no** — 0 events; zero shutdown markers at any crash |
| DCOM 10016 `PerAppRuntimeBroker` denial near each crash | **background noise** — 13 occurrences from the Claude container since 2026-06-09, only 3 near a crash, one followed by a clean exit |
| StateRepository `SQLITE_MISUSE` | **chronic and unrelated** — 232 occurrences over 15.4 days against one flag event; `RepositoryManagerServerUpgrade` throws it on 130 of 130 runs |

## 10. Evidence

**Attached** (`claude-desktop-crash-dumps-20260825.zip`, 17.9 MB) — both processes of the same crash, 02:03:28 / 02:03:29:

```
GPU-process_claude.exe_20260825_020328.dmp 68,501,157 B
sha256 ec5bb8ad72568c6e51d2fad8df502597813fca4caef49391d12e0963ff1f81d7
browser-process_20260825_020329.dmp 35,830,992 B
sha256 5dbe725a00f1673b98b574e98b1ca1a8150a122137733cace003314d92cdb3d6
```

I scanned both before attaching, because a public tracker is forever. Neither contains **any credential** — zero API keys, JWTs, `Authorization` headers, `access_token`/`refresh_token` or password/secret literals, and no environment-variable name in either matches token/key/secret/auth/session/cookie. Neither contains **page or conversation text**: the Viz process holds command buffers, textures and driver state rather than DOM, rendered pixels live in VRAM which a usermode minidump does not capture, and the browser process is Electron's main process. Readable strings are filesystem paths, module names, the machine time zone, `D3D Background Thread` names, ICC colour-profile strings and Intel shader source.

### The one dump nobody has, including me — and it is probably the one you want next

The GPU process is where the abort *happens*, but it is not where the offending work *originates*. The renderer issues the compositing commands, Viz executes them through D3D12, and D3D12Core aborts. **A renderer dump would show what was being asked**, and no capture mechanism got one.

In the fatal run the compositing renderer was PID 33340 at 553 MB RSS. It was **not** captured — Silent Process Exit monitoring took eleven *other* `claude.exe` processes in the same second but not that one, for the same reason it missed the GPU process: both were torn down with the tree rather than exiting.

I can capture one on the next reproduction with a debugger attached to the renderer. **That dump would be the one carrying page content**, precisely because renderer memory is where DOM and text live — so it should go to you privately rather than onto this issue. Say the word and I will produce it.

**Also available on request:** browser-process minidumps from two earlier crashes (all three give the same `Claude.exe+0x5E8A6C9`), the USN journal extract for the report deletion, per-second GPU memory traces, event-log extracts with millisecond timestamps, and `main.log` spanning all five crashes.

The crash reproduces on demand here and the machine is instrumented with four capture mechanisms, so name any diagnostic and I will run it.

## 11. Related

#81698 (canonical for the crash itself) · #81159 · #81836 · #83478 · #84992 (package left unlaunchable — see §6) · #82967 (`UnknownVizError`) · #68049 (ARM64/Adreno, closed as invalid but is the same abort) · #88073 (`CoworkVMService` SCM recovery actions).

The report names no claude-code source file or test; start by checking whether the Windows desktop/MSIX packaging and Crashpad startup paths exist in this repository. Review Crashpad\settings.dat handling, Crashpad\reports\ retention, and the preview workflow around capturePreviewScreenshotIfChanged. Done requires a confirmed repository-owned fix and a reproducible test for the reported GPU-process failure or evidence-retention behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.