The Sound Came Back
Two days ago I wrote that a series of mysterious device-connect pops on Windows had almost certainly been traced to a corroded microphone dragging its USB hub into resets. The post ended cleanly. Either the sound stayed gone or the watcher would catch whatever came next.
Tonight the sound came back.
The last line
The first thing I checked was the log the watcher had been writing. It ended at exactly the moment I'd pulled the corroded mic out of the machine. Not a minute after, not five minutes after — the same second.
The watcher had died at the instant of its own diagnosis.
That's a very particular kind of embarrassing. The reason "the pops stopped after the fix" felt like confirmation was that the observing instrument stopped observing the moment the fix happened. The mic being pulled did generate a clean unplug signature — I saw that in the log — but everything after that was silence, and silence looks the same as success right up until the sound comes back.
Evidence, not proof. A signal captured once isn't a resolution; it's a data point.
Rebuild first, diagnose second
The very first thing I did was rebuild the watcher — fresh script, background process, five-minute heartbeat lines so I could tell it was alive even when nothing was happening. If tonight's chime cycle produced no log entries, that would still be information: it would mean the pops weren't PnP events at all and I was looking in the wrong place.
Then I asked the standard question of any diagnostic session: is there anything currently in an error state?
There was. A device driver on the machine was in CM_PROB_UNSIGNED_DRIVER — Windows' Code 52 — meaning it had installed successfully at some point but its digital signature was no longer being accepted. Windows was retrying to bind it every so often and failing every time, and every failure generated the same little pop-chime I'd been hearing.
Not the mic. Not the hub. A driver.
Why now
The driver in question was one I use for some internal tooling on this box. It's signed, but signed by me for testing — meaning it only loads when Windows is in a mode that accepts self-signed drivers, called test signing mode.
Test signing mode had been turned off recently. Between the mic diagnosis and tonight, I'd swapped it off to play something with kernel-level anti-cheat — those systems refuse to run when test signing is on, because a self-signed driver could plausibly be a cheating tool. Perfectly reasonable posture from their side. Not a bug in the anti-cheat, not a bug in my driver — just two features of the operating system doing what they were designed to do, and me forgetting that flipping the switch would strand my own driver in an unbindable state.
Every time Windows re-enumerated the machine, it tried to load the driver, failed the signature check, and popped the chime.
The sweep
Two commands, both admin-elevated, both plain pnputil:
pnputil /remove-device "<the instance>"
pnputil /delete-driver <the-inf-name> /uninstall /force
The first line evicts the device record. The second removes the driver package itself from the Windows driver store, so a subsequent enumeration can't re-spawn a fresh copy of the failed device from the same broken package. Skip that second step and the ghost comes back the next time something plugs in.
Both returned exit 0. Verification pass: the "problem devices" list was clean, and the driver store no longer contained the package. Silence in the log after that — the useful kind of silence, the kind you can actually trust because the instrument is still recording.
The tool
Around this point I realised I'd built the same diagnostic workflow three nights in a row: spawn a watcher, tail a log, run a snapshot of problem devices, grep the driver store, look for retries and duplicates. Every session started with a rebuild of the same setup from scratch.
So I built it as a proper tool instead.
PnP Scope — single-file Python GUI, tkinter, dark theme. Live event stream showing every device connection and disconnection in real time. Regex filter. ADD/REMOVE toggles. A button that snapshots the current problem-device list. A button that regex-searches the driver store. Save Log and Export CSV. Everything the ad-hoc script was doing, plus a proper interface, plus tooltips written for someone who has never opened it before.
It came together in about an hour, most of which was arguing with the WMI event subscription model until it delivered events reliably instead of dropping them into a runspace-of-nowhere. The first version silently missed the actual sweep event because the PowerShell subscription pattern I was using wasn't dispatching callbacks properly in a headless script. Threading it in Python with a proper COM initialisation per thread fixed it.
The tool caught its first useful thing about ninety seconds after I opened it: a game controller being plugged into the same USB hub the mic had been on, generating nine linked ADD events (composite device, four HID interfaces, four input aliases) inside 275 milliseconds. Green rows for the plug, red for the unplug five seconds later. Exactly the shape the ad-hoc log had — but on tap, without a rebuild.
That screenshot is thirty-six events across about sixteen seconds. Top block in red: a mechanical keyboard being unplugged, cascading through its composite device, all its HID interfaces, and its vendor-defined virtual endpoints. Middle block in green: the same keyboard coming back a few seconds later, this time re-enumerating with a different instance ID prefix because the parent hub had picked a new port assignment. Bottom two lines: the hub itself briefly renegotiating. Sixteen seconds of USB reality that would have been impossible to reconstruct after the fact, laid out in order and colour-coded for read speed.
What I learned
- An instrument that dies at the moment of its diagnosis proves nothing. Silence after a fix looks like success. It also looks like a dead watcher. The two are indistinguishable from outside the log, and the log is what tells them apart. Add heartbeats so a broken instrument announces itself.
- The fix that satisfies you is the one to be most suspicious of. The mic story on Monday was neat. It felt right. It had a millisecond timestamp signature. What it didn't have was continued observation. When a diagnosis feels satisfying, that's a reason to keep watching, not a reason to close the ticket.
- A driver in Code 52 makes almost the same noise as a hardware fault. Retry-loop pops sound identical to intermittent-connection pops. Both trigger the same Windows chime. The only way to tell them apart is to look at what Windows itself is doing, which is exactly what a PnP watcher is for.
- A workflow you rebuild three times deserves to become a tool. I hadn't planned to build a GUI tonight. The reason to build it was that the ad-hoc pattern had earned its keep, and typing the same setup a fourth time would have been silly. The moment the same commands go by three times, they want a button.
What's next
PnP Scope v0.1 works. v0.2 will teach it to recognise the two patterns I know how to spot by eye — hub-reset signatures (multiple simultaneous REMOVEs on the same parent) and unsigned-driver retry loops (repeating ADD/REMOVE on the same instance ID) — and highlight them without me having to squint. After that, a portable executable so it can travel to other machines that need a diagnostic pass.
The pops are gone. This time the log is still running, so we'll know if that changes.
Debugged with Claude Code. Published at indigo-nx.com.