Field notes / debugging
Nineteen calls, every time
My Claude desktop app died five times in one day, on a Legion 5 laptop. Memory, the graphics driver and a leftover process all cleared. What actually killed it was in a log nobody had opened, repeating at exactly the same size every time.
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.
19 calls, five timesThe 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.
one open, no burstOpening 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.
| Suspect | What the check found | Verdict |
|---|---|---|
| Memory pressure | Over ten gigabytes of system RAM still free at the moment checked | Ruled out |
| A graphics-driver reset | No driver-level event in the system log around any crash checked for one | Ruled out |
| A stale process from the last crash | Only an unrelated command-line helper still running afterward | Ruled out |
| Opening the preview pane, on its own | One open earlier the same day, no burst after it and no crash | Ruled out |
| A GPU power-preference warning | Checked five seconds either side, no burst and no crash following it | Ruled out |
| A loaded page running the probe to completion | A burst of exactly nineteen calls in the gap before every one of the five crashes | Real cause |
six confirmed, one maybeA 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.
| Occurrence | 19-call burst | Crash on record |
|---|---|---|
| The five in one daynineteen calls each | found | found |
| Every burst the same size, each one in the gap after the preview pane opened. | ||
| Five days earliernineteen calls | found | found |
| Same signature, same size, on a day with a crash already on the record. | ||
| Eight days earliernineteen calls | found | could not be established |
| The burst is there. The stretch of log that would carry the crash line had already rotated off disk, so it stays out of the count. | ||
zero crash dumpsWhat'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.