Thanks — that report is helpful. I’ll summarize what it shows, what that means, and give a short, prioritized test & next‑steps list so you can conclusively determine whether the MX Master 3 or the original Unifying receiver is faulty — plus a ready RMA message if you need it.
What the Logitech System Report shows (key lines you pasted)
- Receiver:
- ModelId 0x46dc52b, Serial F19493C9
- Receiver firmware: 024.001.00023
- Keyboard K800 firmware: 022.001.00019
- Mouse MX Master 3 firmware: 019.001.00015
- Log events (timestamps shown in the report):
- DFU requested on MX Master 3.
- K800 and MX Master 3 were unpaired and then re‑paired successfully (timestamps ~12:08).
- After pairing, multiple log lines: “Device doesn't respond!! Current retry count: 0” (examples at 12:08:23, 12:12:05, 12:12:42).
What this means (straightforward)
- The “Device doesn't respond” entries in the Unifying software log mean the Unifying stack sent commands to the wireless device and did not receive the expected reply. That is a per‑device failure to respond — consistent with a radio/session failure of the mouse or the receiver not being able to talk to that particular device.
- You already have other evidence (Slax dmesg + lsusb and the fact that adding the UGreen extension stopped permanent disconnects) that this is not a whole‑host USB controller crash but a per‑device radio/session issue.
- The report shows pairing succeeded but then the device stopped responding, which tends to point at the mouse (or its interaction with that receiver) rather than an immediate driver/host crash.
Short, prioritized plan to prove “mouse vs receiver” (do these in order)
1) Keep the spare receiver + UGreen in use (you already did)
- Do this for 15–30 minutes. If stable, that suggests the original receiver (or its placement) was the cause.
2) Quick Bluetooth isolate (fast)
- Pair the MX Master 3 via Bluetooth and use it for 10–30 minutes.
- Interpretation:
- If Bluetooth is rock‑stable: the mouse Bluetooth radio & internals are OK and the problem is the Unifying link/receiver (or RF placement).
- If Bluetooth also misbehaves: the mouse hardware is likely faulty.
3) Swap test across hosts (decisive)
- Plug the spare receiver + UGreen into another known‑good PC and test the same mouse there for 10–30 minutes.
- Interpretation:
- If stable on the other PC but flaky on your main PC → host/driver/BIOS/power issue on the main PC (we’ll address drivers/BIOS).
- If it fails on the other PC as well (with the same mouse) → the mouse is likely faulty.
4) Swap receivers (simple)
- Put the original receiver on the same UGreen + same port and test briefly, then swap back to the spare receiver (no other changes).
- Interpretation:
- Original fails, spare OK → original receiver likely faulty.
- Both fail → likely mouse or host.
5) If a drop occurs: capture decisive Windows evidence (do NOT reboot)
- Immediately run these commands in an elevated PowerShell (exact; copy/paste). They produce two small Desktop files to attach here — I’ll parse them and tell you the one exact remediation.
$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 TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
- Attach MouseDeviceInfo.txt and USB_Events_Last10min.txt; I’ll parse and give a single action (driver/BIOS update vs RMA). These two files are decisive.
Recommendation based on your current status
- Because you’ve already paired to a spare receiver on the UGreen and (so far) stability improved, the odds are the original receiver or its placement was the issue. But you now want the definitive test — do the Bluetooth test and/or the cross‑host test tomorrow. That will quickly tell you whether the mouse or receiver is at fault.
If the mouse is determined faulty — RMA text (copy/paste)
If your tests show the fault follows the mouse (i.e., fails with spare receivers and on another PC), use this text to open an RMA with Logitech (include your logs/attachments):
Subject: MX Master 3 intermittent disconnect — request RMA
Hello Logitech support,
I have an MX Master 3 (firmware 19.1.15, serial 4082-F0-B8-D2-89) that intermittently loses its Unifying link and requires a power‑cycle to recover. Summary of tests I performed:
- Paired & tested under Linux (Slax live): observed transient disconnects and one permanent disconnect that required mouse power‑cycle; captured kernel logs.
- Cross‑tested same receiver + mouse on an HP ProLiant server (Windows Server 2022) — stable.
- Moved receiver to a passive USB‑2.0 extension on rear motherboard USB2 port — this prevented permanent disconnects for a period.
- Unpaired/paired using Unifying Utility and saved a System Report (attached). The Unifying log shows “Device doesn't respond!!” entries after pairing (indicating the mouse stopped responding to the receiver).
- I also tested with a spare Unifying receiver and Bluetooth (results: describe your results here).
Given that the device does not respond to the receiver and the issue persists across multiple receivers / hosts (if that’s what you observed), I believe the mouse hardware is defective and request RMA. I have attached the System Report and the small Windows event logs showing the disconnect time(s). Please advise next steps for RMA.
Thanks,
[your name]
(If you want I’ll tailor that text with your final test results and the exact file attachments.)
Would you like me to:
- Wait while you run the Bluetooth and cross‑host tests and then parse the files if a drop occurs; or
- Draft the RMA message now (ready to send) so you have it prepared?
Either way I’ll parse any files you attach (the two PowerShell outputs above or the System Report) and give the single next step immediately.