Housekeeping With a Co-Worker
I heard a pop.
Windows plays that little chime when a device connects or disconnects. It's a small sound, but this one had been showing up randomly for a few nights, and when it did it took a slice of input latency with it. Enough to break immersion in a game. Not enough to write a bug report about.
So instead of writing a bug report I turned to my co-engineer and said "find the device that's causing this."
The pattern
If you've never worked with an AI as a genuine collaborator on system-level stuff, the shape of it is worth describing. It's not "ask the chatbot a question." It's more like this:
- I say what I'm seeing.
- It runs a battery of read-only checks — event logs, PnP snapshots, driver signatures, watcher processes — all at once, in parallel where possible.
- It surfaces what stands out.
- I decide what to touch.
- If a fix needs admin, it stages an elevated script, tells me what it will do, and I approve the UAC prompt when it appears.
The point is not that the AI knows more than I do. It doesn't. The point is that it can look at seven surfaces simultaneously without getting bored. Human debugging is a series of one-thing-at-a-time hops. This is a fan-out.
The pop
The first pass on the phantom device-pop turned up three suspects. Two of them were orphaned virtual buses from a piece of software I hadn't consciously touched in a long time — leftover kernel-level plumbing that had never been cleaned up when the parent app updated itself. The third was a duplicate of one of my own kernel driver registrations, still enumerated by Windows even though the live copy sat one instance ID over.
None of them had drivers loaded. All of them were sitting in Error state. And Windows was retrying to bind a driver to each of them on a schedule — which produces exactly the pop-chime I'd been hearing, and briefly stalls the USB pipe every time it happens.
Cleaned up with three admin-elevated pnputil removals. The watcher captured the exact moments to the millisecond:
[23:04:15.235] REMOVE | <ghost bus 1>
[23:04:15.258] REMOVE | <ghost bus 2>
[23:04:15.259] REMOVE | <ghost bus 3>
Three lines of log for what would otherwise be a "yeah my machine's just weird" shrug.
The audit
While we were in there, I asked for a general housekeeping pass. Not because I had a specific worry — just because it felt like the right time.
Seven surfaces:
- Defender health and recent detections — is real-time protection on, is tamper protection on, has anything been caught lately.
- Loaded kernel drivers — anything unsigned, anything signed by an unexpected publisher.
- Autoruns — Run keys, startup folder entries, scheduled tasks not authored by Microsoft.
- WMI event subscriptions — the classic fileless-persistence spot; a nasty piece of malware can live entirely in WMI without ever touching disk.
- Listening ports — what's bound to the loopback, what's bound to the machine's real address, and what owns each socket.
- Recent executables — anything dropped into Temp, AppData, or Downloads in the last fortnight; unsigned counts double.
- Firewall and hosts file — the boring defenses that quietly do most of the work.
The full pass across all seven took under two minutes of terminal time.
Result: clean. A handful of things worth knowing about — not malware, but exposed surfaces I'd want to keep an eye on — and no actual compromise. The kernel driver list came back all-signed. WMI came back with only Windows' own default subscription. Hosts file empty. Firewall on. Defender fresh.
The one detection in Defender's history was a legitimate tool I use for automotive diagnostics that ships with a hardware ID unlocker — flagged as expected. Context-aware allowlisting rather than a real hit.
What I learned
- Parallel visibility is the actual superpower. I could have run each of those seven checks myself. But I wouldn't have. I'd have checked one, gone "seems fine," and moved on. Fan-out debugging catches the thing that only makes sense when you see three signals line up.
- The AI's role is to see, not to decide. Every action tonight that could change system state — remove a device, delete a registry key, disable a service — was staged, described, and approved by me. That's the workflow that keeps me trusting it. If I let it make those calls solo, I'd stop trusting it, and rightly.
- A five-second pop can hide a ten-minute problem. The chime was the visible symptom of orphaned kernel-level state. Finding the orphan wouldn't have happened without treating the pop as a real signal instead of a "just Windows being Windows" background noise.
- Housekeeping compounds. Cleaning up ghost devices, tightening what runs at startup, knowing what's bound to what port — none of it is glamorous. It's the same shape as changing oil. Machines that get it feel different to work on.
What's next
The watcher is still running in the background. If the pop returns tonight, we'll know within a millisecond exactly what caused it. If it doesn't, we've almost certainly found the source. Either outcome ends the investigation cleanly.
A quieter machine on the bench tonight. Debugged with Claude Code. Published at indigo-nx.com.