One morning the PC was sitting in BIOS. Not booting, not failing to boot — parked in the firmware screen with a USB stick plugged in and the hard drive first in the boot order, waiting for somebody to notice.
The lazy explanation is “it rebooted and picked the wrong device”. That explanation is wrong often enough that I asked for the actual trail instead of the plausible one.
Windows keeps a record of unexpected shutdowns, and this one had an Event 41 bugcheck code of 340 — storage class, the family of codes that means the machine went down in a way the storage stack was involved in. That is a direction, not an answer. The answer was in the firmware history.
The SSD was a Samsung 990 PRO, and that model has a firmware lineage with a documented history of exactly this: drives that drop out under load, BSODs that get blamed on everything except the drive, and firmware updates that quietly fix them. A machine that reboots into firmware with a storage-class bugcheck and a 990 PRO inside it is not a mystery, it is a known shape. But you only see the shape if you look up the model instead of the symptom.
Behind that was the trigger. A Windows Update restart had started the sequence — the update was the thing that asked the machine to reboot, and the reboot is where the drive misbehaved. Which means the update was innocent and also the reason we found out: it forced an event that the machine had been failing intermittently at for a while without anyone noticing, because a reboot that happens when you are not looking looks exactly like a reboot.
Two other things were in the wreckage and both mattered. An old NSSM service, left behind by something I had stopped using, spamming errors on every start — not the cause, but noise that makes a log harder to read at the exact moment you need to read it. And a Macrium differential backup caught mid-run by the crash, rescued before it could leave a partially-written image that would have failed silently later, at the worst possible time.
The whole thing went into a playbook: check the bugcheck code and classify it, look up the specific hardware against known firmware issues before believing any other theory, check what Windows Update was doing at the time, audit the services that start with the machine, and then verify the backups that were running when it died.
The drive got its firmware update, the stale service went, and the interrupted backup was verified rather than assumed.
What I like about this one is that nothing in it is clever. Every step is something a careful person would do with the same information. The difference is that the machine did them in order, at 6am, without a theory it was emotionally attached to — and the first theory anyone reaches for, “it booted off the USB stick”, would have left a failing drive in place and a playbook unwritten.