Short summary (what happened so far)
- Original symptom: MX Master 3 loses its Easy‑Switch channel (channel LED goes out) and only a mouse power‑cycle restores it. You’re on Windows 11 and the same Unifying receiver also hosts a Logitech K800 keyboard which stays connected during mouse failures.
- Key evidence collected (logs / tests): Windows captures and your Linux traces show the Unifying receiver remained enumerated while the mouse stopped sending events — no xHCI/controller resets were seen. That pattern points to a per‑device radio / pairing / session failure (mouse ↔ receiver) rather than a global USB host/controller problem.
- High‑value diagnostic result: Placing the Unifying receiver on a passive UGreen USB‑2.0 extension plugged into a rear motherboard USB2 port stopped the permanent disconnects. That strongly implicates RF/placement or USB3 interference / antenna geometry as the practical root cause.
Definitive, one‑pass solution (do these in order; stop when fixed)
1) Keep the UGreen passive USB‑2.0 extension in a rear motherboard USB2 port and test for 24–48 hours.
- Why: this already eliminated permanent disconnects for you and is the simplest, safest long‑term workaround. If stable, treat this as the fix.
2) If you want to fully rule out hardware (optional, next best test)
- Pair the MX Master 3 to Bluetooth and use it for 10–30 minutes. If Bluetooth is rock‑stable while Unifying previously failed, the problem is the Unifying link/receiver or its placement.
3) Cross‑host / receiver swap (decisive isolation)
- Put the same mouse + UGreen + spare Unifying receiver on a different known‑good PC for 10–30 minutes. Interpretation:
- Stable on other PC → likely host/driver/BIOS or original receiver placement on your main PC.
- Fails on other PC (or fails with spare receiver) → likely the mouse hardware itself.
4) If the mouse drops again, collect the immediate Windows traces (do NOT reboot) and attach them here so I can parse them and give the single next action:
- In an elevated PowerShell run (copy/paste exactly):
$start = (Get-Date).AddMinutes(-60)
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID0A5C' } | Format-List FriendlyName,InstanceId,Status | Out-File "$env:USERPROFILE\Desktop\MouseDeviceInfo.txt"
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} | Where-Object { $.ProviderName -match 'Kernel-PnP|USBHUB3|USB' -or $_.Message -match 'USB|usb|hub|reset|removed|disconnect|device|xhci|ehci' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last60min.txt"
- Attach MouseDeviceInfo.txt and USB_Events_Last60min.txt here and I’ll read them immediately and tell you the one precise remediation (driver/BIOS update vs. RMA).
5) If tests show the failure follows the mouse (i.e., mouse fails on other PCs / Bluetooth also fails), RMA the mouse. I can draft the exact RMA message you paste to Logitech; include the logs/tarball and the cross‑test notes (K800 stayed connected while mouse channel dropped). Example RMA wording and what to attach are already prepared in the thread if you want me to draft it.
Quick troubleshooting checklist (if you prefer a shorter run‑book)
- Leave UGreen in rear USB2 port for 24–48h (keep it).
- Test Bluetooth (isolates radio).
- Swap receiver / cross‑host test.
- Capture PowerShell logs if it drops again and attach them.
Bottom line / recommendation
- The practical fix that worked: keep the passive USB‑2.0 extension in a rear USB2 port; treat that as the working solution unless you need the receiver elsewhere. That resolves the issue in the large majority of cases and matches the captured evidence showing a per‑device radio/pairing problem rather than a USB controller failure.
Would you like me to:
- Draft the Logitech RMA/support message now (I’ll include the exact logs and repro steps), or
- Wait and parse MouseDeviceInfo.txt + USB_Events_Last60min.txt if another drop happens?