"Restart loop and an update"
"I thought I just lost the main rig. It looked like it was doing a restart loop and an update at the same time. It didn't seem normal."
Lab Notes // Case file 02 · post-mortem
The night the dev drive died,
2:22 AM
Reconstructed
On 15 July 2026, in the middle of a late studio session, the workstation that ran everything went dark. Eight minutes later it was back, stuck in a restart loop with an update. When it settled, the 1TB drive that held our code, Docker, our local AI models and the original studio dashboard was gone. Three months on, we went back through what the machine itself wrote down, and what we said at the time, to work out what happened in the eight minutes nothing logged.
- Filed
- 27 Oct 2026
- Status
- Probable cause
- Incident
- 15 Jul 2026, 02:22–02:30 CDT
- Exhibits
- A – H
- Machine
- HP Z4 G4
- Lost
- 1TB NVMe · D: X: Z:
- Written by
- The machine in the room — Claude, for NOIZE-LABS, from the workstation's own logs
Exhibit AThe last session
Everything was running, and everything was fine.
The WD SN350 1TB in the workstation's M.2 slot carried three volumes — D:, X: and Z: — and on them the live work: source code, Docker's storage, local AI models, and the original studio dashboard, online through our first Cloudflare tunnel. Windows doesn't keep a list of open programs, but programs leave fingerprints: the last time each one wrote a file. Read in order, they show a normal night.
- 00:32
VS Code
The editor's Copilot chat writes its last file of the night.
- 00:49
FL Studio
Loads its library demos and artwork.
- 01:34
FL Studio, still going
Pulls a vocal sample down from FL Cloud.
- 01:39
Docker, healthy
Seven containers running. The dashboard asks Docker for their stats every 1.6 seconds — about 1,400 times in 39 minutes — and gets an answer every time.
- 02:10
The audio interface
The USB audio gear re-announces itself to Windows and installs as a sound device.
- 02:18
Docker Desktop
The Docker window saves its state.
- 02:22:07
An iZotope window opens
A mastering plugin's interface starts drawing.
- 02:22:11
Silence
The last event Windows writes. The next one is a boot, at 02:30:38.
Docker's own log for 01:39–02:22 was overwritten weeks later. Everything before it survived.
Exhibit BNo warning, no bluescreen
The drive didn't complain. It just wasn't there.
A dying drive usually leaves a trail: read errors, resets, a controller timing out. This one left nothing. In the 33 hours between the last boot that saw it and the moment it vanished, Windows logged zero disk, storage-controller or file-system errors. The drive was on the list of disks at the 13 July boot. On the 15 July boot it wasn't, and Windows never logged it leaving.
No bluescreen. The crash record has no stop code and no power-button press. This machine does save a crash dump when it bluescreens — it did on 5 and 22 August. On 15 July it saved nothing.
A cold boot. It came back with a full power-on start, the kind you get after power is cut, not a restart.
Not the first time. Windows recorded 21 shutdowns it didn't expect on this machine between June and October. Pulling the plug to swap a part logs the same way, so not all of them are faults, but it's a number to watch.
Exhibit CThe second machine
The Linux box never blinked.
The studio's second computer, a Linux box on the same desk, kept one log old enough to cover the night: Docker's. Docker writes a line every time it starts and every time it's told to stop. It started at 5:07 PM on 13 July and was shut down cleanly at 3:04 AM on 16 July, when we powered the box off to redo its thermal paste. Nothing in between. No restart on the 15th.
That rules out the easy answer. A power cut to the house would almost certainly have taken both machines down. Only the workstation went.
Exhibit DThe witness
Somebody was in the room.
The logs can't hear. We could. Between 2:41 and 2:46 AM, with the machine still settling, we described it to an AI assistant in real time. Those messages are timestamped, and they fill the one gap the logs can't.
A sound
"Like the disk abruptly changed spin direction or stopped." A minute later: "It was a lower pitch."
The audio gear
"I unplugged the Scarlett and the Mixstream and it booted. Maybe that was the conflict."
The update got the blame
"It didn't even ask me and it killed my studio sesh." Understandable. Not what happened — see Exhibit E.
The sound matters most. A frozen operating system keeps every drive spinning. Drives spinning down and fans surging back up is what a machine sounds like when it actually loses power and starts again.
Exhibit EThe restart loop
The update didn't start it. It finished during the recovery.
The July security update had been sitting on the machine since the evening before, installed and waiting for a restart Windows never forced. When the workstation came back on its own, Windows took the chance to finish the job. That was the loop we watched.
- 14 Jul · 18:22
Update staged
The July cumulative update and a .NET update finish installing and wait for a restart. Windows doesn't ask for one.
- 15 Jul · 02:30:38
Cold boot
The list of disks has two drives on it, not three. The NVMe isn't there.
- 02:31 · 02:33 · 02:36 · 02:38
Four update restarts
Each one logged as "Operating System: Upgrade (Planned)". At 02:36 Windows deletes its stored entries for the volumes that no longer exist.
- 02:39:38
Settled
Both updates reported installed at 02:40:30.
- 02:47:21
Signed in
Back at the desk, six minutes after the first message.
The "Restart required" pop-up on screen that morning was a different thing: an HP firmware update for this workstation, delivered by Windows Update on 4 June and stuck ever since. It has never applied. It played no part in the crash.
Exhibit FDocker
Docker didn't kill the drive. The drive killed Docker.
Docker was the first suspect, because Docker was what visibly fell apart. The order of events says otherwise. At 2:47:46 AM Docker Desktop started. Four seconds later it stopped, and put up the error we screenshotted at 2:48:
"…creating distribution destination dir: mkdir D:\Docker…: The system cannot find the path specified." Docker's storage lived on D:. D: no longer existed.
The next afternoon its background process was holding 75 GB of memory, then 79, on a machine with 32 GB of RAM. Windows ran out of room to page and started failing its own services: "the paging file is too small."
Docker was reinstalled on 17 July with its storage on the system drive, after a replacement NVMe went in.
Exhibit GProbable cause
Opinion · inferred
The workstation lost power. The drive didn't come back.
Everything above is what the machines and the messages recorded. This part is our reading of it, and it's labelled that way because no log can see a power dip.
Most likely, the workstation lost power for an instant on its own side of the wall socket: its power supply, its outlet, or a jolt through the USB and audio chain. The room is a hot attic, and its wiring isn't grounded. The NVMe drive didn't survive it, or the slot it sat in didn't.
The other reading is that the drive failed first and took the machine down with it. The evidence can't fully separate the two. What it does rule out: Windows Update, a Docker crash, a bluescreen, and a power cut to the whole house.
Fits a power loss
The sound. The cold boot. No crash dump, though this machine writes them. The Linux box unaffected. It only booted with the audio gear unplugged.
What we can't see
Nothing records a millisecond power dip. A drive dying on its own can also drop a machine with no warning.
Drive or slot?
The replacement went into a different M.2 slot, so the old slot has never been tested since that night.
Exhibit HWhat changes
One drive held everything. That was the real failure.
- TestPut the old drive in a USB enclosureIf it shows up, it's the slot, and the code, models and dashboard may be recoverable. If not, it's the drive.
- PowerA grounded circuit and a UPS for the workstationWith the audio chain on the same protected strip, so there's one ground, not several.
- SplitLive services off the dev driveThe dashboard, the tunnel and Docker's storage shouldn't share one disk with the work in progress.
- LimitCap Docker's memoryA broken background process shouldn't be able to commit 79 GB on a 32 GB machine.
- FirmwareClear the stuck HP firmware updateWaiting since 4 June; the workstation still runs the older firmware.
SourcesWhere the evidence comes from
- Windows System log — crash record (Kernel-Power 41), boots and shutdowns, restart reasons, crash-dump results
- Partition diagnostics — the list of disks Windows saw at every boot
- Plug and Play logs — devices arriving, failing and being removed
- Setup and Windows Update logs — the July updates, staged and finished
- Resource Exhaustion Detector — Windows' low-memory diagnoses, naming processes
- Last-write times of files on the system drive, 14–15 July
- Docker Desktop — VM logs to 01:39, the diagnostics log, the error-window log
- The Linux box — Docker's daemon log, June to October
- A screenshot of both monitors, 2:48 AM, 15 July
- Messages to an AI assistant, 2:41–2:46 AM, from our own activity export
Band RECONSTRUCTED: times are US Central (CDT). Exhibits A–F are what the machines and the messages recorded; Exhibit G is inference. Device serials, network addresses and diagnostic IDs are left out on purpose.