Logitech MX Master 3 losing connectivity

• Attach C:\Users\<yourname>\Desktop\USB_Monitor.log to your reply (paperclip).
  If the file is large or you only want to send the last hour, just attach USB_Monitor.log anyway — it will still be small.

• The command you ran started a hidden PowerShell process that runs usb_monitor.ps1:
  Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Desktop\usb_monitor.ps1"" -WindowStyle Hidden

• Leave the machine alone and keep the Unifying receiver in the UGreen on the rear USB2 port (as you already did). The monitor will append USB-related System events to:
  C:\Users\<your‑username>\Desktop\USB_Monitor.log

1. Stop the monitor (safe) — two ways (use either)
   • If you created a PID file earlier (usb_monitor.pid):
     
     Code:

     Stop-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -Force
     Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid"

   • If you did NOT create a PID file (your case), find the running process by command line and stop it:
     
     Code:

     # find the process running the monitor
     Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -like '*usb_monitor.ps1*' } | Select-Object ProcessId, CommandLine

   stop it (only if it shows up)​

   Get-CimInstance Win32Process | Where-Object { $.CommandLine -like 'usb_monitor.ps1' } |
   ForEach-Object { Stop-Process -Id $.ProcessId -Force; "Stopped process id: $($.ProcessId)" }
2. Verify the monitor produced the log and view the end of the file:
   
   Code:

   Test-Path "$env:USERPROFILE\Desktop\USB_Monitor.log" # returns True if log exists
   Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200

   • If the file is empty, the script may not have been started as Administrator or it errored — see troubleshooting below.

• If you saw a dropout or your log shows a suspicious timestamp, run these two commands (Admin PowerShell) to produce the decisive two files I need — attach both files here and I’ll parse them immediately:
  
  Code:

  $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" 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' } |
  Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message |
  Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"

• Attach MouseDeviceInfo.txt and USB_Events_Last10min.txt (or paste their contents).

• If the System events show “usb … disconnect”, “reset high‑speed USB device”, or xhci_hcd/ehci_hcd errors at the drop time → host/controller problem (I’ll point to the specific chipset/USB driver or BIOS update).
• If the receiver stayed present and the events show only per‑device retries or “device doesn’t respond” (as in your Unifying log earlier), that points to the mouse ↔ receiver radio/session — we’ll try the spare receiver / Bluetooth test or RMA the mouse. (Your Unifying report contained “Device doesn't respond!!” entries.

• Confirm you started it elevated (Run as Administrator). If not, restart it with an elevated PowerShell using the Start-Process command I gave earlier (or run usb_monitor.ps1 interactively in the elevated window).
• Check for the script file on Desktop:
  Test-Path "$env:USERPROFILE\Desktop\usb_monitor.ps1"
  If missing, re-create it (I gave the full script earlier). If it exists but the log is empty, run one iteration interactively to check for errors:
  
  Code:

  # run once to test (in Admin PowerShell)
  & "$env:USERPROFILE\Desktop\usb_monitor.ps1"
  # then Ctrl+C to interrupt after a few seconds; check USB_Monitor.log
  Get-Content "$env:USERPROFILE\Desktop\USB_Monitor.log" -Tail 200

• If you only remember “around 12:42”, search for lines containing “12:4” (will match 12:40–12:49):
  Select-String -Path "$env:USERPROFILE\Desktop\USB_Monitor.log" -Pattern '12:4'
• Or filter a date/time range (the log uses ISO timestamps). Example for Oct 22, 2025 around 12:42:
  Select-String -Path "$env:USERPROFILE\Desktop\USB_Monitor.log" -Pattern '2025-10-22T12:4'

• I can give you a short Task Scheduler recipe that runs USBLogView’s CLI to export every 5 minutes; the PowerShell monitor is simpler and needs no scheduler, though.

• Monitor: started (you ran Start-Process).
• Receiver: spare receiver + UGreen in rear USB2 port — leave it.
• If a dropout happened: when you’re back, stop the monitor, and attach USB_Monitor.log; or run the two PowerShell capture commands above (MouseDeviceInfo.txt + USB_Events_Last10min.txt) and attach them.

• Attach these two files from your Desktop:
  • C:\Users\<yourname>\Desktop\MouseDeviceInfo.txt
  • C:\Users\<yourname>\Desktop\USB_Events_Last10min.txt
    If one or both are empty, re-run with a larger time window (captures the last 30 minutes):

1. Stop the monitor (Admin PowerShell):
   $pidobj = Get-WmiObject Win32Process | Where-Object { $.CommandLine -match 'usb_monitor.ps1' }
   if ($pidobj) { Stop-Process -Id $pidobj.ProcessId -Force; Write-Host "Stopped usb_monitor (PID $($pidobj.ProcessId)." } else { Write-Host "usb_monitor not found." }
2. Then open or attach the log:
   C:\Users\<yourname>\Desktop\USB_Monitor.log

• Exact event lines near 12:55. I’ll extract and highlight:
  • Any “usb … disconnect”, “reset high‑speed USB device”, or xhci_hcd / ehci_hcd / USBHUB messages at the drop time (those show a host/controller reset).
  • Whether the Unifying receiver stayed enumerated (MouseDeviceInfo will show the receiver & device statuses). If the receiver stays present but only the mouse endpoint is being reset or shows retries, that indicates a device/radio/session issue.
• I’ll then give one single next action (update driver/BIOS and change port if host resets are present, or try spare receiver/Bluetooth/RMA if device‑side). This is the same decisive test we’ve been using.

• If the System events show a hub/controller port reset at 12:55 → update a specific chipset/USB driver or BIOS. If the receiver stayed present but the mouse endpoint failed → the problem is the mouse ↔ receiver radio/session (try Bluetooth or a different receiver and prepare an RMA if it follows the mouse).

• Paste the full contents of the two files here (MouseDeviceInfo.txt and USB_Events_Last10min.txt or -30min). I’ll parse them in‑line and reply instantly.

• Pull the exact log lines that decide host vs device,
• Explain in plain English what they mean, and
• Tell you the single next step to fix it.

find the monitor process (shows ProcessId and CommandLine)​

if the previous line printed a ProcessId (for example 1234), stop it:​

show last 200 lines of the monitor log​

• If USB_Events_Last10min.txt is empty, re-run with AddMinutes(-30) to capture a larger window:
  $start = (Get-Date).AddMinutes(-30)

• Attach these files from your Desktop (paperclip/Attach files):
  • USB_Monitor.log (if you used the monitor), and/or
  • MouseDeviceInfo.txt and USB_Events_Last10min.txt (the immediate capture above).
• Tell me the approximate wall time of the dropout (you already said ~12:42 — fine). I’ll parse the logs and post the exact kernel / event lines that decide host controller reset vs device radio/session failure and then give the single next action (update a driver/BIOS, keep UGreen, swap receiver, or RMA).

• Show how to export USBLogView snapshots periodically using Task Scheduler (if you prefer that tool over the PowerShell monitor), or
• Draft the RMA/support text ready to paste (only if logs show the mouse itself is at fault).

• You started the usb_monitor.ps1 before you left and reported at least one permanent drop while you were out (~12:42–12:55 window). I’ll use the logs you produce to decide whether Windows reset the USB host/controller or the mouse/receiver radio/session failed.

Note the ProcessId(s) printed, then run:​

• I used AddMinutes(-30) to cover a larger window; change to -10 if you want a narrower slice.
• Important: run these interactively in the same PowerShell session (don’t paste them into a saved .ps1) so $start is defined and used.
• Do NOT reboot before running these commands — reboot clears the events we need.

• MouseDeviceInfo.txt
• USB_Events_Last30min.txt
• (Optional) USB_Monitor.log if it exists

• Look for kernel/USB event lines like “usb … disconnect”, “reset high‑speed USB device”, xhci_hcd / ehci_hcd / USBHUB messages (these indicate a host/controller reset), or for only device‑level retries / “device doesn't respond” (these indicate a mouse ↔ receiver radio/session issue).
• Then I’ll give the one exact next step: update a specific chipset/USB driver or BIOS if it’s a host reset, or swap receiver / Bluetooth / RMA wording if it’s device/radio.

• If Get-WinEvent returns no results, increase the window (AddMinutes(-60) and re-run the Get-WinEvent line.
• If the monitor log is empty, the monitor may have started without Admin rights. Restart it with the Start-Process command (copy/paste into an elevated PowerShell):

• Open Event Viewer → Windows Logs → System → Action → Filter Current Log → in the XML or Message filter include keywords: Kernel‑PnP, USB, USBHUB, xhci_hcd; set time range to the drop time; export the filtered results to a file and attach it.

• The errors you saw came from two things: using Get‑WmiObject vs Get‑CimInstance, and using $.ProviderName / $.Message instead of the correct pipeline variable $.ProviderName and $.Message. The corrected commands above use the working $_ variable and Get‑CimInstance for process search if you need to find the monitor process.

• Look for a powershell.exe with a StartTime close to when you ran Start-Process (about 11:54). Note its Id.

1. Open PowerShell as Administrator.
2. Run this to list all running PowerShell processes and their StartTime so you can identify the one you started (~11:54):

1. Look for the entry whose StartTime matches when you launched the monitor (about 11:54). Note its Id (PID).
2. Stop that PID (replace <PID> with the number you saw):

1. Confirm it stopped:

note the ProcessId printed, then:​

stop powershells started in the last 3 hours​

1. Check the monitor log (show last 200 lines):

1. If it contains entries around the time you reported (~12:42), attach USB_Monitor.log to your reply (paperclip). I’ll parse it and extract the USB/kernel lines that matter.

• Attach both Desktop files (MouseDeviceInfo.txt and USB_Events_Last10min.txt) and tell me the approximate wall clock time of the drop (12:42 is fine). I’ll parse those immediately and tell you exactly whether Windows reset the host/controller (driver/BIOS fix) or whether it was a per‑device radio/session failure (swap/RMA advice).

• It likely wasn’t running with Admin rights. Re‑start it elevated (I can paste the exact Start-Process command again) or use the above immediate capture when the next drop happens.

• Stop the monitor using Option A (Get-Process → Stop-Process).
• Inspect USB_Monitor.log (Get-Content … -Tail 200) and attach if it contains entries near 12:42.
• If you already have the two Windows captures, attach MouseDeviceInfo.txt and USB_Events_Last10min.txt now.
• I’ll parse the logs and give the single next action (driver/BIOS update vs swap/RMA).

• If you want to stop any background monitor now, run this (Admin PowerShell). It will stop PID 20336 you listed:

• After those finish, attach both files from your Desktop:
  • MouseDeviceInfo.txt
  • USB_Events_Last60min.txt

• The System events (USB_Events_Last60min.txt) will show whether Windows performed a hub/controller/xHCI reset at the drop time (which points to a host/controller problem) or whether you’ll see only per‑device retries / “device doesn’t respond” entries while the Unifying receiver remains present (which points to a mouse‑side radio/session failure). The device list (MouseDeviceInfo.txt) shows whether Windows still sees the receiver and mouse and their Status. Together they’re decisive.

• Your earlier Linux + Unifying report evidence (device stayed enumerated; dmesg showing per‑device reset and Unifying log “Device doesn't respond!!”) already strongly pointed at a mouse ↔ receiver radio/session problem rather than the whole USB controller crashing. Keeping the receiver on the UGreen extension fixed the permanent disconnects earlier — that’s the highest‑ROI workaround. We’ll confirm that for the 12:42 drop from these Windows logs.

• You can open each Desktop file and paste the full contents into your reply (they’re small). I’ll parse inline.

• Say “Stop it” and I’ll assume you want to terminate PID 20336 and give the exact one‑line to paste in elevated PowerShell (Stop-Process -Id 20336 -Force).