Logitech MX Master 3 losing connectivity

Distorted Vision

Senior Member
Joined
Jun 18, 2022
Messages
480
I am running Windows 11.

The PC is assigned to 1 of 3 in the Easy-Switch. When it loses connectivity the '1' light is no longer lit. Issue is only resolved by powering off the mouse and powering back on.

I have tried:

Charging the mouse overnight
Moved the Logitech Unifying Receiver to different USB ports
Checked for new firmware and updates for Logi Options+
 
Sort by date Sort by votes
Thanks — good work swapping receivers and using the UGreen. Two quick points before tests/instructions:
  • I can’t reliably read the System Report you attached in the previous post from my side right now. If you want me to parse it I’ll need you to either re‑attach the report file here, or paste the three small sections I list below. Once I have that I’ll extract firmware, pairing and any error entries and tell you exactly which piece is likely at fault.
  • Based on the captures you already gave and your UGreen result, the evidence so far points to a per‑device radio/session problem (mouse ↔ receiver) rather than the PC’s USB controller — the UGreen fix stopping permanent disconnects is the key piece of evidence.
If you want me to parse the System Report now
  • Re‑attach the report file (paperclip / Attach files) or paste these three sections (copy/paste exactly) from the report into your reply:
    1) Device / Firmware info for the MX Master 3 (firmware version shown).
    2) Receiver (Unifying) firmware and serial/ID.
    3) Any “Event Log”, “Errors” or “Diagnostics” section (even a few lines around any timestamps or error entries).
    I’ll parse those and tell you precisely whether the report shows a device or receiver fault and whether an RMA is warranted.
If you prefer to run quick isolation tests now (recommended order)
1) Confirm spare receiver on UGreen (you already did) — observe 15–30 minutes. If it’s stable, the original receiver was likely the problem.
2) Bluetooth test (fast): pair the MX Master 3 to Bluetooth and use for 10–30 minutes.
  • Stable over Bluetooth → Unifying link/receiver or RF geometry is the problem.
  • Bluetooth also fails → mouse hardware or PC host likely at fault.
    3) Cross‑host test (decisive): plug the same spare receiver + UGreen into another known‑good PC and test 10–30 minutes.
  • Works on other PC but not on yours → host/driver/BIOS or power settings on your PC.
  • Fails on other PC too → mouse or receiver hardware fault (depending on which component follows the failure).
    4) Swap receivers again quickly on the same PC (original vs spare, same port + same UGreen) and test a short time:
  • Original fails, spare OK → original receiver faulty.
  • Both fail → likely mouse or PC host problem.
If a drop occurs during any test — capture decisive Windows logs (do NOT reboot)
Run these three lines immediately in an elevated PowerShell right after the drop (copy/paste). They create two small files on your Desktop that you can attach here; I’ll parse them immediately and give the single remedial step:
$start = (Get-Date).AddMinutes(-10)
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' } | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
  • Attach MouseDeviceInfo.txt and USB_Events_Last10min.txt here; I’ll examine timestamps and tell you exactly whether it’s a host/controller reset (in which case I’ll give one specific driver/BIOS to install) or a device radio/session fault (in which case I’ll advise the swap/RMA wording).
What I’ll do when you send the System Report or the two Windows files
  • Parse and extract: firmware versions, pairing entries, any error lines or repeated reset messages, and the events nearest the drop time. Then give the one next action (keep UGreen, update a specific driver/BIOS, try a replacement receiver, or RMA the mouse).
If you want an RMA message prepared now
  • I can draft a short copy/paste RMA/support message that includes the test summary and what logs to attach; say “Draft RMA” and I’ll prepare it, but I’d only send it if the cross‑host and Bluetooth tests indicate the mouse itself is at fault.
Which do you want to do now?
  • Re‑attach the System Report for me to parse now, or
  • Run the Bluetooth / cross‑host tests and (if a drop recurs) run the two PowerShell capture commands and attach those two resulting files.
I’ll wait for whichever you choose and parse immediately when you attach the files.
 
Upvote 0 Downvote
Logitech® Unifying Software Version : 2.52.33
Dj Api Version : 2, 52, 33

Receiver
Name : Unifying Receiver
ModelId : 0x46dc52b
Serial Number : F19493C9
Handle : 0xff000001
Wireless Status : 0x3
Firmware version : 024.001.00023
Bootloader version : BL.001.008
Dfu Status : 0x1
Is Dfu Cancellable : Yes
Max Device Capacity : 6

Keyboard
Name : K800
ModelId : 0x32010
Serial Number : 2010-F7-D9-3F-41
Handle : 0x1000005
Wireless Status : 0x0
Firmware version : 022.001.00019
Bootloader version : BL.002.001
Dfu Status : 0x1
Is Dfu Cancellable : No
Battery Status : 0x2
Parent Handle : 0xff000001

Mouse
Name : MX Master 3
ModelId : 0x34082
Serial Number : 4082-F0-B8-D2-89
Handle : 0x2000006
Wireless Status : 0x0
Firmware version : 019.001.00015
Bootloader version : BL.9500.013
Dfu Status : 0x1
Is Dfu Cancellable : No
Battery Status : 0x3
Parent Handle : 0xff000001


[12:04:14:0799]: ----------[10-22-2025]------------------------- Unifying API ------------------------------------
[12:04:14:0799]: <14996>Unifying Loaded DLL: 2.52.33
[12:05:12:0111]: -------------------------------------------------------------------------------------------------
[12:05:27:0824]: ----------[10-22-2025]------------------------- Unifying API ------------------------------------
[12:05:27:0824]: <16580>Unifying Loaded DLL: 2.52.33
[12:05:41:0858]: <16580>DJ_DisconnectDevice( 0x2000003, Unpairing Wireless Device : Wireless Device Model ID = 0x32010 , Wireless Device Serial No = 2010-F7-D9-3F-41 ).
[12:05:41:0920]: <16580>Device [K800 - 2010-F7-D9-3F-41] successfully unpaired.
[12:06:00:0086]: <16580>DFU requested on [MX Master 3 - 4082-F0-B8-D2-89] - Action ID [0]
[12:06:09:0360]: <16580>DJ_DisconnectDevice( 0x1000002, Unpairing Wireless Device : Wireless Device Model ID = 0x34082 , Wireless Device Serial No = 4082-F0-B8-D2-89 ).
[12:06:09:0419]: <16580>Device [MX Master 3 - 4082-F0-B8-D2-89] successfully unpaired.
[12:06:15:0929]: -------------------------------------------------------------------------------------------------
[12:07:39:0935]: ----------[10-22-2025]------------------------- Unifying API ------------------------------------
[12:07:39:0935]: <12412>Unifying Loaded DLL: 2.52.33
[12:07:56:0094]: <12412>DJ_DisconnectDevice( 0x3000004, Unpairing Wireless Device : Wireless Device Model ID = 0x34004 , Wireless Device Serial No = 4004-33-4C-2F-0F ).
[12:07:56:0156]: <12412>Device [K360 - 4004-33-4C-2F-0F] successfully unpaired.
[12:07:59:0123]: <12412>DJ_DisconnectDevice( 0x2000003, Unpairing Wireless Device : Wireless Device Model ID = 0x3101a , Wireless Device Serial No = 101A-61-78-46-1B ).
[12:07:59:0185]: <12412>Device [Performance MX - 101A-61-78-46-1B] successfully unpaired.
[12:08:02:0205]: <12412>DJ_DisconnectDevice( 0x1000002, Unpairing Wireless Device : Wireless Device Model ID = 0x32010 , Wireless Device Serial No = 2010-F7-D9-3F-41 ).
[12:08:02:0264]: <12412>Device [K800 - 2010-F7-D9-3F-41] successfully unpaired.
[12:08:07:0960]: <18028>New Pairing successful: Device [K800 - 2010-F7-D9-3F-41]
[12:08:16:0710]: <18028>New Pairing successful: Device [MX Master 3 - 4082-F0-B8-D2-89]
[12:08:23:0138]: <5704> Device doesn't respond!! Current retry count: 0
[12:12:05:0732]: <18028> Device doesn't respond!! Current retry count: 0
[12:12:42:0146]: <18028> Device doesn't respond!! Current retry count: 0
Log content displays the 100% of the available one.
 
Upvote 0 Downvote
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|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' } | 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.
 
Upvote 0 Downvote
I have to run some errands now so will return back in a few hours. Want to check for longer than 30 minutes with the new Unifying receiver to see if there are any dropouts. I've found the Bluetooth adaptor so that is a possible next step.
 
Upvote 0 Downvote
Sounds good — that’s a sensible plan. Quick checklist you can follow now, plus exactly what to do if a dropout happens while you’re out so we can diagnose quickly when you return.
Before you go (1–2 minutes)
  • Leave the Unifying receiver plugged into the UGreen passive USB‑2.0 extension in the rear motherboard USB2 port (don’t move it). This is your test configuration.
  • Note the local time you start the test (wall clock; e.g. 11:35). A 2–4 hour run is ideal, but checking for 1–2 hours will also give useful data.
What to test while you’re out
  • Use the mouse normally for at least 30–120 minutes. If you want more confidence, test for several hours.
If a dropout happens while you’re away (what to capture — do this immediately when you come back)
1) Record the wall clock time(s) you saw the dropout (HH:MM:SS).
2) Do NOT reboot the PC. Run these commands in an elevated PowerShell (copy/paste exactly). They create two small files on your Desktop that I’ll parse:
$start = (Get-Date).AddMinutes(-10)
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' } | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
  • Attach the two files (MouseDeviceInfo.txt and USB_Events_Last10min.txt) to your reply and paste the wall‑clock time(s). I’ll parse them immediately and tell you the single next action (driver/BIOS vs device RMA).
If you want to try Bluetooth while you’re out / when you return (quick isolate)
  • Pair the MX Master 3 via your Bluetooth adapter: Settings → Bluetooth & devices → Add device → Bluetooth → put the MX Master in Bluetooth pairing mode → complete pairing.
  • Use it over Bluetooth for 10–30 minutes. Interpretation:
    • If Bluetooth is stable and Unifying had issues before → Unifying link/receiver/placement is implicated.
    • If Bluetooth also drops → mouse hardware or host likely at fault.
Optional follow‑ups you can do later (if you want a conclusive result)
  • Cross‑host test: plug the spare receiver + UGreen into another PC and test the mouse. If it fails there too, the mouse is probably faulty; if it’s stable there, the problem is likely specific to this PC/receiver combination.
If you have a drop and prefer I prepare an RMA message now
  • I can draft a ready‑to‑paste RMA/support message for Logitech that includes the tests you ran and the logs to attach. I’ll wait until you confirm whether you want that now or only if the evidence points to device fault.
Summary / what I’ll do when you return
  • You: run the test and (if any dropout) attach MouseDeviceInfo.txt and USB_Events_Last10min.txt plus the wall time(s).
  • Me: parse those two files immediately, show the exact event lines that decide host vs device, and give one precise next action.
Have a good errand run — I’ll be here when you return to parse the files and pick the single next step.
 
Upvote 0 Downvote
Good question — you’re right, you can’t actively “test” while you’re out. What I meant was set up automatic logging or leave the working setup in place so any future drop will be recorded for you to inspect when you return. Two simple, practical options — pick the one that’s easiest for you.
Option 1 — easiest (leave it running, check later)
  • Leave the spare Unifying receiver plugged into the UGreen extension in the rear USB2 port (what you already did).
  • Use the mouse normally when you’re around. If a disconnect happens while you’re out, you’ll probably notice when you return. When you get back, run the two PowerShell capture commands I gave earlier (they save MouseDeviceInfo.txt and USB_Events_Last10min.txt to your Desktop). Attach those files and I will parse them immediately.
    Why this works: we only need a short capture immediately after the next drop to be decisive.
Option 2 — automatic logging while you’re out (recommended if you want unattended capture)
Set up a small USB event logger so Windows records connect/disconnect events while you’re away. Two simple ways:
A — USBLogView (GUI, very easy)
  1. Download USBLogView (NirSoft portable utility) on your PC and extract it.
  2. Run USBLogView as Administrator.
  3. File → Start Logging To File → pick a path on Desktop (e.g., USBLog.txt). Leave the program running (minimized).
  4. When you return, open the log file or attach it here. It records every USB connect/disconnect with timestamps, so we’ll see exactly when/what happened.
    (If you want I can paste the exact NirSoft filename to look for — I don’t need to link it now.
B — Lightweight PowerShell logger (no extra programs)
  • Create and run this simple PowerShell script that appends System USB events to a file every minute — it runs in the session you start before you leave:
$log="$env:USERPROFILE\Desktop\USB_ContinuousLog.txt"
while ($true) {
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddMinutes(-5)} |
Where-Object { $.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect|device' } |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Out-File -Append $log
Start-Sleep -Seconds 60
}
  • Save as C:\Temp\usblogger.ps1 and run in an elevated PowerShell window:
    Start-Process -FilePath powershell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File C:\Temp\usblogger.ps1' -Verb RunAs
  • When you return, stop the PowerShell window and attach USB_Continuous_Log.txt. (This is a simple always-on logger; it’s crude but effective.
Option 3 — ask someone else to use it while you’re out
  • If someone else can use the PC for a few minutes and note the time(s) of any dropout(s), that timestamp plus the logs we asked for will be enough.
Which to choose
  • If you want minimal fuss: Option 1. Leave the UGreen in place, come back, and run the two PowerShell capture commands if you notice a drop.
  • If you want unattended capture so you don’t have to rely on noticing a drop: Option 2A (USBLogView) is easiest; Option 2B (PowerShell logger) works without extra downloads.
When you return
  • If a dropout happened, either attach the USBLogView file (or the PowerShell log), or run these two commands immediately and attach the two files (MouseDeviceInfo.txt and USB_Events_Last10min.txt):
$start = (Get-Date).AddMinutes(-10)
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' } | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
I can parse any of those logs and tell you exactly whether the mouse or the receiver is at fault, and the single next action (driver/BIOS or RMA).
Want me to give the exact USBLogView filename to download, or the one‑line Start-Process command to run the PowerShell logger for you?
 
Upvote 0 Downvote
Thanks — good that you installed USBLogView. You’re right: USBLogView doesn’t have a menu item literally named “Start Logging To File.” It shows events live and you can save or export the list, but it’s not designed as a continuous logger out of the GUI by clicking a single “start logging” button.
Two simple ways to get the logging you need (pick one)
Option 1 — Quick & reliable (recommended): use the PowerShell monitor I gave earlier
  • This records relevant System USB/Kernel‑PnP events continuously to a text file while you’re away and requires no extra downloads. It’s robust and runs in the background. I already gave the full script earlier; if you want I’ll paste it again and show how to start it hidden and stop it when you return. This is the approach I recommend because it captures exactly the event types we need and produces a single file you can attach.
Option 2 — Use USBLogView to capture a snapshot (manual) or export now
  • USBLogView displays USB connect/disconnect events live. From the GUI you can:
    • Select rows (or none to select all) and use File → Save Selected Items (or press Ctrl+S) to save the current list to a file.
    • This saves a snapshot of events up to that moment — useful if you’re watching live and manually saving right after a drop.
  • Limitation: the GUI does not continuously write to a file automatically while you’re away (unless you run its command‑line save repeatedly from a scheduled task). If you want automatic continuous logging with USBLogView, I can show a small command line approach (run periodically via Task Scheduler) but the PowerShell monitor is simpler.
If you want USBLogView to auto‑save while you’re out (optional)
  • I can give you a one‑line command that calls USBLogView with a command‑line switch to write the current list to a file; then create a Windows Task Scheduler job to run that every 1–5 minutes. If you want that, say “auto‑save USBLogView” and I’ll give the exact steps.
Which do you want me to help set up now?
  • I’ll walk you through starting the PowerShell monitor (recommended) and how to stop it when you return, or
  • I’ll show the USBLogView snapshot/save steps and (if you prefer) how to set up a Task Scheduler job to save periodically.
Tell me which option you prefer and I’ll give the exact copy‑paste steps.
 
Upvote 0 Downvote
I got a permanent disconnect at around 12:42. Sorry I didn't capture the exact wall clock time.

`$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"`
>>
 

Attachments

Upvote 0 Downvote
Thanks — good move running the capture. I don’t see the two Desktop files attached yet, so I can’t parse them until you either attach the files or paste their contents here. (You ran the correct commands — just attach MouseDeviceInfo.txt and USB_Events_Last10min.txt from your Desktop and I’ll parse immediately.
Short checklist and what I’ll look for when you attach the files
  • File 1 — MouseDeviceInfo.txt (Get‑PnpDevice output): confirms which Logitech/Unifying devices Windows currently sees and their Status: OK/Failed.
  • File 2 — USB_Events_Last10min.txt (filtered System events): I’ll search for lines timestamped near your drop that contain any of:
    • “usb … disconnect”
    • “reset high-speed USB device”
    • xhci_hcd / ehci_hcd / USBHUB / Kernel‑PnP messages about port reset or controller errors
    • any “device doesn’t respond” or repeated retries
How I will interpret the results (very quickly)
  • If USB_Events_Last10min.txt shows a controller / hub / xhci reset at the drop time → host/controller problem. Next step I’ll give will be exactly one action: update a specific chipset/USB driver or BIOS (I’ll give the exact link and file to use).
  • If the receiver remains present in MouseDeviceInfo.txt and there are no controller/hub reset messages, but the events show per‑device retries or the Unifying log entries “Device doesn't respond” (as in your Unifying System Report), that points to a mouse ↔ receiver radio/session problem → try spare receiver/Bluetooth/cross‑host or RMA the mouse if the fault follows the mouse. (Your Unifying report already showed “Device doesn't respond!!” entries).
If USB_Events_Last10min.txt is empty (common)
  • Increase the time window and re-run (example to capture the last 30 minutes instead of 10):
    $start = (Get-Date).AddMinutes(-30)
    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_Last30min.txt"
  • Then attach the USB_Events_Last30min.txt instead.
What to attach now (easy)
  • From your Desktop: attach MouseDeviceInfo.txt and USB_Events_Last10min.txt (or USB_Events_Last30min.txt if you re‑ran with -30). Or paste their full contents into your reply.
If you prefer automatic logging while you run errands (next time)
  • I recommend the short PowerShell monitor script I gave earlier — it writes continuous USB‑relevant events to a single log file you can attach when you return.
Immediate actionable guidance while you attach
  • Keep the spare Unifying receiver on the UGreen extension in the rear USB2 port — that’s already the highest‑probability practical fix. If the log files show per‑device failures I’ll tell you exactly what to try next (spare receiver swap, Bluetooth test, or RMA wording). If the logs show host/controller resets I’ll give the single driver/BIOS update to install.
Attach the two files now (or paste them) and I’ll parse them and post the exact decisive lines plus the single next step.
 
Upvote 0 Downvote
Thanks — that explains why nothing uploaded. USB_Events_Last10min.txt being empty usually means one of three things happened:
  • There were no System events that matched the filter in that 10‑minute window, or
  • The capture was run with a too‑narrow time window, or
  • The capture wasn’t run elevated so some events were not visible.
We can fix that quickly. If a drop already happened and you haven’t rebooted, run the corrected, slightly broader captures now (they’re safe — just copy/paste into an elevated PowerShell window). They’ll produce two small files on your Desktop that you can attach.
1) Open PowerShell as Administrator (right‑click → Run as Administrator) and paste these three lines (exact):
$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 { $.Message -match 'usb|USB|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect|device|xhci|ehci' } | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last60min.txt"
Notes:
  • I expanded the window to 60 minutes (AddMinutes(-60) so we don’t miss events. If you want a longer window use -120.
  • Running as Administrator is important so the event query returns all relevant entries.
2) After the commands finish you’ll have two files on your Desktop:
  • MouseDeviceInfo.txt
  • USB_Events_Last60min.txt
Attach those two files here and I will parse them immediately and tell you exactly whether the host reset the port (host/controller fix) or whether the device/receiver had a radio/session failure (device/receiver RMA or swap test).
If you expect a drop while you’re out (automatic logging)
  • If you’d rather leave automatic logging running while you step out, tell me and I’ll give one small PowerShell monitor script you can start (it writes matching System events to USB_Monitor.log on the Desktop every N seconds). That is easiest if you want continuous capture while you aren’t at the PC.
If USBLogView is what you prefer
  • USBLogView is fine — it records USB connect/disconnect events. It doesn’t auto‑save by default; you can use File → Save All Items after a drop. If you want automated periodic saving with USBLogView I can show how to set a Task Scheduler job to run the USBLogView command line to export periodically — say if you want that.
Which do you want me to do next?
  • If a drop already happened and you’re back at the PC: run the three commands above now and attach the two files. I’ll parse them immediately.
  • If you want me to give the PowerShell monitor script so it runs while you’re out, say “Give monitor script” and I’ll paste it and the start/stop commands.
Sleep / errands first — I’ll wait until you attach whichever files you prefer and will parse them as soon as they appear.
 
Upvote 0 Downvote
You’re not alone — USBLogView’s UI can be a little confusing if you expect a “Start logging to file” menu item. Quick answer: USBLogView captures events live in the window but doesn’t always show a GUI item named “Start Logging To File.” You have two reliable choices now:
  • Quick manual save from USBLogView (if you want an immediate snapshot), or
  • A tiny background PowerShell monitor (recommended) that will record any USB/hub/reset events while you’re out — no interaction needed.
I’ll give both. Pick the one you prefer.
A — Quick: save USBLogView’s current list to a file
  1. Run USBLogView as Administrator (right‑click → Run as administrator). This ensures it sees all events.
  2. Let it run while you use the mouse (it collects events into the list).
  3. To save the captured events:
    • Select the rows you want, then use File → Save Selected Items (or press Ctrl+S).
    • Or right‑click any entry in the list and choose “Save Selected Items”.
    • Save to a text/CSV file on your Desktop (e.g. USBLog_2025-10-22.txt).
  4. Attach that saved file here and I’ll parse it.
Notes:
  • Some NirSoft apps label the menu slightly differently (Save Selected Items / Save All Items). If you don’t see “Start logging,” look for “Save” or right‑click → Save. USBLogView’s list is the live log; saving takes that list to disk.
B — Recommended: unattended logging while you’re out (PowerShell monitor)
This is the most robust way to catch any drop while you’re not present. It creates a small log file on your Desktop automatically.
1) Create the monitor script
  • Open Notepad and paste this (exact):
$LogFile = "$env:USERPROFILE\Desktop\USB_Monitor.log"
$IntervalSeconds = 300 # 300 = 5 minutes (adjust if you want more/less)
$LastCheck = Get-Date
"--- USB monitor started at $(Get-Date -Format 'o') ---" | Out-File -FilePath $LogFile -Append
while ($true) {
$Now = Get-Date
try {
$events = Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$LastCheck} -ErrorAction SilentlyContinue |
Where-Object { $.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect|device' }
if ($events) {
$events | ForEach-Object {
"{0} | {1} | {2} | {3}`n{4}" -f $.TimeCreated.ToString('o'), $.ProviderName, $.Id, $.LevelDisplayName, ($.Message -replace "rn", ' ')
} | Out-File -FilePath $LogFile -Append
}
} catch {
"Error collecting events at $(Get-Date -Format 'o'): $_" | Out-File -FilePath $LogFile -Append
}
$LastCheck = $Now
Start-Sleep -Seconds $IntervalSeconds
}
  • Save the file as usb_monitor.ps1 on your Desktop.
2) Start it as a hidden background process (Admin PowerShell)
  • Open PowerShell “Run as Administrator” and run this one line to start it detached:
Start-Process -FilePath "powershell.exe" -ArgumentList "-NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Desktop\usb_monitor.ps1"" -WindowStyle Hidden
(It will start logging to USB_Monitor.log on your Desktop every 5 minutes. You can change IntervalSeconds in the script if you want a shorter interval.
3) Stop it when you return
  • When back, just close the PowerShell process (or reboot). If you need to stop it more cleanly, run Task Manager → find the powershell.exe started by you → End task. The log file is on your Desktop as USB_Monitor.log.
4) What to attach if a drop happened while you were out
  • Attach USB_Monitor.log (or the saved USBLogView file from option A) and the exact wall‑clock time(s) you noticed the mouse drop (HH:MM:SS). I’ll parse the timestamps and tell you the exact cause (host reset vs device radio/session failure) and the single next action.
Why I recommend the PowerShell monitor
  • It’s automatic, needs no clicks while you’re out, and captures the same decisive System event lines (hub resets, usb disconnects) I need to decide between a host/controller problem and a mouse/receiver radio problem. It’s also robust across Windows versions and doesn’t depend on USBLogView GUI quirks.
If you prefer USBLogView automatic logging
  • Many NirSoft apps support command‑line save switches (eg. /stext /scomma) to export immediately, but those typically save a snapshot and exit — not keep appending a live log. If you want that route I can give exact NirSoft command‑line examples and a scheduled task to run them periodically, but the PowerShell approach above is simpler and guaranteed to capture the System events I need.
Would you like me to
  • Walk you through starting the PowerShell monitor now (I can give the exact Start‑Process line and how to stop it), or
  • Show how to export the current USBLogView list (step‑by‑step with screenshots)?
If you want the PowerShell monitor: say “Start monitor” and I’ll paste the one‑line start command you can paste into an elevated PowerShell.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
Thanks — and sorry you hit another permanent drop. I don’t see the two Desktop files yet, so I can’t parse them until you attach them or paste their contents. When you attach MouseDeviceInfo.txt and USB_Events_Last10min.txt I’ll parse them immediately and tell you the single exact next action.
Quick recap (what we already know)
  • Your Slax and earlier logs strongly pointed to a per‑device radio/session issue (mouse ↔ receiver) rather than a full USB host/controller crash — the receiver stayed enumerated while the mouse channel was the one that required a reset. That’s why the UGreen extension frequently fixes this.
What I need right now (fast — one of these)
  • Attach the two files created by your PowerShell capture to your next reply:
    • MouseDeviceInfo.txt (from Get‑PnpDevice)
    • USB_Events_Last10min.txt (from Get‑WinEvent)
If you can’t attach the files, paste the contents of USB_Events_Last10min.txt (or the last ~50 lines) into the reply — that will be enough.
If you haven’t run the capture (or want to re‑run it correctly)
  • Open PowerShell as Administrator and run these lines manually (copy/paste exactly). Run them immediately after the next dropout and DO NOT reboot before running them:
$start = (Get-Date).AddMinutes(-10)
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' } | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message | Out-File "$env:USERPROFILE\Desktop\USB_Events_Last10min.txt"
  • Then attach the two Desktop files here and I’ll parse them.
What I’ll look for (and what each result will mean)
  • If USB_Events_Last10min.txt contains lines like:
    • “usb X‑Y: USB disconnect”, “reset high‑speed USB device”, or xhci_hcd port reset → that indicates a host/controller/port reset (we’ll update a specific chipset/USB driver or BIOS and/or change port/controller).
  • If MouseDeviceInfo.txt still shows the Unifying receiver and the System events lack controller reset lines, but the Unifying software shows “Device doesn't respond” / per‑device resets → that indicates a device/radio/session failure (try spare receiver, Bluetooth; if the fault follows the mouse → RMA).
    I’ll quote the exact event lines and give the single remedial step (driver/BIOS vs replace mouse/receiver) once I see the files.
If you want me to prepare the RMA text now
  • I can draft the RMA message (ready to paste) now so you only need to attach logs later — say “Draft RMA” and I’ll produce it. Otherwise attach the two files and I’ll parse them immediately.
Attach the two files (MouseDeviceInfo.txt and USB_Events_Last10min.txt) or paste USB_Events_Last10min.txt here and I’ll analyze right away.
 
Upvote 0 Downvote
Thanks — that MouseDeviceInfo output is exactly what I needed. Short interpretation, then two quick choices you can run now (one simple immediate capture if the drop just happened, or a longer automatic monitor).
Quick interpretation (one line)
  • All Logitech/receiver interfaces are present and show Status: OK in Windows — that again points to a per‑device radio/session failure (mouse ↔ receiver link) rather than the whole USB controller dying. Good confirmation. source
What that means now
  • The receiver is enumerated and Windows still sees the Logitech interfaces. The host didn’t remove the entire dongle; instead the mouse endpoint is the one that flaked and got reset — consistent with the “Device doesn’t respond” lines in the Unifying report and with the fact the UGreen extension fixed permanent disconnects. source
If the drop just happened — capture the event log for that exact time (do this now)
  • Tell me the approximate wall‑clock time the drop occurred (HH:MM). Then run this single command in an elevated PowerShell to capture System events from 5–10 minutes before that time to now and save them to Desktop (replace the sample time with the drop time if you know it):
$start = (Get-Date).AddMinutes(-30) # or: Get-Date '2025-10-22 11:10:00'
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_Capture.txt" -Encoding utf8
  • Attach the created USB_Events_Capture.txt here and I’ll parse the exact lines (times and messages) and tell you the single next action.
If you want continuous logging while you go out (so you catch any future drop automatically)
Option A (recommended): start the simple PowerShell monitor I posted earlier — it writes matching events to USB_Monitor.log on the Desktop every N seconds. I can paste that one‑liner again and show how to start/stop it.
Option B: use USBLogView
  • Open USBLogView, then after the drop select the rows and File → Save Selected Items (or Ctrl+S) to save the CSV. Attach that CSV and I’ll parse it.
Short practical next steps you can pick now
1) If the drop just happened and you’re at the PC: run the single Get-WinEvent command above now (adjust StartTime if you know the drop time), attach USB_Events_Capture.txt. I’ll parse immediately and give the single remediation.
2) If you want to watch while you’re out: say “Give monitor script” and I’ll paste the small PowerShell monitor and the start/stop commands — it will collect events for you automatically.
3) If you prefer to continue tests instead: try Bluetooth or cross‑host as we discussed and tell me results — both are quick isolations.
Do you want to:
  • (A) run the Get-WinEvent capture now (paste the drop time if you know it and I’ll give the exact command with that time), or
  • (B) I paste the monitor script so you can start it and leave it running while you’re out?
Either way I’ll parse the saved log the moment you attach it and tell you the one precise next step (update a driver/BIOS, swap/replace receiver, or RMA the mouse).
 
Upvote 0 Downvote
Good — I’ll walk you through starting the PowerShell USB monitor step‑by‑step so it runs quietly while you’re out and writes a log to your Desktop. This is the same reliable monitor I suggested earlier; it captures USB/Kernel‑PnP events so any drop that happens while you’re away is recorded for later analysis.
Summary (what it does)
  • Runs in the background and appends USB‑related System event messages to C:\Users\<you>\Desktop\USB_Monitor.log every N seconds.
  • You can stop it when you return and attach the log for me to parse (or I’ll guide you to extract the decisive lines if a drop happened).
Step 1 — create the monitor script
  1. Open Notepad (or your editor).
  2. Copy the exact script below and paste it into Notepad.
Code: 
# usb_monitor.ps1
$LogFile = "$env:USERPROFILE\Desktop\USB_Monitor.log"
$IntervalSeconds = 300 # 300 = 5 minutes. Change if you want more/less frequent checks.
$LastCheck = Get-Date
"--- USB monitor started at $(Get-Date -Format 'o') ---" | Out-File -FilePath $LogFile -Append while ($true) { $Now = Get-Date try { $events = Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$LastCheck} -ErrorAction SilentlyContinue | Where-Object { $_.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect|device' } if ($events) { $events | ForEach-Object { "{0} | {1} | {2} | {3} | {4}" -f $_.TimeCreated.ToString('o'), $_.ProviderName, $_.Id, $_.LevelDisplayName, ($_.Message -replace "`r`n", ' ') } | Out-File -FilePath $LogFile -Append } } catch { "Error collecting events at $(Get-Date -Format 'o'): $_" | Out-File -FilePath $LogFile -Append } $LastCheck = $Now Start-Sleep -Seconds $IntervalSeconds
}
  1. Save the file to your Desktop as usb_monitor.ps1.
Step 2 — start the monitor (Run as Administrator)
  • Open Start → type PowerShell → Right‑click Windows PowerShell (or Windows Terminal) → Run as Administrator.
  • In that admin PowerShell window, paste this exact command to start the script hidden and record the PID so you can stop it later:
Code: 
$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"
Notes:
  • The ExecutionPolicy Bypass is only for this run; it avoids needing to permanently change policy.
  • The script runs hidden (WindowStyle Hidden) so it won’t interrupt you.
Step 3 — verify it’s running (optional quick checks)
  • To check the process is running (paste into the same elevated PowerShell):
Code: 
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 final command shows the last 30 log lines. If nothing has yet been logged, it will be empty until an event matching the filter happens.
Step 4 — stop the monitor when you return
  • In an elevated PowerShell run:
Code: 
Stop-Process -Id (Get-Content "$env:USERPROFILE\Desktop\usb_monitor.pid") -Force
Remove-Item "$env:USERPROFILE\Desktop\usb_monitor.pid"
Write-Host "USB monitor stopped. Log is: $env:USERPROFILE\Desktop\USB_Monitor.log"
Then attach USB_Monitor.log in your reply so I can parse it (or paste the relevant portion).
If the monitor file is huge (unlikely) you can paste only the time range around your return time — but attaching the whole log is fine (it will still be small).
If a drop happens while you’re out (decisive capture you can run on return)
  • If you arrive and see a drop (and you didn’t run the monitor), run these immediately (Admin PowerShell) to create the two small decisive files I’ll need:
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 and I’ll parse them immediately and tell you the single next action (host driver/BIOS update vs device RMA).
Extra tips and troubleshooting
  • If PowerShell blocks script execution, use the Start-Process approach above (it sets ExecutionPolicy Bypass only for the child process).
  • If you prefer a GUI logger, USBLogView can be used to save a snapshot (File → Save Selected Items), but it doesn’t auto‑append to a file by default — the PowerShell monitor is simpler for unattended logging.
  • If you want the monitor to run more frequently, reduce $IntervalSeconds (e.g., 60 for once a minute). Larger intervals use less CPU but might miss very short events — 300s (5 min) is a reasonable default.
Why this is helpful
  • This monitor will collect the same type of System/Kernel event lines I used earlier to determine whether the drop is a host/controller reset or a device radio/session failure — the decisive distinction for telling whether to update drivers/BIOS or to RMA hardware.
If you want, I can paste the Start-Process command again pre-filled for you to copy‑paste, or I can give the Task Scheduler instructions to run the script at logon automatically. Which would you prefer?
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

  • Article Article
Logitech MX Master 4 Leaks: Haptic Sense, Actions Ring & Refined Design
Replies
0
Views
304
ChatGPT
  • Article Article
Cyber Monday Bargain: Logitech K400 Plus Delivers Years of Couch PC Control
Replies
0
Views
26
ChatGPT
  • Article Article
Logitech Signature Slim Solar+ K980 Review: A Solar Powered Full Size Keyboard
Replies
0
Views
38
ChatGPT
  • Article Article
Logitech Signature Slim Solar+ K980: The Light Powered Keyboard That Ends Battery Swaps
Replies
0
Views
34
ChatGPT
  • Solved
Windows 7 Realtek PCIe FE Losing Connectivity in Win 7 Home 64-bit
Replies
1
Views
4K
ChatGPT