Serious show stopping bug with 2.20

So this version seems to have the worst bug yet. Under some circumstances, not quite sure what, maybe pressing two G-keys at the same time or very close, CUE seems to kinda bugout sending one of the G-keys repeatedly. The key continues to be sent even on the Win10 login and even if you switch user account, so it's clearly something serious as normally the profile changes when you switch user resetting any keys.

On my system it has repeatedly bugged out sending the left mouse button continuously. You can imagine this makes it quite dangerous and hard to do anything much to recover the situation. In the end I had to put the PC to sleep with the power button, wake it up and then float the mouse over the power button in the bottom left of the Win10 login screen, move it swiftly up to restart and restart the PC. I could find no other way. It was impossible to kill CUE due to the continuous left mouse presses the system was receiving!

I've reverted to 2.19. Hopefully this can be fixed quickly along with the very annoying need to restart CUE everytime the switch user screen engages, as discussed at length in other threads.

I had a similar issue yesterday with Tab being sent repeatedly. I didn't directly associate that with CUE but it might be related to this issue since it occurred after working with the G-keys.

Exactly like described above I needed to restart the PC to stop it.

For me this is not something new. This has happened with pretty much every version I have used. Not sure what causes it however does seem to not happen if I restart after installing a update.(however not knowing what triggers it I cant confirm) I have seen two things work (if I remember correctly) if you can get to device manager and remove all the items listed in mouse then let it re-detect that works or closing out CUE completely then restarting it.(not 100% sure about this last one working) Given the above driver loading unload solving it seems like during driver update it doesn't fully unload the current when then installing the new.

Edit: Again if I remember correctly its the "HID-compliant mouse" entrys you want to disable. I beleieve one or two of the entrys that have the "Location" "on Corsair composite virtual input device" is the glitched/bugged one at least it is for me when using a mouse no keyboard(corsair).

For me this is not something new. This has happened with pretty much every version I have used. Not sure what causes it however

I also have had this happen in every version. The only way I can consistently reproduce it is when I have an autohotkey script running that polls for a hotkey from the Scimitar or M65 mouse that via CUE sends F24 (i suspect that is incidental and an irrelevant specific anecdote).

I have the AHK script open magifier in windows and invert colors when that CUE remap is pressed. For me, if I happen to open cue at the same time, I can always, 100% of the time get Cue to go into a loop where it jams the same remap all the time, like it is stuck in an infinite loop like the driver is not satisfied that its effect has fired for some reason. It does not always help if I kill my AHK script and it always helps if I kill Cue which leads me to believe it is something with the Cue Driver. I also have it happen randomly even without scripts running in Photoshop where it will start jamming a tool key like l or e or something and I cannot get it to stop without killing the process. For me it is no big deal but you do need to have a stopgap...for me it is generally the same ahk script that has the following code:

Volume_Mute::

Runwait, taskkill /im CUE.exe /f

ExitApp

Return

then having a global hotkey ink on the desktop i can re run cue...not a fix, but a bandaid.