Claude 桌面應用程式一天內五次崩潰前均出現 19 次 WebGL 呼叫

Claude's own desktop app kept dying outright, the whole window gone, no warning. Not a hang, not a
freeze that eventually recovers: the process behind the screen simply stopped existing. It happened
five times in one day alone, on a Lenovo Legion 5 laptop. Each one logged the identical signature:
the GPU process reported gone, reason crashed, exit code 101457950, every single time.

I ruled out the obvious suspects first, one at a time, and each one cleared.

Memory looked fine going into the crash: system RAM had over ten gigabytes free at the moment
checked, nowhere near exhausted. The graphics driver never logged a reset around any crash checked
for one, no driver-level event in the system log at all. Nothing was left over from a
previous crash either: once the app went down, the only thing still running afterward was an
unrelated command-line helper, so there was no stale process holding a lock that could explain the
next crash starting from a bad state. Three clean suspects, three dead ends.

The pattern that was hiding in a different log entirely

The actual cause turned up somewhere nobody was looking directly for it: a completely separate log
file, tracking browser-level activity rather than the app's own process events. A specific WebGL
call — getInternalformatParameter, the kind a web page makes to ask the graphics driver about
supported texture formats — showed up in a tight burst right before every crash. Not once or twice. Every single time, across five
separately timed occurrences spanning hours, that burst was exactly the same size: nineteen calls.
Never eighteen. Never twenty. A fixed number repeating exactly, five times, is not what a random
failure looks like. It's what a fixed sequence running to completion looks like, every time it
runs at all.

The trigger was a browser preview pane inside the app, opened by whatever the user was doing at the
time, loading a page that happened to run a script probing WebGL capabilities as part of its own
fingerprinting or feature detection. Each crash landed five to six seconds after the preview pane
had opened. The nineteen-call burst sat right in that gap, every time.

1. Start — the browser preview pane opens.
2. In the gap — a page inside it runs nineteen WebGL calls.
3. 5-6s later — the GPU process is gone.

The same three steps behind all five crashes in one day. The nineteen calls sat in the gap between
the pane opening and the process dying, every time.

Opening the pane wasn't enough by itself

One earlier preview-pane open that same day had no burst afterward, and no crash. That's the detail
that rules out "the preview pane itself is the problem." The pane can open cleanly all day. What
kills the process is specifically a loaded page inside it running that exact probe sequence to
completion, not the act of opening the pane at all.

A separate warning line, about a GPU power-preference option being ignored on this platform, showed
up earlier that same morning with nothing bad following it: checked five seconds either side, no
burst, no crash. That same warning also appears at the very top of every one of the actual crash
sequences, immediately before the nineteen calls start. So the warning by itself isn't the trigger.
It's a harmless line that happens to sit right before the real trigger, whenever the real trigger
runs at all, which made it worth ruling out on its own rather than assuming it was just noise.

A sixth possible crash, found and deliberately left uncounted

Going back further in the logs turned up one more candidate burst, eight days before the day with
five crashes, and it doesn't get counted. Here's why. The burst is there, the right size, in the
right log. What isn't there is the matching crash line. The specific stretch of log covering that
exact window had already rotated out of every log file still on disk by the time anyone went
looking. What's on disk instead is a fresh app launch about nine minutes after the burst, with the
previous launch recorded two days earlier, meaning something ended that long-running session before
the new one started, just not on camera. A restart nine minutes after an unexplained burst, with
nothing describing how the previous session actually ended, is consistent with the same crash. It
is not proof of it. Six of the bursts line up with a confirmed crash: one five days earlier, and
all five from the day of the five crashes. The unconfirmed one from further back stays unconfirmed,
named as a maybe rather than quietly rounded into the count. If it belongs in the total,
that's a call for whoever owns the running tally next, made with the gap in the evidence attached,
not asserted on the strength of a nine-minute coincidence alone.

Seven bursts in the logs, six of them beside a crash on the record. The seventh is left out of the
count rather than rounded into it.

What's left open

No crash-diagnostic file was produced by any of the five crashes: the folder where the app would
normally leave one after a hard failure stayed empty every time. The bug is filed upstream as
anthropics/claude-code#80444, alongside
around ten duplicate reports, reproduced across NVIDIA, AMD, and Intel graphics on both Windows 10
and 11, so it isn't specific to this one laptop. All of them are still open. I put a comment on
that issue with this machine's own findings, and the thread is still getting daily activity from
other people hitting the same crash. In the meantime the only mitigation that actually works is not
opening that specific browser preview feature at all, and driving anything that needs a real
browser through a separate, standalone tool instead.

None of this was hard to check, once the search moved from guessing at causes to reading the log
that actually recorded what happened.

The memory number, the driver log, the leftover-process check: all fast, all clean, all wrong turns
that had to be ruled out anyway before the real pattern, sitting in a log nobody had thought to grep
yet, showed up in exactly the same shape five times in a row.

Originally published at thekilted.dev/nineteen-calls-every-time.