AutoHotkey Community

There are many threads in this and earlier iterations of this forum reporting variations on a "modifiers stuck" problem--i.e. LWIN, ALT, CTRL, etc, appear to be stuck down after an AHK macro is run when they are not. There are various posted solutions/workarounds, but none of them work for me, nor, apparently, do they for many other people because they keep reporting these problems. It is a continuous and apparently ubiquitous enough annoyance with using AHK that I'm hoping the developers or community can come up with a real universal fix.

My specific setup is a last generation, top of the line X1 Carbon running fully patched Windows 10. (While I doubt hardware or OS matters here, I'm including just in case.) The problem has been with me for years and still appears in the latest AHK release which at this time is 1.1.25.01, 64-bit.

Some things I've tried without success:

(1) KeyWait at the beginning of the macro, e.g. Even with this sort of code, I still find, e.g., LWIN often stuck down.

(2) "ReleaseModifiers" script, e.g. And then calling the script as ReleaseModifiers(500) at the end of every macro.

Also tried solutions posted elsewhere, e.g. https://autohotkey.com/boards/viewtopic.php?f=5&t=26760 and https://autohotkey.com/board/topic/9409 ... ways-down/

The only thing I've found that consistently gets me out of the stuck key situation is to kill and relaunch AHK, which is not a terribly convenient workaround.

Hoping someone can help end this long national nightmare!

https://autohotkey.com/docs/commands/_MenuMaskKey.htm

HTH

I still have this problem on a daily basis. I've tried the solutions above -- having a KeyWait for each macro; a ReleaseModifiers() script for each macro; and different #MenuMaskKey settings including vk07; and none of them fully solve the problem of a modifier getting stuck down. It seems to be most frequently (maybe always?) LWIN. It is particularly acute when there is high CPU usage and thus the system is running a little slower. Any other ideas for how to track down the root cause?

With a top of the line x1 carbon you shouldnt be having high cpu usage. I would look into what is causing that first.

Quicken is the most common culprit when updating accounts. It's terribly written software. Other common scenarios are virus signature updates/scans. The stuck key phenomenon is most reproducible in those situations but it also occurs occasionally under more normal use conditions when CPU usage is not high--just harder to replicate reliably.

Hi ajkessel, just looking at your release modifiers code, it appears to me the logic of that function couldn't work.

Assuming, the physical key itself isn't faulty, which can also cause stuck keys, the issue is usually that a physical key is NOT down, yet the OS thinks it is. To rectify (theoretically, as In practice it doesn't always work) you need to send the offending key up, which is never attempted in your posted code. You also never check for a logically down key only a physically down key. i.e. GetKeyState(key) vs GetKeyState(key,"P"), former is logical (according to OS) key state, later is physical key state.

With the first example, which should work, you could alter the hotkey, to be "#0 Up::" and leave out the keywait for 0 as it won't be needed. You could even add "<" before # forcing the hotkey to only work with LWin, and not with RWin, as using RWin will kind of stuff up the hotkey. Also try forcing the keyboard hook if you haven't already (i.e. #UseHook near the top of the script).

Aside from that the issue sounds more like the keyboard messages are being dropped/missed from the message queue, due to the nature of it mainly occurring during periods of high system load. You could also try checking your keyboard buffer size in the registry, perhaps it's been changed by something ? It's in the "HKLM\SYSTEM\CurrentControlSet\Services\kbdclass\Parameters" registry key, as "KeyboardDataQueueSize", by default the value should be 0x64, if it is less than this, set it back to default, if not, you could try increasing it, (but don't make it too large, double it, see if it makes an improvement, if not set it back to default).

Thanks for the suggestions.

This occurs on several different keyboards and even across multiple laptops/new installs of Windows, so it can't be a hardware issue.

KeyboardDataQueueSize was set to 0x64 but I've now doubled it to 0xc8 to see if that changes anything.

I've been using #UseHook for a long time so it didn't seem to impact the issue.

I'll modify the # bindings to <# since I only use LWin anyway. But to make sure I understand--assuming I never touch the physical RWin button, this probably isn't related to my problem, right?

Yeah < or > before a modifier simply restricts the hotkey to only fire on the left or right (respectively) modifier key, instead of firing on both of them. It would only cause an issue here when RWin was used to fire the hotkey as the keywait LWin would do nothing. Not really a solution to the issue at hand more a possible issue you may have stumbled onto another time.

I'm not sure what else to suggest, I rarely have stuck key issues, so I'm a bit stumped. I can only make guesses like perhaps other code is interfering, since I assume you have more than just this one hotkey active.

Incidentally another consideration is the hotkey itself, #0 is, from memory, natively a windows hotkey, and while sometimes it doesn't matter other times it does (In other words, ahk can overwrite some of the native windows win hotkeys, but there are others it just can't. Perhaps this is one of them where it fails, or it's only being partially successful, i.e. side effects). Perhaps test with a different win combo than win+zero. However I suspect you've already got other win key combos it's doing this with.

Something else you could try is increasing the priority of your script to above normal (see "Process, Priority" in docs for details). But otherwise I'm out of ideas.

I have a suspicion that this might be causing problems: I've switched LWin to RCtrl and haven't seen my stuck key problem since then. Any reason to think this would be particularly problematic?

Yes, that code would be problematic. The issue is a LWin & LButton:: combo key is handled differently to using a modifier hotkey such as #LButton (which you could also presumably change it to). Have a look at the docs regarding combination hotkeys, to see details, but in short it changes the nature of the first key (LWin), which normally isn't an issue in itself, assuming you're aware of the details, but when that key is a modifier and you also use it as one, then things get messy. Best bet is only use modifiers as modifiers (not combo hotkeys) or if you have to use one as a combo hotkey, don't use it as a modifier, but instead keep it as a combo hotkey throughout, i.e. keep it consistent.

OK, I'll make sure there are no other uses like this and see if that fixes it (that "LWin & LButton" code originally came from some forum post or example posted somewhere).