STATUS_INTERRUPT_STILL_CONNECTED (0x128) — What It Means and How to Fix It

You're staring at STATUS_INTERRUPT_STILL_CONNECTED with the NTSTATUS value 0x00000128. Most people see this on a driver uninstall, a device disable, or a shutdown that hangs and eventually bugchecks. The message is literal: some kernel component called IoDisconnectInterrupt (or the WDF equivalent) on an interrupt vector that still had a handler attached.

The culprit here is almost always a network or storage driver that only half-cleaned up. I've seen it on Intel NIC drivers mid-update, on certain Broadcom miniports, and — my personal favorite — on a StorPort driver from a RAID card vendor whose uninstaller left an ISR dangling because a filter driver was still holding a reference.

Work through these three passes. Stop when it's fixed.

Pass 1 — The 30-Second Fix

Reboot. Not shutdown, not hibernate, not "restart Windows Explorer." A full cold reboot.

Why it works: interrupt objects live in non-paged pool and get torn down by the kernel during a clean boot cycle. If the offending driver only failed to disconnect during a runtime uninstall, the reboot clears the state. This fixes maybe 40% of cases — those where the driver was already unloaded and the error was surfaced by a stale keystroke or a pending IRP that never completed.

If the error came back immediately after the same action (uninstall, disable, driver update), rebooting is a band-aid. Move to Pass 2.

Pass 2 — The 5-Minute Fix: Find and Reset the Driver

You need to find which driver is holding the interrupt. Two ways:

Method A: Device Manager

1. Open Device Manager (devmgmt.msc).
2. View → Show hidden devices.
3. Look under Network adapters, Storage controllers, and System devices for anything with a yellow bang or a generic name like "Unknown device."
4. Right-click the suspect → Properties → Details tab → select Inf name and Hardware Ids. Note the driver.

Method B: From a command prompt (faster)

pnputil /enum-drivers | findstr /i "net bcm e1i e1d nvlddmkm storport"
Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like "*Ethernet*" -or $_.DeviceName -like "*RAID*"} | Select DeviceName, DriverVersion, InfName

Once you know the driver:

1. Disable the device in Device Manager. Don't uninstall yet — disable.
2. Reboot into Safe Mode (Shift+Restart → Troubleshoot → Advanced → Startup Settings → 4).
3. In Safe Mode, uninstall the device and tick "Delete the driver software for this device."
4. Reboot normally. Let Windows install the inbox driver, or grab the vendor's LTS version — not the newest one. Newest NIC drivers break things more often than they fix.

If the error still fires on the next uninstall attempt, the problem isn't the driver — it's something hooked into it. That's Pass 3 territory.

Pass 3 — The 15+ Minute Fix: Find the Filter That Won't Let Go

Interrupt vectors get shared. A miniport registers an ISR, but a filter driver (NDIS LWF, WFP callout, antivirus network shim, VPN TAP driver) holds a reference. When the miniport tries to disconnect, the kernel sees a non-zero reference count and throws 0x128.

Spot the filter

fltmc filters
Get-NetAdapterBinding -Name "Ethernet" | Where-Object {$_.Enabled -eq $true}

Common offenders I've busted on production boxes:

• Third-party VPN clients (older Cisco AnyConnect, older Palo Alto GlobalProtect) leaving NDIS lightweight filters bound.
• Endpoint security agents (CrowdStrike, SentinelOne, Carbon Black) with a network extension still loaded.
• Intel PROSet packages that install a "teaming" filter even when you don't use teaming.

Unbind them from the adapter and retry the driver operation:

Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ""
# Then retry the uninstall / disable operation

If you're still stuck — kernel debug

Attach WinDbg (kernel mode) to the live box, or analyze the memory dump after the bugcheck:

!analyze -v
!irpfind
!devstack 
!drvobj  7

Look at the !analyze output for the stack that called IoDisconnectInterruptEx. The frame right above it is your culprit. Nine times out of ten it's a driver whose DriverUnload routine just doesn't wait for pending DPCs to drain.

Real talk: if you're at Pass 3 and the vendor's driver is the problem, open a ticket. You can't patch someone else's cleanup routine. I've waited six weeks on a Broadcom fix for exactly this bug.

What Doesn't Help

• Driver Verifier with all flags on. You'll get a different bugcheck (usually 0xC4) before you ever see 0x128. Use standard flags + 0x20 (deadlock detection) if you must, but don't shotgun it.
• sfc /scannow. This is a kernel object lifetime problem, not corrupt system files. sfc won't touch it.
• Disabling interrupt moderation. That's a performance knob, unrelated to disconnect semantics.
• "Reset network stack" scripts. They'll nuke your bindings and you'll have more problems than you started with.

Quick Reference

Bottom line: reboot first, then reset the specific driver in Safe Mode, then hunt down the filter that's holding the reference. Skip the ritual cleanses. The bug is in one driver's unload path and you just need to find which one.