Desktop app dies silently after GPU process crash (exitCode 101457950) when a Browser-pane page requests a WebGPU adapter - Windows 11 / AMD APU

Status Closed — duplicate

Maintainer reply None cached

Activity 1 comment · opened Aug 21, 2026 · closed Aug 25, 2026

Summary

On Windows 11 with an AMD APU, the Claude desktop app dies silently and completely — no error dialog, no window, no tray icon — whenever a page loaded in the Browser/preview pane calls requestAdapter() (WebGPU). The GPU child process crashes with a fixed exitCode 101457950 (0x060C201E), the main process never recovers, and the app has to be restarted manually.

This reproduced 4 times in ~5.5 hours, exclusively on app version 1.32885.1. The same machine has 33 prior boots across four earlier versions with zero occurrences.

The crash is not a display-driver TDR and not host-memory exhaustion; evidence for both exclusions is below.

Environment

Symptom

The app window disappears. Nothing is left running. main.log ends abruptly at the GPU line with no shutdown marker, and the next entry is a cold Starting app from the manual restart, 3–15 minutes later.

For contrast, all 6 clean exits in the same log are explicitly marked (Windows session ending (shutdown|close-app) - quitting the app, beforeQuitForUpdate handler fired). The 4 crash restarts have no such marker.

A native crash report is uploaded on the next boot — 4 of them, 1:1 with the 4 GPU crashes, each firing 1–2 s after the following cold start, with type: 'Unknown', value: 'No message', stack: undefined. These are the only such events in 173 hours of logs. That is the evidence the whole app died rather than just the GPU child.

Evidence chain

Two log files are involved. The renderer-side file is the one that identifies the trigger, and it is easy to miss if you only read main.log.

Renderer — `%APPDATA%\Claude\logs\unknown-window.log`

Identical shape before every one of the 4 crashes:

2026-08-20 19:14:49 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
2026-08-20 19:14:50 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-20 19:14:50 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-20 19:14:50 [warn] A valid external Instance reference no longer exists.
2026-08-20 19:14:50 [warn] A valid external Instance reference no longer exists.

Counts across the entire 992-line file:

| Message | Total occurrences | At the 4 crashes | Elsewhere |
| :--- | ---: | ---: | ---: |
| powerPreference … requestAdapter() on Windows | 8 | 8 (4 pairs) | 0 |
| OTS parsing error: … WOFF 2.0 … | 4 | 4 | 0 |
| A valid external Instance reference no longer exists. | 6 | 6 (at 3 of 4) | 0 |

A valid external Instance reference no longer exists is Dawn reporting that the WebGPU Instance is gone — i.e. the GPU-side object died while the renderer still held a reference.

Main — `%APPDATA%\Claude\logs\main.log`

In the same second as the Dawn messages:

2026-08-20 19:14:50 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

All four occurrences carry the identical exitCode 101457950 (0x060C201E). It is the only exitCode value present anywhere in the file.

Timestamps

| # | Crash (local) | Preview tab opened before crash |
| :--- | :--- | :--- |
| 1 | 2026-08-20 19:14:50 | 8 s |
| 2 | 2026-08-20 20:37:10 | ~4 min |
| 3 | 2026-08-21 00:20:50 | 8 s |
| 4 | 2026-08-21 00:45:03 | ~3 min |

All four occurred with an active Browser/preview pane. In crash 4 the loaded page was an external site whose CSP violations name facebook.com/tr and leju.com.tw; other sessions in the window loaded pages pulling api.maptiler.com and maps-vector.* — vector map tiles, a common WebGPU/WebGL consumer.

What is ruled out

Display-driver TDR — ruled out. Zero Event ID 4101 across the entire retained Windows System log (not just the crash window), zero events from any Display / amd* / nvlddmkm / LiveKernelEvent provider, and C:\Windows\LiveKernelReports is empty. A driver reset would have logged 4101.

Host RAM / commit exhaustion — ruled out. At the four crashes, system free memory was 5,059 / 7,709 / 6,083 / 7,378 MB out of 15,720 MB, and app tree RSS was 1,619 / 3,830 / 1,337 / 1,655 MB. The electron_gpu process RSS never exceeded 217 MB across 9,839 samples. Crucially, the control group runs the other way: 221 samples recorded system free memory below 500 MB (as low as 15 MB) and produced zero GPU crashes. Microsoft-Windows-Resource-Exhaustion-Detector has never fired; pagefile peak usage is 63 MB against an 18,432 MB limit.

**VRAM is not ruled out.** No log records GPU memory. On this APU only 512 MB is reported as dedicated, with the rest shared from system RAM, so a WebGPU allocation failing under VRAM pressure remains a live hypothesis that the available telemetry cannot exclude.

Absence of a crash dump proves nothing either way. %APPDATA%\Claude\Crashpad holds only a 0-byte metadata and a 40-byte settings.dat — no .dmp. Chromium suppresses WER via Crashpad, and a TerminateProcess-style kill raises no exception and so produces no dump regardless of cause.

Correlation caveat, stated honestly

main.log also shows [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } exactly 4 times, 1–2 s before each crash, 4/4 with no false positives. It looks compelling, but it should not be read as the cause:

main.log has no sub-second timestamps, so a 1–2 s logged gap cannot establish ordering against an asynchronously-delivered child-process-gone event.
Three oauth log templates are equally 4-for-4 inside the same 5 s pre-crash window.
Allowed preview subresources are never logged at all, so there is no denominator and no valid negative control.

The blocked xhr and the WebGPU adapter request are best read as co-symptoms of the same page load. The renderer-side Dawn/WebGPU sequence is the stronger signal because it is in the same second as the crash and has zero base rate elsewhere.

Suggested repro

Windows 11 on a single-GPU AMD APU.
Open the Browser pane and load an external page that uses WebGPU (a MapTiler / MapLibre vector map is a reliable example).
Watch unknown-window.log for requestAdapter() followed by A valid external Instance reference no longer exists.

Expected: the GPU process recovers, as Chromium normally does.
Actual: GPU process gone … exitCode 101457950, and the main process never comes back.

Notes for anyone triaging from similar reports

The 10 MiB main.log truncation described in other threads did not apply here — the file was 7.2 MB and still being written, so the crash was fully recorded.
Repair from Windows app settings is unlikely to help: nothing here indicates a damaged install.
Per-app GPU preference is not an available workaround on a single-GPU machine.

Attachments available on request

Redacted extracts of main.log (4 crash blocks with 30 lines of context each) and the correlated unknown-window.log lines. Organisation IDs, client IDs, tokens and paths have been removed.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗