Logitech MX Master 3 losing connectivity

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! Installing PowerShell on Windows - PowerShell

PS C:\WINDOWS\system32> $proc = Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File `"$env:USERPROFILE\Desktop\usb_monitor.ps1`"" -WindowStyle Hidden -PassThru
PS C:\WINDOWS\system32> $proc.Id | Out-File "$env:USERPROFILE\Desktop\usb_monitor.pid"
PS C:\WINDOWS\system32> Write-Host "USB monitor started (PID: $($proc.Id)). Log: $env:USERPROFILE\Desktop\USB_Monitor.log"
USB monitor started (PID: 18868). Log: C:\Users\rupes\Desktop\USB_Monitor.log
PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid"
18868
PS C:\WINDOWS\system32> Get-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -ErrorAction SilentlyContinue

Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
581 30 63576 78072 0.69 18868 3 powershell


PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 30
--- USB monitor started at 2025-10-22T12:53:41.9553191+01:00 ---
--- USB monitor started at 2025-10-22T17:25:34.8376479+01:00 ---
PS C:\WINDOWS\system32>
 

Great — that’s a smart, orderly plan. Short reply with what to watch for, a few clarifications about the “Logi” receiver, and exactly what to do next so we can conclude quickly.
Quick acknowledgement
  • Good: you swapped to the second spare receiver (the one marked “Logi”), unpaired/re‑paired K800 and MX Master 3, and started usb_monitor.ps1. You’ve already seen no drops so far. Leave it running on the UGreen for a few hours — that will quickly tell us whether the spare receiver fixes the issue.
About the “Logi” marking
  • “Logi” is Logitech’s newer branding — some newer receivers are marked “Logi”. That doesn’t necessarily mean Bolt vs Unifying, but there are two different protocols: Unifying and Bolt. If pairing succeeded in your Unifying app, it’s compatible. If you want to be 100% certain:
    • Open Device Manager → Universal Serial Bus controllers → find the receiver entry and check Properties → Details → Hardware Ids. If it shows something like 046D:C52B (Logitech Unifying), it’s Unifying. If different IDs (and you used the Bolt pairing tool) it could be Bolt. Either way, pairing success means you’re good to test.
What I’ll watch for from the USB monitor
  • usb_monitor.ps1 logs System events that mention USB/hub resets and disconnects into USB_Monitor.log on your Desktop. If a permanent disconnect happens while you’re away, that log (or the immediate Windows captures below) is what I need to decide host vs device.
If a permanent disconnect happens (exact steps)
1) Do NOT reboot the PC.
2) If you have the monitor running, stop it when you return and attach the file:
  • Stop it: find & stop the process or run the Stop-Process command I gave earlier.
  • Attach: C:\Users\<you>\Desktop\USB_Monitor.log
OR (immediate decisive capture — recommended if you missed the monitor)
3) Run these two commands in an elevated PowerShell (copy/paste exactly). They produce two small Desktop files I’ll parse immediately:
$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 both:
  • MouseDeviceInfo.txt
  • USB_Events_Last60min.txt
What I will look for and report (fast)
  • If System events show “usb … disconnect” or xhci_hcd / ehci_hcd reset entries at the drop time → host/controller/port problem (I’ll supply the exact chipset/USB driver or BIOS update to install).
  • If the receiver stayed present (MouseDeviceInfo shows it) and the events show only per‑device retries or Unifying “device doesn’t respond” behavior → radio/session problem (mouse or receiver). Then we’ll:
    • try Bluetooth (next step) and cross‑host testing; and
    • if the fault follows the mouse, I’ll draft an RMA message for you.
Next tests you’ll run (order & why)
1) Continue running the spare receiver on the UGreen for a few hours (done). If stable → original receiver likely at fault or placement was the issue.
2) If it stays stable, next try the MX Master 3 over Bluetooth (pair via Bluetooth adapter) for 10–30 minutes:
  • Bluetooth stable → Unifying link/receiver implicated.
  • Bluetooth also drops → mouse hardware likely faulty.
    3) Cross‑host test (if needed): plug the spare receiver + UGreen into a different known‑good PC and test. If the fail follows the mouse across hosts → mouse fault; if only fails on one PC → host issue.
If you want, I can prepare the RMA text now (ready to paste) — but let’s wait until one of the above tests points to the mouse.
Wrap & quick checklist to follow before you leave now
  • Leave the spare receiver on the UGreen in the rear USB2 port.
  • Note the time you start this watch period (wall clock).
  • If you return and see a drop, run the two commands above (or attach USB_Monitor.log) immediately and I’ll parse right away.
I’ll be here and ready to parse the logs the moment you attach them (or to draft the RMA if we confirm a device fault). Safe errands — see you later.
 

Thanks — that looks good. The monitor is running (PID 18868) and your USB_Monitor.log shows it started, so logging is active. Quick, clear next steps and what I need from you when you return.
Immediate confirmation (what you already did)
  • You started the monitor and saved its PID: 18868. The monitor log header shows it started (you printed the last 30 lines and saw the two “USB monitor started …” entries). Good — it’s logging now.
While you’re out
  • Leave the spare Unifying receiver plugged into the UGreen passive USB‑2.0 extension in the rear USB2 port and don’t move the PC. The monitor will collect System USB/Kernel‑PnP events while you’re away.
When you return — the 1‑minute checklist
1) Stop the monitor (so the logfile is closed cleanly)
  • Open PowerShell as Administrator and run:
    Stop-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -Force
    Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid"
    (If you didn’t have a pid file, stop the powershell process you started by PID or StartTime — see earlier steps you ran.)
2) Inspect the monitor log (quick)
  • View the tail to see if it captured anything around the time you noticed the dropout:
    Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200
  • If you remember an approximate wall time (eg “about 12:42”), filter the log for that time range:
    Select-String -Path "$env:USERPROFILE\Desktop\USB_Monitor.log" -Pattern '2025-10-22T12:4'
3) Produce the decisive Windows captures (if a dropout was logged)
  • If you see events around your dropout time, or you want me to be definitive, run these two commands (Admin PowerShell). They create two small files on your Desktop that I’ll parse and act on immediately. Use AddMinutes(-60) if the drop was earlier; AddMinutes(-30) is fine for recent drops:
$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"
4) Attach to your reply
  • Attach these files (paperclip) or paste their contents:
    • USB_Monitor.log (full monitor file) — useful if you left it running, or
    • MouseDeviceInfo.txt and USB_Events_Last60min.txt (the two decisive captures)
What I’ll do as soon as you attach them
  • I’ll parse the logs and pull the exact event lines that decide host vs device:
    • If you see controller/hub/xhci resets at the drop time I’ll give the single driver/BIOS update (exact download + steps).
    • If the receiver stayed present but there are per‑device retries / “device doesn’t respond” entries, I’ll tell you to swap receiver/Bluetooth test or prepare an RMA (and I will draft the RMA wording and list the exact log snippets to attach).
If you want me to stop the monitor for you now
  • Say “Stop it” and I’ll give the one line to paste to stop PID 18868 (Stop-Process -Id 18868 -Force). If you prefer to stop it yourself later, that’s fine — just run the Stop-Process command above when you return.
Short reassurance
  • The monitor running now will capture any future drop while you’re out. When you’re back, attach the files listed and I’ll give the single next action.
Would you like me to give the exact Stop-Process command to stop PID 18868 now, or will you stop it yourself when you return?
 

Receiver is defintely Unifying. I used the Unifying Software for pairing. I'm thinking if it has the Logi branding it may be later revision of the hardware so may behave different from the other two which look identical.

RMA to Logitech seems pointless as it is out of warranty.
 

Thanks — that makes sense and is a useful observation about the branding/revision difference.
Short takeaways
  • Your receiver is definitely a Unifying receiver (the Unifying Software paired it and your logs show 046d:c52b). That matches the behaviour we saw: receiver stayed enumerated while the mouse channel intermittently failed.
  • Because it’s out of warranty, RMA is unlikely to be worth it — so the practical choices are 1) keep using the reliable workaround (UGreen + spare receiver), 2) replace the faulty part (cheap receiver or new mouse), or 3) confirm the exact faulty component with a quick, final set of tests and logging.
Recommended next steps (prioritised, minimal fuss)
1) Keep the UGreen + spare receiver that’s currently stable
  • Since stability improved once you used the UGreen and the spare receiver, the simplest, cheapest solution is to keep that arrangement and monitor for 24–48 hours. That solves the problem in practice.
2) Do two quick isolation checks (optional, confirmatory)
  • Bluetooth test: pair the MX Master 3 to the PC via Bluetooth and use for 10–30 minutes. If Bluetooth is rock‑stable, the mouse hardware is OK and the issue is the Unifying link/receiver/placement.
  • Cross‑host check: plug the current spare receiver + UGreen into a different PC and test the same mouse there. If it works there, the original PC/receiver/placement was the problem; if it fails there too, the mouse is the likely culprit.
3) If you want a low‑cost permanent fix (recommended if you prefer not to keep the extension)
  • Replace the Unifying receiver with a new Unifying receiver (inexpensive), and/or
  • Buy a replacement mouse if tests show the fault follows the mouse. Buying a new Unifying receiver is usually cheaper than a new mouse and often fixes these symptoms.
4) If the fault recurs, capture the decisive Windows logs immediately (do NOT reboot)
  • Run this (Admin PowerShell) right after the next drop and attach the two files it creates:
    $start = (Get-Date).AddMinutes(-30)
    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 those two files and I’ll parse them immediately and tell you exactly whether to update a specific driver/BIOS or to replace hardware.
Why the UGreen + spare receiver is a good practical solution
  • Empirically it fixed the permanent disconnects for you. Technically it improves antenna position and reduces USB3/hub RF interference so the Unifying radio link is much more robust. Keeping that arrangement is the least invasive, most likely to succeed option.
If you still want an RMA-style message (even OOW)
  • I can draft a short message describing the tests/logs (Slax capture, system report with “Device doesn't respond” lines, cross‑tests) for Logitech support — they may still offer troubleshooting or paid repair/discounts. Say “Draft RMA” and I’ll prepare text you can copy/paste.
What I can do next for you
  • If you’d like, when you return you can attach the monitor log or the two Windows files above (if a dropout happens) and I’ll parse them at once and give the single next action.
  • Or I can help you pick & order a replacement Unifying receiver (cheap) or a new mouse (if the mouse is the cause) and show how to transfer pairing/firmware.
Which would you like to do now?
  • Keep UGreen in place and wait (I’ll check back when you return), or
  • Run Bluetooth / cross-host tests now (I can walk you through), or
  • I’ll draft an RMA text for you to keep ready.
Rest, run your errands — I’ll be here when you return and we’ll finish the final confirmation.
 

Give the exact Stop-Process command to stop PID 18868 now
 

Run this exact command in an elevated PowerShell (Run as Administrator) to stop PID 18868:
Stop-Process -Id 18868 -Force
Then verify it stopped and view the log tail (two quick checks):

confirm the process is gone​

Get-Process -Id 18868 -ErrorAction SilentlyContinue

show the last 200 lines of the monitor log​

Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200
If you created a pid file earlier, remove it (safe to run even if it doesn't exist):
Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid" -ErrorAction SilentlyContinue
Paste the output of the Get-Content command (or attach USB_Monitor.log) and I’ll parse it for any drop entries.
 

I've made a decision to buy a Logitech K650 and either a MX Master 3S or Master 4 in Black Friday. They both use the Bolt Receiver. I want to wait until then as it is likely the MX Master 3S is going to be heavily discounted as the MX Master 4 has just been released.

I just need a temporary working mouse and keyboard until. Worse case scenario until Black Friday is using the K800 with the Unifying receiver and the MX Master 3S from my laptop with the Bolt receiver.

I want to move away from the Unifying receiver as Bolt seems a superior technology.
 

Nice plan — waiting for Black Friday to pick up Bolt‑compatible gear makes sense. Below is a short, practical checklist and a few tips so you have a reliable temporary setup until then, and a smooth migration to Bolt when you buy new kit.
Temporary setup (what to use now)
  • Keep the spare Unifying receiver on the UGreen passive USB‑2.0 extension in the rear USB2 port (what you already have). That solved the permanent disconnects and is the lowest‑effort, most reliable interim fix.
  • Use the K800 on the Unifying receiver for daily typing if you prefer. It’s older but serviceable.
  • Use your MX Master 3 from your laptop via Bolt (if that MX Master 3 supports Bolt; you said MX Master 3S likely has Bolt — verify your specific mouse model). If it’s Bolt‑paired on the laptop, great — that avoids mixing receivers on the main PC.
  • If you plan to use Bluetooth as a fallback, pair the MX Master 3 with Bluetooth as well (many Logitech mice support dual pairing).
Checklist before you buy (so migration is simple)
  1. Confirm Bolt compatibility
    • Check the exact model numbers you plan to buy (K650, MX Master 3S or MX Master 4) and confirm they list “Logitech Bolt” compatibility. Bolt and Unifying are different protocols — a Bolt receiver cannot manage Unifying devices and vice versa.
  2. Update firmware & software now
    • Update Logi Options+ (or Bolt app) on the PCs you’ll use. Update firmware on current devices if updates exist — you’ll want the latest firmware/settings saved or synced before swapping hardware.
  3. Backup device settings
    • Logi Options+ supports cloud/device backup for many devices — sign in and back up your mouse settings (buttons, custom mappings). That makes restoring settings on the new mouse easier.
  4. Prepare the old Unifying receiver
    • If you want to keep the K800 for now, leave it paired to the Unifying receiver. If you want to retire the old receiver, unpair devices with the Unifying Utility (classic Unifying or the newer Unifying/Bolt app’s Unpair function).
What to do on Black Friday (migration steps)
  • Unbox Bolt receiver + new mouse/keyboard. Pair the new devices with the Bolt receiver using Logitech’s Bolt/Options+ app.
  • Restore settings from the cloud in Logi Options+ (if you used device backup).
  • Keep the UGreen extension or move the Bolt receiver to the back‑panel USB2 port — Bolt benefits from good placement just like Unifying.
If you see problems after buying Bolt gear (one decisive capture)
  • If you still see disconnects with Bolt, run the two small Windows captures I gave earlier (MouseDeviceInfo.txt + USB_Events_Last60min.txt) and attach them; I’ll parse and tell you the one exact action (driver/firmware/BIOS or replacement).
Why Bolt is a good choice (brief)
  • Bolt uses a more modern radio/stack intended to be more robust in noisy environments and supports improved encryption and latency in many configurations. In practice many users see better reliability than older Unifying receivers (especially in USB3/noisy setups). That matches your wish to move away from Unifying.
Cheap permanent options if you don’t want to wait
  • Replace the original Unifying receiver (cheap) or buy a new Bolt receiver + devices on promo. A new Unifying receiver + UGreen will often be the cheapest way to return to a single-dongle setup, but Bolt is more future‑proof.
If you’d like I can
  • Draft a shopping checklist for Black Friday (links/what to look for + recommended SKUs), or
  • Draft the short RMA/repair text if you later decide to try asking Logitech (even OOW some regions offer paid support), or
  • Walk you step‑by‑step through pairing Bolt and restoring options when you have the new hardware.
Want me to prepare a Black Friday shopping checklist (models to watch / what to check), or a short migration script/steps you can copy‑paste when you buy your new MX Master 3S/Master 4 and K650?
 

PS C:\WINDOWS\system32> Stop-Process -Id 18868 -Force
PS C:\WINDOWS\system32> Get-Process -Id 18868 -ErrorAction SilentlyContinue
PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200
--- USB monitor started at 2025-10-22T12:53:41.9553191+01:00 ---
--- USB monitor started at 2025-10-22T17:25:34.8376479+01:00 ---
PS C:\WINDOWS\system32> Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid" -ErrorAction SilentlyContinue
PS C:\WINDOWS\system32>
 

Perfect — you stopped the monitor successfully.
Quick read of what you showed
  • USB_Monitor.log only contains the two “USB monitor started …” lines. That means the monitor was running and started twice, but it didn’t capture any matching USB/System events between those start points (or the earlier permanent drop at ~12:42 happened before the monitor was first started at 12:53, so it wasn’t logged). Good that you stopped it cleanly.
If you want to capture the 12:42 event now (one‑time decisive grab)
  • Because the dropout happened several hours ago, run the capture over a larger time window so Windows Event Log will include it. In an elevated PowerShell (Run as Administrator) copy/paste these two exact commands — they’ll write two small files to your Desktop:
$start = (Get-Date).AddMinutes(-300)
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_Last300min.txt"
  • Then attach MouseDeviceInfo.txt and USB_Events_Last300min.txt here (paperclip). I’ll parse them immediately and give the single next action (driver/BIOS update vs hardware swap/RMA).
If you prefer to run tests instead of logging
  • Bluetooth test: pair the MX Master 3 to your Bluetooth dongle and use it for 10–30 minutes. If Bluetooth is rock‑stable while the Unifying link was flaky, that isolates the Unifying link/receiver as the issue.
  • Cross‑host test: plug the spare receiver + UGreen into another PC and test. If it’s stable there, the original receiver/PC combo was the problem; if it fails on the other PC too, the mouse is likely the culprit.
Short practical recommendation now that you’re moving to Bolt gear
  • Keep the current UGreen + spare receiver as your temporary, reliable setup until Black Friday. Buying Bolt devices (K650 + MX Master 3S/4) is a good move — Bolt is more robust in noisy USB3 environments and will likely eliminate this class of problem long‑term.
Want me to
  • (A) parse the two log files if you run the larger capture above now, or
  • (B) draft a Black Friday shopping checklist for Bolt devices and recommended SKUs/pricing strategy, or
  • (C) prepare an RMA text (even OOW) you can use if you decide to contact Logitech?
Say which and I’ll do it straight away.
 

No don't need a Black Friday shopping checklist.
But create the migration script for the new Bolt gear.
 

Great — here’s a concise, ready‑to‑run “migration script” you can follow when your Bolt gear arrives. It covers pre‑migration prep, the exact pairing & firmware/update steps, how to restore settings, verification, and a short troubleshooting checklist (with the exact PowerShell captures to run if anything goes wrong).
Do this in order. I assume Windows 10/11 on the PC you’ll use as primary.
Before you start (prep, 5–10 min)
1) Create a System Restore point (just in case):
  • Search → Create a restore point → Create.
2) Install Logitech software
  • Install Logi Options+ (the app that handles Bolt and the device settings). Sign in to your Logitech account if you want cloud backup. (If you prefer the older apps for specific models, install as needed later.)
3) Backup any existing device settings (if you used Logi Options+ previously)
  • Open Logi Options+ → Sign‑in → ensure Device Backup / cloud sync is enabled. Wait for settings to sync.
4) Note current power settings (we used these earlier) — ensure selective suspend is off:
  • In elevated CMD or PowerShell run:
    powercfg -setacvalueindex SCHEME_CURRENT SUB_USB USBSELECTSUSPEND 0
    powercfg -setdcvalueindex SCHEME_CURRENT SUB_USB USBSELECTSUSPEND 0
    powercfg -S SCHEME_CURRENT
Migration / pairing steps (on the day you get Bolt gear)
A. First device (keyboard K650 or whichever you want as primary)
1) Plug the Bolt receiver into a rear, motherboard USB2 port. If you have a short passive extension (UGreen), use it for best radio position.
2) Launch Logi Options+ → click “Add Device” or the Bolt pairing action.
3) Choose “Logi Bolt receiver” option, follow on‑screen steps (press pairing buttons on the receiver/mouse/keyboard as prompted). Wait for the app to confirm the new device is paired.
4) Repeat for the other device (mouse). You can pair multiple Bolt devices to the same Bolt receiver (check the app count).
B. Firmware & Options
1) In Logi Options+ select each device and check “Firmware” / “Check for Update” — update firmware if available.
2) If you used cloud backup earlier, restore the backup in Options+:
  • Options+ → Devices → Settings → Restore from cloud (if available).
  • If no cloud backup, reconfigure buttons/flows in Options+ manually.
C. Verify behavior
1) Test basic functions: cursor movement, left/right/middle buttons, side buttons, wheel, keyboard keys.
2) Walk test: move mouse around for 10–30 minutes; look for stutters/drops.
3) If using Flow (multi‑PC clipboard), test that switching works.
If you want a temporary fallback
  • Keep your old Unifying receiver + UGreen available (do NOT have Bolt and Unifying receivers both in the same port if you don’t need to) — they are not compatible but can both be present in different ports if needed.
Post‑migration verification & housekeeping
1) Confirm the new Bolt devices appear in Device Manager:
  • Run in PowerShell: Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID_0A5C' } | Format-List FriendlyName,InstanceId,Status
2) Confirm firmware versions in Logi Options+ and keep a note (screenshot).
3) Remove old pairings (optional)
  • Use Logitech Unifying Utility to unpair old Unifying devices if you no longer need them (don’t unpair until you’ve confirmed Bolt devices work).
Troubleshooting (decisive captures — run these immediately after any drop)
If you see a drop or disconnect, do NOT reboot. Run these in an elevated PowerShell and attach the two resulting files (or paste their contents here) — they are the minimal evidence I need to tell you the single correct fix.
1) Device list (shows whether Windows still sees receiver / device):
$start=(Get-Date).AddMinutes(-10)
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID_0A5C' } | Format-List FriendlyName,InstanceId,Status | Out-File "$env:USERPROFILE\Desktop\MouseDeviceInfo.txt"
2) System events (USB / kernel events around the drop):
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_Last10min.txt"
Attach those two files and I will:
  • If events show “usb … disconnect” or xhci_hcd resets → tell you the exact chipset/USB driver or BIOS update to install (I’ll give a single download and the exact install step).
  • If the receiver stays present but the device stops responding → instruct to swap receiver / test Bluetooth / instruct replacement or replacement receiver purchase.
Tips & best practices for Bolt
  • Put the Bolt receiver on a rear motherboard USB2 port or on a short passive extension positioned on the desk — good RF geometry still matters.
  • Keep selective suspend off for USB root hubs and Logitech devices in Device Manager (we already disabled earlier).
  • Ensure Windows chipset drivers and BIOS are up to date if you see hub/controller resets.
Quick script you can save for the migration day (copy/paste)
  • Save this as migrate_to_bolt.txt for a checklist:
1) Install Logi Options+ and sign in.
2) Plug Bolt receiver into rear USB2 (use UGreen if available).
3) Options+ → Add Device → Bolt → follow pairing steps for keyboard then mouse.
4) Options+ → Check Firmware → Update if available.
5) Options+ → Restore backup (if present).
6) Test for 15–30 minutes. If drop occurs, run the two PowerShell captures above and attach the files.
If you want I can also:
  • Produce a one‑page printout you can follow while doing the migration step‑by‑step on the day (copyable checklist), or
  • Prepare a short fallback purchase list (one Bolt receiver + inexpensive K650 + MX Master 3S or 4 suggestions) — but you said no checklist needed.
Would you like the small one‑page printable checklist now, or do you want me to stand by and parse any capture files if a drop occurs after you migrate?
 

Can we run the usb_monitor.ps1 script for a few hours to see if there is a drop out.
 

Yes — absolutely. You can run usb_monitor.ps1 for several hours and it will record any USB/Kernel events while you’re away. Below are the exact, copy‑paste commands and a few safety checks so it runs reliably, how to verify it’s running, how to stop it later, and how to get me the log to analyze if a dropout happens.
1) (Optional) Edit interval (if you want more frequent checks)
  • If you want it to check every minute instead of 5 minutes, open the script usb_monitor.ps1 on your Desktop and change:
    $IntervalSeconds = 300
    to, for example:
    $IntervalSeconds = 60
  • Save the file.
2) Start the monitor (Run as Administrator)
  • Open PowerShell as Administrator and run these exact commands (they start the monitor hidden and save its PID so you can stop it later):
$proc = Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Desktop\usb_monitor.ps1"" -WindowStyle Hidden -PassThru
$proc.Id | Out-File "$env:USERPROFILE\Desktop\usb_monitor.pid"
Write-Host "USB monitor started (PID: $($proc.Id)). Log: $env:USERPROFILE\Desktop\USB_Monitor.log"
  • After running, you should see a PID number printed.
3) Verify it’s running (quick)
  • Still in the elevated PowerShell run:
Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid"
Get-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -ErrorAction SilentlyContinue
Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 30
  • The -Tail output will show the header line(s) and any logged events that matched the filter.
4) What to do while it runs
  • Leave the PC alone (keep the spare receiver on UGreen in the rear port). The script will append USB‑related System events to USB_Monitor.log. If a dropout happens while you’re away, do not reboot the PC — the log entries will remain.
5) Stop the monitor when you return (Run as Administrator)
  • If the PID file exists (recommended), run:
Stop-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -Force
Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid" -ErrorAction SilentlyContinue
Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200
  • If you didn’t have a PID file, find the process and stop it:
    Get-WmiObject Win32Process | Where-Object { $.CommandLine -match 'usb_monitor.ps1' } | Select-Object ProcessId,CommandLine

    then stop whichever ProcessId is shown:​

    Stop-Process -Id <ProcessId> -Force
6) If a dropout was logged — what to attach
  • Attach the USB_Monitor.log (or paste the lines near the drop) and/or run the immediate decisive capture (Admin PowerShell) and attach the two files it creates:
$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:
  • USB_Monitor.log (if you used the monitor), and/or
  • MouseDeviceInfo.txt and USB_Events_Last60min.txt (the decisive captures)
7) Timings / notes
  • Recommended run time: a few hours (you said “a few hours”) — the script is low CPU and safe.
  • If you change $IntervalSeconds to 60 the monitor checks every minute (more resolution but more lines). 300 (5 min) is usually fine.
  • If the log is empty after stopping, it likely means the monitor ran without finding any USB/System events that match the filter (good — no drop) or it was not started elevated — check the Start-Process output and the PID file.
8) When you return
  • Stop the monitor, attach USB_Monitor.log (or the two captures above) and tell me the approximate wall time of the drop(s) if you remember — I’ll parse and tell you the single next action (hardware swap vs driver/BIOS update).
If you prefer, I can also show how to schedule the monitor as a Task Scheduler job to run unattended across reboots — but the Start-Process approach is simplest for a one‑off multi‑hour run.
Want me to confirm the exact Stop-Process command to run when you return? (If yes I’ll paste it ready to copy/paste.)
 

MouseDeviceInfo.txt



FriendlyName : HID-compliant vendor-defined device
InstanceId : HID\VID_046D&PID_C52B&MI_02&COL01\8&2038E687&0&0000
Status : OK

FriendlyName : Logitech USB Input Device
InstanceId : USB\VID_046D&PID_C52B&MI_00\7&2FFDA91A&0&0000
Status : OK

FriendlyName : HID-compliant vendor-defined device
InstanceId : HID\VID_046D&PID_C52B&MI_02&COL02\8&2038E687&0&0001
Status : OK

FriendlyName : HID Keyboard Device
InstanceId : HID\VID_046D&PID_C52B&MI_00\8&20E309E7&0&0000
Status : OK

FriendlyName : USB Input Device
InstanceId : USB\VID_046D&PID_C52B&MI_01\7&2FFDA91A&0&0001
Status : OK

FriendlyName : HID-compliant vendor-defined device
InstanceId : HID\VID_046D&PID_C52B&MI_02&COL03\8&2038E687&0&0002
Status : OK

FriendlyName : USB Input Device
InstanceId : USB\VID_046D&PID_C52B&MI_02\7&2FFDA91A&0&0002
Status : OK

FriendlyName : HID-compliant vendor-defined device
InstanceId : HID\VID_046D&PID_C52B&MI_01&COL04\8&8755A42&0&0003
Status : OK

FriendlyName : HID-compliant system controller
InstanceId : HID\VID_046D&PID_C52B&MI_01&COL03\8&8755A42&0&0002
Status : OK

FriendlyName : USB Composite Device
InstanceId : USB\VID_046D&PID_C52B\6&3AE11B61&0&3
Status : OK

FriendlyName : HID-compliant consumer control device
InstanceId : HID\VID_046D&PID_C52B&MI_01&COL02\8&8755A42&0&0001
Status : OK

FriendlyName : HID-compliant mouse
InstanceId : HID\VID_046D&PID_C52B&MI_01&COL01\8&8755A42&0&0000
Status : OK

USB_Events_Last300min.txt



TimeCreated : 22/10/2025 16:57:26
ProviderName : Microsoft-Windows-Ntfs
Id : 98
LevelDisplayName : Information
Message : Volume Windows 10 Professional (\Device\HarddiskVolumeShadowCopy12) is healthy. No action is
needed.

TimeCreated : 22/10/2025 16:55:31
ProviderName : Microsoft-Windows-HttpService
Id : 114
LevelDisplayName : Information
Message : Removed URL (http://*:2869/upnp/eventing/) from URL group (0xFE00000020000001). Process Id 0x1850
Executable path \Device\HarddiskVolume2\Windows\System32\svchost.exe, User S-1-5-19

TimeCreated : 22/10/2025 16:53:20
ProviderName : Microsoft-Windows-HttpService
Id : 113
LevelDisplayName : Information
Message : Attempted to add URL (http://*:2869/upnp/eventing/) to URL group (0xFE00000020000001). Status: 0x0.
Process Id 0x1850 Executable path \Device\HarddiskVolume2\Windows\System32\svchost.exe, User
S-1-5-19

TimeCreated : 22/10/2025 16:53:20
ProviderName : Microsoft-Windows-HttpService
Id : 114
LevelDisplayName : Information
Message : Removed URL (http://*:2869/upnp/eventing/) from URL group (0xFE00000520000001). Process Id 0x1850
Executable path \Device\HarddiskVolume2\Windows\System32\svchost.exe, User S-1-5-19

TimeCreated : 22/10/2025 16:53:16
ProviderName : Microsoft-Windows-HttpService
Id : 113
LevelDisplayName : Information
Message : Attempted to add URL (http://*:2869/upnp/eventing/) to URL group (0xFE00000520000001). Status: 0x0.
Process Id 0x1850 Executable path \Device\HarddiskVolume2\Windows\System32\svchost.exe, User
S-1-5-19

TimeCreated : 22/10/2025 13:47:31
ProviderName : BROWSER
Id : 8033
LevelDisplayName : Information
Message : The browser has forced an election on network
\Device\NetBT_Tcpip_{D5E02D60-AB0F-45A4-8798-B6AACC2E3AF5} because a master browser was stopped.

TimeCreated : 22/10/2025 13:41:58
ProviderName : Microsoft-Windows-Ntfs
Id : 98
LevelDisplayName : Information
Message : Volume Windows 10 Professional (\Device\HarddiskVolumeShadowCopy11) is healthy. No action is
needed.

TimeCreated : 22/10/2025 13:13:39
ProviderName : Microsoft-Windows-Kernel-General
Id : 11
LevelDisplayName : Information
Message : TxR init phase for hive
\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\WINDOWS\System32\config\SOFTWARE (TM:
{5776640a-aef9-11f0-9dc1-faabaee11bb7}, RM: {57766409-aef9-11f0-9dc1-faabaee11bb7}) finished with
result=0xC00000A2 (Internal code=7).

TimeCreated : 22/10/2025 13:13:38
ProviderName : Microsoft-Windows-Kernel-General
Id : 11
LevelDisplayName : Information
Message : TxR init phase for hive
\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\WINDOWS\System32\config\DRIVERS (TM:
{57766407-aef9-11f0-9dc1-faabaee11bb7}, RM: {57766406-aef9-11f0-9dc1-faabaee11bb7}) finished with
result=0xC00000A2 (Internal code=7).

TimeCreated : 22/10/2025 13:13:38
ProviderName : Microsoft-Windows-Kernel-General
Id : 11
LevelDisplayName : Information
Message : TxR init phase for hive
\??\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\WINDOWS\System32\config\SYSTEM (TM:
{57766404-aef9-11f0-9dc1-faabaee11bb7}, RM: {57766403-aef9-11f0-9dc1-faabaee11bb7}) finished with
result=0xC00000A2 (Internal code=7).
 

Attachments

Thanks — I’ve read the two files you pasted.
Short answer (one line)
  • The Windows logs show the Unifying receiver and Logitech HID interfaces are still present (Status: OK) and there are no USB hub / xHCI controller reset messages in the System event extract you supplied — that points to a per‑device radio/session failure (mouse ↔ receiver link), not a full USB host/controller failure.
Why (briefly, with exact evidence)
  • MouseDeviceInfo.txt shows the Logitech Unifying receiver and all Logitech HID interfaces present and Status: OK — Windows still sees the receiver and device endpoints, so the dongle was not removed from the bus.
  • USB_Events_Last300min.txt contains general system messages but no “usb … disconnect”, “reset high‑speed USB device”, “xhci_hcd … port reset” or similar hub/controller error messages around your reported times — so Windows didn’t perform a controller‑level reset. That absence, combined with the Unifying log “Device doesn't respond” entries you provided earlier, matches a device/radio/session problem.
What that means in plain English
  • The mouse’s 2.4 GHz link to the Unifying receiver intermittently lost packets or stopped responding. The host attempted to recover the single mouse endpoint (which you observe as the device needing a power‑cycle or reset). The receiver itself stayed connected to the PC. This is commonly caused by RF interference, poor dongle antenna orientation, USB3/hub noise, or a per‑device firmware/session bug — and it’s exactly the problem that placing the receiver on a short passive USB2 extension (UGreen) usually fixes.
Practical next steps (do these in order)
1) Keep the UGreen + spare receiver where it is and monitor (highest ROI)
  • Leave the spare receiver plugged into the UGreen on a rear motherboard USB2 port and use normally for 24–48 hours. If no more permanent disconnects occur, treat that as your working fix. (You already saw the permanent disconnects stop after doing this.)
2) Quick isolations (only if you want extra certainty)
  • Bluetooth test: pair the MX Master 3 via your Bluetooth dongle and use it for 10–30 minutes.
    • Stable on Bluetooth → mouse hardware is fine; the Unifying link/receiver/placement is the issue.
    • Bluetooth also fails → mouse hardware likely faulty.
  • Cross‑host test: plug the same spare receiver + UGreen into a different, known‑good PC and test. If it’s stable there but not on the main PC → main PC host/driver/BIOS or port issues. If it fails on other PCs too → mouse is likely faulty.
3) If it drops again — capture the decisive Windows logs immediately (do NOT reboot)
  • Run these in an elevated PowerShell as soon as you notice the drop (copy/paste exactly). They save the two small, decisive files to your Desktop which I’ll parse immediately:
$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 both files (MouseDeviceInfo.txt and USB_Events_Last60min.txt) and tell me the approximate wall time(s) of the drop(s). I’ll parse the exact lines and tell you one specific action: either a chipset/USB driver or BIOS update (if it’s a host reset) or replace/replace-receiver or RMA advice (if it’s device‑side).
4) Low‑risk Windows tweaks you can keep (already done some)
  • Keep USB selective suspend disabled and “Allow the computer to turn off this device” unchecked for USB hubs/Logitech entries (you already disabled these; keep that). If the problem reappears with host‑side symptoms I’ll provide the exact chipset driver/BIOS to install.
If you prefer a permanent hardware move now (practical)
  • Because you plan to move to Bolt devices on Black Friday, the simplest routes until then are:
    • Keep the spare receiver + UGreen (temporary fix), or
    • Buy a replacement Unifying receiver (cheap) if you prefer not to use an extension cable.
      Bolt is a good long‑term choice; it’s more robust in crowded RF/USB3 environments.
If you want me to draft an RMA / replacement message
  • You said device is OOW, but if you still want a concise message (for paid support or replacement) I can draft it with the logs and our test summary. Say “Draft RMA” and I’ll prepare copy/paste text.
One small troubleshooting note about your monitor logs
  • Your USB_Monitor.log only showed the “monitor started” lines (the monitor was started late so it didn’t capture the 12:42 event) — that’s why the direct monitor file didn’t contain the earlier drop; the Get‑WinEvent full capture (USB_Events_Last60min.txt) is the right file to run after a drop because it pulls historical event log entries.
If you want, I’ll:
  • Wait here and parse the two files as soon as you attach them after the next drop, or
  • Draft a short RMA text now for you to keep ready.
Which do you prefer?
 

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! Installing PowerShell on Windows - PowerShell

PS C:\WINDOWS\system32> $proc = Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File `"$env:USERPROFILE\Desktop\usb_monitor.ps1`"" -WindowStyle Hidden -PassThru
PS C:\WINDOWS\system32> $proc.Id | Out-File "$env:USERPROFILE\Desktop\usb_monitor.pid"
PS C:\WINDOWS\system32> Write-Host "USB monitor started (PID: $($proc.Id)). Log: $env:USERPROFILE\Desktop\USB_Monitor.log"
USB monitor started (PID: 18868). Log: C:\Users\rupes\Desktop\USB_Monitor.log
PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid"
18868
PS C:\WINDOWS\system32> Get-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -ErrorAction SilentlyContinue

Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
581 30 63576 78072 0.69 18868 3 powershell


PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 30
--- USB monitor started at 2025-10-22T12:53:41.9553191+01:00 ---
--- USB monitor started at 2025-10-22T17:25:34.8376479+01:00 ---
PS C:\WINDOWS\system32> Stop-Process -Id 18868 -Force
PS C:\WINDOWS\system32> Get-Process -Id 18868 -ErrorAction SilentlyContinue
PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200
--- USB monitor started at 2025-10-22T12:53:41.9553191+01:00 ---
--- USB monitor started at 2025-10-22T17:25:34.8376479+01:00 ---
PS C:\WINDOWS\system32> Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid" -ErrorAction SilentlyContinue
PS C:\WINDOWS\system32> $start = (Get-Date).AddMinutes(-300)
PS C:\WINDOWS\system32> Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID_0A5C' } | Format-List FriendlyName,InstanceId,Status | Out-File "$env:USERPROFILE\Desktop\MouseDeviceInfo.txt"
PS C:\WINDOWS\system32> 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_Last300min.txt"
PS C:\WINDOWS\system32> $proc = Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Desktop\usb_monitor.ps1"" -WindowStyle Hidden -PassThru
Start-Process : A positional parameter cannot be found that accepts argument 'C:\Users\rupes\Desktop\usb_monitor.ps1'.
At line:1 char:9
+ $proc = Start-Process -FilePath "powershell.exe" -ArgumentList "-NoPr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Start-Process], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.StartProcessCommand

PS C:\WINDOWS\system32> $proc.Id | Out-File "$env:USERPROFILE\Desktop\usb_monitor.pid"
PS C:\WINDOWS\system32> Write-Host "USB monitor started (PID: $($proc.Id)). Log: $env:USERPROFILE\Desktop\USB_Monitor.log"
USB monitor started (PID: 18868). Log: C:\Users\rupes\Desktop\USB_Monitor.log
PS C:\WINDOWS\system32> Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid"
>> Get-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -ErrorAction SilentlyContinue
>> Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 30
18868
--- USB monitor started at 2025-10-22T12:53:41.9553191+01:00 ---
--- USB monitor started at 2025-10-22T17:25:34.8376479+01:00 ---
PS C:\WINDOWS\system32>
 

Thanks — that’s everything I needed. Short, clear summary first, then the exact next steps you can follow.
Quick conclusion (one line)
  • The Windows captures you posted show the Unifying receiver and Logitech HID interfaces are still present (Status: OK) and there are no controller/hub/xHCI reset events in the System event extract — that points to a per‑device radio/session problem (mouse ↔ receiver), not a full USB host/controller failure.
Why I conclude that (evidence)
  • MouseDeviceInfo.txt shows the receiver and the Logitech HID endpoints are present and Status: OK (Windows still sees the device).
  • USB_Events_Last300min.txt contains general system messages but no “usb … disconnect”, “reset high‑speed USB device”, or xhci_hcd / ehci_hcd hub/controller reset messages around the times you reported.
    Together that pattern (receiver present + no controller resets) is exactly what we saw earlier from the Slax logs and the Unifying report’s “Device doesn’t respond” lines: the mouse’s Unifying radio channel flaked rather than the USB controller dropping entirely.
Exactly what to do next (prioritized, minimal effort)
1) Keep the UGreen + spare receiver in the rear USB2 port (do this now)
  • This is the high‑ROI practical fix. You already saw permanent disconnects stop after moving the receiver to the passive extension — leave it plugged in and test for 24–48 hours. If it’s stable, consider that your long‑term working solution.
2) Quick isolations (pick one or do both)
  • Bluetooth test (fast): pair the MX Master 3 to your Bluetooth dongle and use for 10–30 minutes.
    • If Bluetooth is stable while Unifying was flaky → the issue is the Unifying link/receiver/placement.
    • If Bluetooth also disconnects → the mouse hardware or OS/host likely at fault.
  • Cross‑host test (decisive): plug the spare receiver + UGreen into a different known‑good PC and test the mouse for 10–30 minutes.
    • Stable on other PC but flaky on your main PC → issue likely host/driver/BIOS on your main PC.
    • Fails on other PC too → the mouse is likely faulty (or both receivers share a problem).
3) If a drop happens again — capture the decisive Windows logs immediately (do NOT reboot)
Run these two commands in an elevated PowerShell as soon as you notice the next drop (copy/paste exactly). They save two small files to your Desktop; attach both and I’ll parse them immediately and tell you the single next action.
$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 give one precise remediation:
    • If controller/hub/xhci resets appear → I’ll point to the exact chipset/USB driver or BIOS update (single download + steps).
    • If receiver remains present and only device retries or “device doesn’t respond” appear → I’ll recommend swapping receivers / Bluetooth test or hardware replacement.
4) Temporary hardware choices (simple)
  • Keep the spare receiver + UGreen as your temporary long‑term workaround.
  • If you prefer not to use an extension, buying a new Unifying receiver is cheap and often fixes the symptom; buying Bolt gear (your Black Friday plan) is a better long‑term move.
5) If you want a written RMA/support note for Logitech (even out‑of‑warranty)
  • I can draft a concise message summarizing tests and logs you can copy/paste. Say “Draft RMA” and I’ll prepare it. (Given OOW, buying replacement Bolt gear as you plan is probably the best ROI.)
Extra quick notes you may find helpful
  • You already disabled USB selective suspend / power‑save for hubs and Logitech entries — keep those settings.
  • The monitor you ran only logged “monitor started” entries because it was started after the 12:42 event; the Get‑WinEvent capture (the two files above) is the reliable way to pull historical entries for past drops.
If you want me to do anything now
  • If you’ve already run the two commands for the 12:42 window (or the 300‑minute one I suggested earlier), attach those files now and I’ll parse them and give the single next action.
  • Otherwise, leave the UGreen in place and do the Bluetooth/cross‑host tests when convenient; if anything drops, run the two capture commands above and attach the files.
Would you like me to draft the RMA message (ready to paste) now, or wait until you run the Bluetooth / cross‑host tests / next log capture?
 

Back
Top