This is an odd one.
If I lock my Windows 11 workstation with the Win-L keyboard combination, SignalRGB stops processing keystroke-based macros until the macro feature is toggled off and on again (or the program itself is restarted).
This only happens with the keyboard shortcut. If I lock the workstation through the power menu, or use an on-screen keyboard, or issue rundll32.exe user32.dll,LockWorkStation at a command line, SignalRGB macros continue to work after logging back in.
The behaviour is the same with two different physical USB keyboards, and it doesn’t matter whether Require users to press Ctrl-Alt-Delete is enabled or not.
It is possible to “trick” the system into misbehaving by holding down the Win key while, for instance, running a batch file containing the rundll32.exe user32.dll,LockWorkStation command. It’s as though it’s triggered by the Win key being pressed as the system locks regardless of the actual source of the lock command. This suggests it’s more of an underlying Windows issue, but perhaps one that SignalRGB could be made to mitigate?
I’ve managed to find a sort of workaround by using SignalRGB itself to look for a particular keyboard combination (I’m using Alt-NumpadMinus for now) and to issue rundll32.exe user32.dll,LockWorkStation via a batch file. It works, but it’s difficult to deprogram decades of muscle memory from fingers that go automatically to Win-L whenever I leave the workstation. And I can’t use another Win- combination for the reason outlined in the previous paragraph.
Does anyone know why SignalRGB might be particularly susceptible to whatever Windows-based shenanigans are going on here? I’ve tried a couple of other macro tools, AutoHotKey and VoiceMacro, and neither of those seems to be affected by the Win-L thing.
Windows 11 24H2 (26100.3037), SignalRGB 2.4.44-beta+cdb75d6f