Thanks — helpful update. The disconnect confirms this is host/USB/hub related (since the mouse + receiver were stable on another PC). Your earlier PowerShell attempts didn’t show USB provider events because the filter/commands didn’t match the actual messages. Let’s capture the right device info and the relevant System events immediately after the next drop so I can read the exact Kernel/USB errors.
Please do the following right after the next time the mouse loses channel 1 (do not reboot yet). Copy/paste each command & its output back here, or run the small script below which saves the outputs to your Desktop so you can attach them.
1) Find Logitech/Unifying devices (one command)
Run in an elevated PowerShell (Run as Administrator):
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID_0A5C' } | Format-List FriendlyName,InstanceId,Status
This lists any devices with Logitech (VID_046D) or Unifying vendor (VID_0A5C). Paste the output.
2) Show all present USB devices (so we can see the receiver entry)
Run:
Get-PnpDevice -PresentOnly -Class USB | Format-List FriendlyName,InstanceId,Status
If this returns a very large list, just paste the parts that include your Logitech/Unifying VID/PID lines.
3) Capture recent System USB / Kernel‑PnP events (last 10 minutes)
Run:
$start=(Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} |
Where-Object { $_.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|Usb' } |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-List
Paste the output (or attach). I’m looking for lines that show "device removed", "port reset", "USB error", "USB controller reset", or similar — these tell us whether Windows reset the port or the device vanished.
If you prefer the script to save files (run as Administrator). It will write two text files to your Desktop you can copy/paste or attach:
$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\Mouse_Device_Info.txt"
Get-PnpDevice -PresentOnly -Class USB | Format-List FriendlyName,InstanceId,Status | Out-File "$env:USERPROFILE\Desktop\All_USB
Devices.txt"
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} | Where-Object { $.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|Usb' } | Select TimeCreated, ProviderName, Id, LevelDisplayName, Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
Run that immediately after the drop, then attach the three files or paste the contents. If you don’t want files, paste the outputs from commands 1 and 3 above.
A few practical reminders (so the capture is useful)
- Capture the logs immediately after a drop — wait no more than a couple of minutes.
- If you moved the receiver between ports during testing, mention which port you were using (rear motherboard port, front panel, Belkin hub, Anker hub) and whether any other USB device was attached to the same hub.
- If you see a Kernel‑PnP entry that mentions a specific InstanceId or VID/PID (for example VID_046D&PID_C52B), paste that exact message — it’s the key clue.
If the capture shows a USB port reset / controller error, next steps will be: update chipset drivers and BIOS, move the receiver to a different host controller, or keep it on an extension to the rear port. If the capture shows no USB reset and the device simply drops the radio session, we’ll focus on re‑pairing or receiver replacement (RMA).
Run the two short commands (or the script) after the next drop and paste the results here — I’ll parse them and tell you the single next action to fix this.
