Whodunit: The Case of the Crashing Computer

If Maria could send desktop notifications, Saturday night's would have read:

"Vic… you are slaving this computer. It's quitting."

She can't. So instead the machine communicated the old-fashioned way: Edge froze mid-scroll, the model runner died with a stack trace, and my Event Viewer filled up with BlueScreen entries like a haunted guestbook. An evening of pilot testing — GitHub import, Q&A, PowerPoint templates — and everything around me kept falling over. Grabe (unbelievable).

So I did what you do when a machine misbehaves this theatrically: I treated it as a whodunit.

Suspect #1: the GPU. Verdict: framed. By a ghost.

Event Viewer was damning. LiveKernelEvent 141 — a GPU engine timeout — at 6:11 PM, 6:17 PM, and 7:48 PM, each paired with a bugcheck. Right in the middle of my testing session. Case closed, right? The graphics card is dying, the AI workload killed it, buy a bigger GPU, cry.

Except. Scrolling back, the same event appears every four hours. Every day. For weeks. Including 3 AM, when this computer is doing absolutely nothing except existing in the dark.

Then the actual tell: every single event carried the exact same kernel memory addresses. Windows randomizes those addresses on every boot — two real crashes on different days cannot share them. And the machine had rebooted between "crashes" that matched pointer-for-pointer.

These weren't crashes. Windows Error Reporting had one old GPU fault queued up — the folder timestamps say April 6 and July 6 — that it kept trying to upload to Microsoft and failing, because this machine is offline half the time. And every failed retry writes a fresh, scary, brand-new-looking crash event into the log. My computer has been performing the same two accidents, on schedule, like community theater, since spring.

The GPU didn't crash on Saturday. The GPU hasn't crashed since July. My event log is haunted, and the ghost punches a clock.

Suspect #2: Narra. Verdict: annoyingly innocent.

Surely the evidence engine hammering a 14-billion-parameter model all evening was involved somehow. So I pulled Narra's audit log — the append-only one, the log that can't be edited, the log I built specifically so nobody (including me) could tidy up history.

Zero failures. The whole session. GitHub import: clean. Q&A citing Narra's own source code: clean. Three PowerPoint renders into the corporate template: clean. It even regenerated a full deck at 8:08 PM — which, as we're about to see, was the worst possible minute on that machine — and finished.

My own software had an alibi, with receipts, in a format I designed to be tamper-proof. I have never been so pleased to lose an argument with a log file.

The actual culprit: a slow leak and one unlucky ask

Full confession first: I had completely forgotten that hardware is a finite thing. I was deep in pilot-testing mode, so naturally I also had every other project running at the same time — dev servers I'd started days ago and never stopped, a stack of VS Code windows, a browser holding every tab I'd "come back to later." The machine had never complained before, so I'd stopped thinking of memory as something I was spending. It turns out you can't forget about resources; you can only defer the invoice.

Here's the simple version of what I forgot. The machine has two memories: the graphics card's own 12 GB (where AI models want to live) and the computer's main 31 GB (where everything else lives). My writer model needs about 10 of those 12 GB — and when a model doesn't quite fit, Ollama quietly slides the overflow into main RAM. Slower, but survivable.

Pero (but) main RAM had spent the whole day being nibbled to death. The Next.js dev server — which is known to leak the longer it runs — had ballooned. VS Code was over five gigabytes. Edge held a few more. Windows' own leak detector had literally flagged the dev server and VS Code by name that evening, which is the operating system equivalent of pointing at someone in a lineup.

At 8:07 PM, Ollama tried to load a model, needed one more ~270 MB slice of RAM, and Windows said: there isn't any. The model runner died on the spot — that's a crash. Edge, starved at the same moment, chose to freeze instead — that's a hang. Same cause, different coping styles. Honestly? Relatable.

Ollama then evicted everything, retried with the room it had just cleared, and succeeded — which is why Narra's log stayed clean while the machine around it was quitting. Maria was right. I was slaving the computer. It quit. lol.

What this earned: a detective you can run

A dozen manual queries across four different logs solved this once. That's not a repeatable skill, that's an evening. So the whole investigation is now one command:

uv run python scripts/crashcheck.py --workspace .narra-gcs

It checks RAM and the known leakers, disk, VRAM, whether a model is secretly spilling into main memory, what Ollama's runner log recorded, which apps crashed or hung — and, my favorite part, it detects the ghost: kernel events with identical pointers across a reboot get labeled as stale re-reports of an old fault, with the real fault's date pulled from the report queue, instead of being reported as fresh GPU failures. It reads everything and touches nothing; every finding says what happened and what to do, command first.

The bigger lesson goes into the product queue: the machine itself is a dependency, and dependencies get health checks. narra doctor will grow RAM and VRAM headroom warnings so the next "it keeps crashing" gets caught before the session instead of diagnosed after it.

But the lesson that stuck is softer than an engineering ticket: even computers need rest and a buffer. Rest, as in — restart the things that have been running for days; a leak resets to zero the moment you let the process stop. Buffer, as in — the free memory you "aren't using" isn't waste; it's exactly what keeps the next ask from being the one that kills something.

I'd love to close with "and of course I protect my own rest too," but that would be the only uncited claim in this post. The truth is I'm writing this as someone who regularly closes the laptop at 3 AM and calls it dedication. The machine and I run exactly the same way — everything at once, no headroom, restart never — and it is really not good for either of us. The difference is that the machine was honest enough to quit. I just pour another coffee and call my leaks "passion projects." So the real fix isn't only in the product queue: a buffer isn't idleness, and rest isn't lost time. It's what keeps the next ask from being the one that breaks something. That applies to 31 GB of RAM, and it applies to me.

So now: restart the dev server before a long AI session, leave the machine some room to breathe — and if the event log says something crashed at 3 AM, ask who was really running past their limits at that hour. Lately the answer is both of us.