The standard fixes (re-pair, update drivers, replace batteries) miss the most common real cause: USB selective suspend failing on the Bluetooth radio itself. Here’s how to diagnose it from the event log and fix it permanently.
TL;DR
If your Bluetooth mouse stops working at random intervals, you can revive it by opening “Bluetooth and other devices” settings without doing anything in the page, and the failures don’t show up as errors anywhere obvious — your Bluetooth radio is going into USB selective suspend and failing to wake up. The recovery mechanism is that opening the Bluetooth settings page causes Windows to re-enumerate Bluetooth devices, which forces a USB-level reset that brings the radio back.
The fix has three layers — disable USB selective suspend on the Bluetooth controller itself, on its parent USB hub, and in the global Windows power profile. All three because they cascade. PowerShell:
$bt = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB.VID_13D3.PID_3558' }
$key = "HKLM:\SYSTEM\CurrentControlSet\Enum\$($bt.InstanceId)\Device Parameters"
New-ItemProperty -Path $key -Name 'SelectiveSuspendEnabled' -Value 0 -PropertyType DWord -Force
New-ItemProperty -Path $key -Name 'EnhancedPowerManagementEnabled' -Value 0 -PropertyType DWord -ForceThen in Device Manager untick “Allow the computer to turn off this device to save power” on the Bluetooth radio’s parent USB hub, and in Power Options set “USB selective suspend setting” to Disabled. Reboot.
The rest of this post explains how to confirm this is your problem, why USB selective suspend silently fails on certain radios, and why none of the obvious fixes work.
Symptoms
Search for any of these and you should land here:
- Your Bluetooth mouse (or keyboard) stops responding at random intervals — sometimes after minutes of idle, sometimes after hours.
- It almost always comes back if you open Settings → Bluetooth and other devices. You don’t need to do anything inside the page; just opening it is enough.
- Wiggling, clicking, pressing keys does nothing — the device doesn’t wake.
- Other Bluetooth devices (headphones, speakers) on the same machine often keep working, or have the same intermittent issue.
- There are no obvious errors in Event Viewer about Bluetooth. The Bluetooth-related logs look mostly empty.
- It happens regardless of how recently you paired the device, which version of the device’s firmware you have, or whether the batteries are full.
- Re-pairing the device fixes it for a while, then the symptom returns.
- Disabling and re-enabling the Bluetooth radio in Device Manager also fixes it for a while.
If most of these match, the explanation below probably applies to you.
Why the Standard Advice Doesn’t Help
Search results for “Bluetooth mouse keeps disconnecting” tend to recommend:
- Update the Bluetooth driver
- Remove the device and re-pair it
- Replace the batteries
- Run the Windows Bluetooth troubleshooter
- Disable Bluetooth and re-enable
- Reinstall the Bluetooth radio driver
A couple of these do fix the symptom in the moment — re-pairing, disabling/re-enabling, restarting the Bluetooth service — because they all incidentally trigger the same USB re-enumeration that opening the settings page does. But none of them address the underlying cause, which is at the USB power-management layer, not the Bluetooth-protocol layer. So the symptom comes back the next time the radio idle-suspends.
The driver update advice is well-intentioned but mostly irrelevant: you can be on the latest manufacturer driver and still hit this, because the bug is in the Bluetooth radio’s firmware-level wake-from-suspend handshake (or in the USB host controller’s handling of it), not in the driver code that the driver update would replace.
What’s Actually Happening: USB Selective Suspend
Modern PCs implement aggressive power management on idle USB devices. The mechanism is called selective suspend: any USB device that hasn’t been used for a few seconds gets put into a low-power state by Windows, on the assumption that it can be resumed quickly when needed. When the OS or an application needs to talk to the device again, the USB host controller sends a resume signal down the bus and the device wakes back up within milliseconds.
This is mostly invisible — printers, webcams, USB drives all suspend and resume countless times a day with no perceptible delay. For a Bluetooth radio though, the resume handshake is a bit more involved: the radio has to power up its baseband processor, re-establish state with currently-paired devices, resume scanning for advertisement packets, and re-arm the host’s HID polling. Several Bluetooth controllers — and the Realtek 13D3:3558 family in particular, which is the Bluetooth half of the popular Realtek 8821CE WiFi+Bluetooth combo cards on a lot of Gigabyte and ASUS desktops — have a known habit of botching part of that resume handshake. Specifically, the radio appears to wake up at the USB level (it draws power, the host controller sees it) but it doesn’t fully come back online at the Bluetooth-stack level. So Windows thinks the radio is alive, the radio thinks it’s asleep, and your mouse can’t reach it.
What’s particularly annoying is that there’s no error from the BTHUSB driver when this happens, because from the OS’s perspective nothing went wrong — selective suspend completed normally and the device simply isn’t returning data. There is, however, a very useful event that fires every time the Bluetooth stack re-initializes against the radio, and that’s the diagnostic we’ll use.
Opening Bluetooth and other devices settings triggers Windows to enumerate paired Bluetooth devices. Enumeration involves issuing fresh requests to the radio, which the host controller responds to by issuing a USB-level reset (because the device wasn’t responding to its previous queries), which is a much heavier-handed wake than the normal resume signal — and that reset gets the radio back into a working state. That’s why the settings-page trick works.
The Diagnostic: BTHUSB Event 18 Cadence
The Bluetooth USB driver writes Event ID 18 to the System log every time the Bluetooth stack initializes against the local radio:
Windows cannot store Bluetooth authentication codes (link keys) on the local adapter. Bluetooth keyboards might not work in the system BIOS during start-up.
The text of the event is misleading. It’s not an error — it’s an informational message about a controller capability (link key storage), and it fires during every initialization regardless of whether anything went wrong. The fact that it fires is the signal: every Event 18 corresponds to one full Bluetooth stack initialization. On a healthy machine, you’d expect one or two of these per day — once at boot, maybe once after wake-from-sleep.
Pull the recent Event 18 history with:
Get-WinEvent -ProviderName BTHUSB -MaxEvents 100 |
Select TimeCreated, Id, LevelDisplayName, @{N='Msg'; E={ ($_.Message -split "`r?`n")[0] }} |
Format-Table -AutoSize -WrapIf you see something like this, you have the problem:
3/05/2026 1:09:54 PM 18 Information ...
3/05/2026 10:40:41 AM 18 Information ...
3/05/2026 9:28:21 AM 18 Information ...
2/05/2026 4:25:18 PM 18 Information ...
2/05/2026 3:17:23 PM 18 Information ... ← three within 2 hours
2/05/2026 2:46:36 PM 18 Information ...
1/05/2026 5:23:18 PM 18 Information ...
30/04/2026 9:25:30 PM 18 Information ...
30/04/2026 7:08:21 PM 18 Information ...
Six to fifteen events per day, sometimes clustered three within two hours, is the smoking gun. Each event is one of your “mouse died → opened settings → mouse alive” cycles.
You can also confirm by checking the per-device USB power-management state. The default for USB devices is selective-suspend-enabled with no per-device override. Run:
$bt = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB.VID_13D3.PID_3558' }
$key = "HKLM\SYSTEM\CurrentControlSet\Enum\$($bt.InstanceId)\Device Parameters"
reg query "$key" /v SelectiveSuspendEnabled
reg query "$key" /v EnhancedPowerManagementEnabledIf both come back with ERROR: The system was unable to find the specified registry key or value., the device has no explicit override and is using Windows defaults, which means selective suspend is on.
(Substitute the VID/PID match for whatever Bluetooth radio you have. Find the exact InstanceId in Device Manager → Bluetooth → your radio → Properties → Details → Hardware Ids. It’ll look like USB\VID_xxxx&PID_xxxx. The 13D3&PID_3558 here is the AzureWave/Realtek combo-card BT chip; Intel BT is typically USB\VID_8087, etc.)
The Fix: Disable Selective Suspend at All Three Layers
USB power management cascades from three places:
- The device’s own per-device override in registry (or via Device Manager’s Power Management tab on the device).
- The parent USB hub’s power management. If the hub itself is allowed to suspend, that can take everything below it down with it, regardless of per-device settings.
- The global Windows power profile’s “USB selective suspend setting”.
The default is “suspend allowed” at all three layers. To get a permanent fix you need to disable it at all three; disabling at any one layer alone doesn’t always stick.
Layer 1: the Bluetooth controller itself
PowerShell as admin:
$bt = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB.VID_13D3.PID_3558' }
$key = "HKLM:\SYSTEM\CurrentControlSet\Enum\$($bt.InstanceId)\Device Parameters"
New-ItemProperty -Path $key -Name 'SelectiveSuspendEnabled' -Value 0 -PropertyType DWord -Force
New-ItemProperty -Path $key -Name 'EnhancedPowerManagementEnabled' -Value 0 -PropertyType DWord -Force
# Verify
Get-ItemProperty -Path $key | Select SelectiveSuspendEnabled, EnhancedPowerManagementEnabledIf the registry path is access-denied (which can happen on some installs), use Device Manager instead: Device Manager → Bluetooth → right-click the Bluetooth radio (e.g. “Realtek Bluetooth Adapter”) → Properties → Power Management tab → uncheck “Allow the computer to turn off this device to save power” → OK.
Layer 2: the parent USB hub the Bluetooth radio sits behind
The Bluetooth radio is connected to a USB hub somewhere in the device tree. Find which one:
$bt = Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'USB.VID_13D3.PID_3558' }
$parentId = (Get-PnpDeviceProperty -InstanceId $bt.InstanceId -KeyName 'DEVPKEY_Device_Parent').Data
Get-PnpDevice -InstanceId $parentId | Select Status, FriendlyName, InstanceIdThat returns something like “USB Root Hub (USB 3.0)” with an InstanceId. Open Device Manager → Universal Serial Bus controllers → find that exact hub → Properties → Power Management tab → uncheck the same checkbox.
If the hub itself doesn’t have a Power Management tab (some hubs don’t expose one), the per-device setting from layer 1 is what governs. But on most modern Windows installs the hub will have the tab.
Layer 3: the global Windows power policy
Open Power Options:
- Control Panel → Hardware and Sound → Power Options → Change plan settings (for the active plan) → Change advanced power settings
- Expand USB settings → USB selective suspend setting
- Set it to Disabled (for both “On battery” and “Plugged in” if you’re on a laptop).
- OK.
For a desktop, just set it to Disabled and forget about it — the power saving is trivial. For a laptop, the trade-off is more real (a few percent battery drain on a long idle period), but on most modern laptops the impact is negligible compared to the screen and CPU draw.
After all three layers are flipped, reboot. The reboot is needed because some USB devices only re-evaluate their power-management settings on full PnP enumeration, and a clean boot guarantees that.
Verifying the Fix Worked
After the reboot, use the machine normally for a day or two. Then re-run the BTHUSB query:
Get-WinEvent -ProviderName BTHUSB -MaxEvents 50 |
Select TimeCreated, Id |
Sort TimeCreated -Descending |
Format-Table -AutoSizeYou’re looking for the daily Event 18 cadence to drop from ~10/day to ~1-2/day (just boot and any sleep cycles). If it’s stayed high, one of the three layers didn’t take — most often the parent hub’s power management, because the wrong hub got the change. The Bluetooth radio can be behind several layers of hubs (root hub → composite USB device → internal hub), and you may need to disable suspend on each one in the chain. Re-run the parent-finding command starting from the Bluetooth device and walk up the tree.
Why Combo WiFi+Bluetooth Cards Hit This More
The Realtek 8821CE and similar combo cards (8822CE, 8852BE, etc.) put both WiFi and Bluetooth on a single chip. The WiFi half talks to the host over PCIe; the Bluetooth half talks over USB internally on the motherboard. The two halves share an antenna and a 2.4 GHz radio frontend, coordinated by a coexistence protocol so they don’t transmit on top of each other.
This shared-radio architecture means the Bluetooth controller has to negotiate radio access with the WiFi side every time it wakes from suspend, and that negotiation has to happen during the same window in which the Bluetooth stack is re-establishing state with paired devices. Several timing-sensitive things have to line up. On many Realtek combo cards, that lineup is fragile, and the resume sometimes silently fails — the Bluetooth controller is technically powered but it’s stuck waiting for radio access that never gets granted, or it gives up and goes back into a half-suspended state that USB doesn’t know about.
Disabling selective suspend bypasses all of that complexity by simply never letting the radio sleep in the first place. The radio stays continuously powered and continuously connected, the coexistence negotiation never has to re-run from cold, and the wake-handshake bug is moot because there’s no wake.
If you don’t want to leave the radio always-on, the alternative is to replace the combo card with a separate WiFi adapter and a separate Bluetooth dongle on different USB ports — both halves stop competing for radio access, and Bluetooth selective suspend usually works fine on standalone dongles. But that’s hardware effort for what’s essentially a free software fix.
Why You Can’t Find This Online
The BTHUSB Event 18 → “Bluetooth re-init cadence is the diagnostic” pattern is essentially absent from public documentation. Microsoft’s docs describe USB selective suspend as a developer-facing power-management feature; they don’t describe what its failure modes look like from the user side. Hardware vendors don’t acknowledge their controllers’ wake bugs because the issue is intermittent and the suspend mechanism is “working as designed”. And most search results for the symptom focus on driver updates and re-pairing because those are the visible knobs an end-user has — even though they fix the symptom for an hour and then it returns.
The result is a long tail of forum threads with people swapping the same surface-level advice and the actual cause going undocumented. If you got here by searching for “Bluetooth mouse stops working randomly” or “Realtek Bluetooth disconnects” or similar, hopefully this saves you the cycle of repeatedly reinstalling drivers.
Cheat Sheet
For people who skipped to the end:
- Symptom: Bluetooth mouse/keyboard stops working at random intervals. Opening Bluetooth and other devices settings revives it without you doing anything in the page.
- Diagnostic:
Get-WinEvent -ProviderName BTHUSB -MaxEvents 100. If you see Event 18 firing many times a day, that’s the bug. - Root cause: USB selective suspend on the Bluetooth radio fails its wake-from-suspend handshake. The radio appears to be powered but is unreachable.
- Fix: Disable USB selective suspend at three layers — the BT device itself (registry/Device Manager), the parent USB hub (Device Manager), and the global Windows power plan (Power Options). All three. Reboot.
- Common on: Realtek combo cards (8821CE, 8822CE, 8852BE) where WiFi and Bluetooth share a radio; some Intel and MediaTek combo controllers as well.
- What doesn’t fix it: Driver updates, re-pairing, replacing batteries, running the Bluetooth troubleshooter — those address the symptom temporarily by triggering a USB re-enumeration, but the underlying suspend bug remains.
If this saved you time, share it. Bluetooth mouse periodic disconnect on Windows 10 / Windows 11 is a maddening symptom that almost always has a five-minute fix once you know where to look.