Bluetooth stack fails to restart after driver-store cleanup — Windows 11 25H2

This has affected 8+ users across our fleet so far, all on Windows 11 25H2 with Intel AX211 radios (Dell and HP hardware). It's a full loss of Bluetooth — not a minor glitch. Users lose headsets mid-call and can't re-pair them, and mice/keyboards drop randomly, including during sign-in. It keeps coming back after a fix that looked complete, so it's actively affecting productivity, not a one-off.

The issue: Since late August 2026, Bluetooth on multiple Windows 11 25H2 devices has developed a restart loop. Paired devices connect and disconnect repeatedly, and eventually Bluetooth disappears entirely from Quick Settings, Settings, and Device Manager. While the fault is active, audio devices won't pair at all, and mice/keyboards continue to pair but drop out intermittently. Reinstalling or updating the Bluetooth driver does not fix it, and neither does a normal restart. It isn't specific to one vendor, adapter, or Windows build — we've seen it on builds 26200.9168 and 26200.9278.

What we found (key finding #1 — the devnode leak): Using Get-PnpDevice, affected machines showed a large number of "ghost" Bluetooth devnodes (40+) with zero live nodes — meaning the entire Bluetooth class had gone, not just the paired accessories. A healthy control machine showed 0 ghost nodes and ~28 live nodes. This is the clearest signal something is wrong: BthEnum and BthLEEnum were creating a new generation of child devices every time the radio's parent USB device (VID_8087&PID_0033) got reconfigured, without ever cleaning up the previous generation. The parent hash stayed the same throughout, which rules out the module dropping off the USB bus — this is a restart loop, not a disconnect.

What we found (key finding #2 — driver ranking instability): The driver store held multiple competing Bluetooth driver packages claiming the same hardware ID at identical rank — several versions of the Intel driver stacked up from repeated Intel Driver & Support Assistant installs. The selected driver was oscillating between different installed versions across sessions, including a mid-session change with no reboot involved. Important detail: one of the newer driver branches in the store targets a different Intel chipset generation than the AX211 radio actually in these machines — so the store had the wrong driver competing for priority.

What we found (key finding #3 — cleanup only partially worked): We disabled Intel Driver & Support Assistant, reduced the driver store to the single correct package, removed the orphaned devnodes, and blocked Windows Update from pushing more driver versions. This fixed the repeated ~75-minute restart cycle. But Bluetooth still failed again about an hour later — this time differently. The Kernel-PnP log showed a "device configured" event with no matching "device started" event after it, which points to a start/resume failure rather than the same loop repeating. The device had also been offline ~55 minutes beforehand, too long for a reboot and more consistent with a sleep/wake cycle. This is the most important finding: it means there are two separate faults stacked together, not one.

Ruled out:

• Windows build version (fault on two different builds; a healthy control machine ran one of the same builds)
• The August 2026 cumulative update (rollback didn't help)
• A staged Windows feature rollout (zero differences across thousands of feature flags between a faulted and healthy machine)
• Driver-store pollution as the sole cause (fixed that specifically, fault still recurs)
• Peripheral brand (control machine uses the same brand of mice with no issue)

Still open: Whether this is a driver-ranking problem (largely fixed) sitting on top of a separate, still-unpatched Bluetooth resume-from-sleep bug in 25H2. That would explain why cleanup only partially worked, and why the same "restart loop then dead" symptom is being reported on non-Intel hardware (Surface, Lenovo, AMD) elsewhere too.

Has anyone seen the same "configured but never started" pattern after sleep/resume, or is there a known issue tracking this on 25H2?