Years ago I wrote about the Logitech’s LVUSBSta.sys driver that corrupted the USB and audio stack when installed. For a long time, I no longer bought Logitech because even if the hardware is mostly good, software was not. For a while I bought Microsoft devices, which usually worked without issues. Now Microsoft got out from that business, so I returned to Logitech, especially because the new MX Creative Console looked interesting. Wrong move, it looks.
When I connected an MX keyboard, it installed its Logi Options+ software as well (version 1.84.641293). Now, that “utility” consumers 12-15% of CPU continuously, and makes some application less responsive.
On my eight core machine it means more or less something keeping a single core 100% busy. And look at the call stack of the thread:
ntdll.dll!memset+0x2f4e
ntdll.dll!RtlFreeHeap+0x51
ucrtbase.dll!free_base+0x1b
logioptionsplus_agent.exe!logi::LoupedeckConnector::isGetUserInfoDelegateRegistered+0x725dc5
logioptionsplus_agent.exe!logi::LoupedeckConnector::isGetUserInfoDelegateRegistered+0x725b09
logioptionsplus_agent.exe!logi::LoupedeckConnector::isGetUserInfoDelegateRegistered+0x72530e
ucrtbase.dll!configthreadlocale+0x92
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21It looks the acquisition of Loupedeck by Logitech brought some merging issues. And what “GetUserInfo” call it is attempting and why? And why it doesn’t accept a “no” answer and stops there? Probably, if software tried less to track users, it would work better and use less resources.
Moreover, there is no way to file a bug report to Logitech easily. Are they worried to be submerged by tons of them? It looks this one is not the first version with such issues, there are several reports in the past years too. Someone has to remember Logitech that “errare humanum est, perserverare autem diabolicum”. Especially when your software works at the system level, and is always running, you can’t rely on developers without the proper skills, and testers as well.
Update 2024-11-22: suspending the thread looks to have no bad side effects. I tried it using Process Explorer, and devices works as expected. It could be a viable workaround, until the bug is fixed, even if has to be repeated at each start of the process.
Update 2024-11-23: logioptionsplus_agent.exe process is spawned only when you launch the Logi Options+ app. It doesn’t look to run just after boot. When the application is closed, the child process is not terminated, and keeps running. Unluckily, killing the whole process makes the configuration auto-switching inoperative.
Meanwhile, probably unrelated, I found the “Options Rings” are not working, at least on my system. Press the assigned button (on the dialpad or keypad, it doesn’t matter), the cursor shows the wait icon briefly, then nothing happens. Process Explorer again shows something is not working, “C:\Windows\System32\WerFault.exe” is run, which is the Windows Problem Reporting application. Yet no error is displayed to the user.