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

Status Open

Reported on v2.1.240

Maintainer reply None cached

Activity 0 comments · opened Aug 25, 2026

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:

the app deletes the previous crash report one second after its next start;
Crashpad uploads are off in the shipped configuration, so nothing was sent before that deletion;
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   <report-id>.dmp   "File create"           2026-08-24 22:05:44
USN 20516708616   <report-id>.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

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 <NULL> 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).

View original on GitHub ↗