Stop modifier keys from getting stuck down

[mikeyww]

There are lots of issues with modifier keys getting stuck down. A variety of posts report it. Would be great to eliminate that problem.

[lexikos]

Well, what's the cause of the problems?

There is a great deal of complexity involved in keyboard input processing, most of it existing outside of AutoHotkey. AutoHotkey provides multiple send modes, key delay settings, and other options because there is no single perfect tool for every job.

[mikeyww]

That's my question, too: what is the cause of the problems? I don't point any fingers, just seek better performance from AHK. It should find a way to avoid or at least detect the problem. I don't think that an answer to any problem is, "Well, we're trying, we did some things to try to prevent this problem, and we have other good features". I love AHK and use it every day. I'm being tough on it because it has a recurrent problem that should be addressed somehow, regardless of the cause or source. That's what debugging means, in my own view. I know that you are an expert, @lexikos! I'm just providing my perspective as an end user.

[lexikos]

It is my opinion that the majority of the remaining reliability problems with hotkeys or Send are inherent to the underlying systems/processes, or have causes that cannot be fixed by changes to AutoHotkey (but can generally be worked around by utilizing methods appropriate to the situation, from what AutoHotkey already provides).

For instance, modifiers may stick down as a result of Send "restoring" a modifier after temporarily releasing it. Without the keyboard hook, it is impossible for Send to know whether the key is physically still being pressed, so there are workarounds like #HotkeyModifierTimeout. If the user releases the modifier within the timeout period, Send might press it back down, causing it to stick. If the user is still holding it after the timeout, Send won't have pressed it back down, so the script and active window will act as though the user isn't holding it. The program is operating on incomplete information, so limitations can be expected.

With the keyboard hook, the program should (in theory) always know whether the user is physically holding a modifier (but there are exceptions). SendEvent can therefore avoid pressing the modifier back down if the user has already released it during the send. In theory, the system buffers keystrokes during SendInput, so if the modifier is physically released, the corresponding event will come after SendInput presses it, and it won't get stuck. However, if a keyboard hook is installed, the stream of events can be interrupted. The script uninstalls its own keyboard hook (or falls back to SendEvent) to avoid the associated issues, but there are possible drawbacks to uninstalling the hook temporarily; and if there's a third-party keyboard hook, maybe the system won't buffer keystrokes during SendInput, so it might "restore" modifiers to the wrong state.

No one combination of techniques is ideal; there are always drawbacks, so it is up to the user to find an approach that works.

What I'm saying is that making such a vague wish is futile. I think it goes without saying that anyone using AutoHotkey wants it to be reliable.

When a specific problem is reported along with code to reproduce it, the possibility of a fix is much more reasonable, if only for that specific situation. Vague reports of problems will get vague answers.

[mikeyww]

OK. I do thank you very much for the details and reply, and also for your work on AutoHotkey. I know that I did not provide any supporting details, so there is no way to address my specific problem further, until details are available. I was simply reflecting on the various reports of this issue, and the magnitude of how it disrupts the user. "Fixing" this, if there is such a thing, is not only my greatest wish for AHK; it is my only wish.

In my own case, I have been taking steps to see whether I can resolve the issue, or at least narrow the possible causes. I had a few different scripts running, so I have consolidated them. I am checking to see if I have other AHK scripts also running (on demand) with the keyboard hook, and I have been eliminating the keyboard hook when I can, except in my main script that always runs. I also use the #HotkeyModifierTimeout-- seemed to help but not in all situations (though my script uses the KB hook, so perhaps it was just my imagination)-- and I have been trying different Send modes when I can (generally using Input by default in most situations).

Some tools might help. For example, is there any way that AHK or some other program can show a list of programs that are running with keyboard hooks? I actually have no idea which of my other programs might have hooks. I was running XMouseButtonControl and have decided to discontinue that one for a while, to see what happens. Perhaps I should do some more investigation myself, too, to look into the AHK key history when the problem recurs, to try to catch any offending code.

From your message, my conclusion is that I have a vague and futile wish. I will see if I can work on improvements at my end.

[lexikos]

For example, is there any way that AHK or some other program can show a list of programs that are running with keyboard hooks?

Not as far as I know.

However, some antivirus software can detect and block the use of keyboard hooks, somehow.

SetWindowsHookEx with WH_DEBUG might detect when a hook is called, but the hook procedure must reside in a DLL, which would be loaded into every process.

Some searching indicates how one might detect hooks, but further research indicates some of the necessary structures are in kernel memory, which would not be accessible to a user-mode program such as AutoHotkey. That aside, it would heavily depend on the use of undocumented structures.

[mikeyww]

OK. Thanks for the details and the research. I was using Keypirinha as a launcher, so I've written a separate AHK launcher instead. I was also using a KB shortcut for Everything, and I moved that shortcut into AHK as well. I'll see whether that helps. I have seen some AV software that blocks certain KB activity-- I believe that it was Webroot-- so I moved away from that a while back for other reasons. Perhaps it is fair to say that any software that maintains global keyboard shortcuts would use a keyboard hook (I am guessing)? That information would actually help users, because that is something that they can easily understand and identify.

[mikeyww]

This might help other users.

https://www.donationcoder.com/forum/?topic=18189.msg162881

Interesting program, 11 years old, found a ton of shortcuts on my computer. See the Zip download on the page.

It undoubtedly does not find everything, but at least it could help in some situations. I think one would want to subtract Windows' own shortcuts to find the rest. It does not show which programs own the shortcuts, so sorting through all of the listings could take a while.

[lexikos]

It appears that "ActiveHotkeys" only tells you which hotkeys are 'active', not which program registered them. It most likely works by attempting to register every possible combination with RegisterHotkey. If a combination succeeds, that hotkey wasn't already registered by some other program. This is actually completely useless for detecting keyboard hooks, because registered hotkeys do not use a keyboard hook. Also, the system itself registers a bunch of hotkeys.

Hotkeys implemented by a keyboard hook cannot be discovered in such a way, because they are not "registered" in any standard way; a program just responds to a specific event or combination of events which pass through the hook, when the keys are actually pressed. One can only watch for side-effects, such as events being suppressed (if they are).

Programs with global hotkeys which use (and suppress) a combination of Ctrl, Alt, Shift, Win and one other key are most likely using RegisterHotkey, and not a keyboard hook. Registered hotkeys always suppress the key-down event and not the key-up event. They cannot differentiate between keys that have the same virtual keycode (VK). Anything which does not fit that pattern is probably implemented with a keyboard hook.

[mikeyww]

Thanks for explaining that. I appreciate the details. I don't know how the hook actually works, so your message taught me something. Others may also benefit!

[DavidP]

Hello all,

While the discussion is a bit over my head, I can confirm that I too am seeing stuck modifier keys on an irregular basis, maybe two to three times a day. I usually have two lengthy scripts running in parallel, both of which are probably trying to create keyboard hooks.

Currently, it is mostly the ALT key that is getting stuck.

I don't know if this is related, but what also happens for me is that my hotkey for inserting unformatted clipboard text occasionally inserts only a v instead, so apparently the CTRL key isn't being sent properly:

Code: Select all

^v Up::  ; Ctrl+V = pure text conversion ; $ Prefix removed in order not to conflict with the Mikrofonbars script which has a keyboard hook
Clip0 = %ClipBoardAll%          ; Save current clipboard
  ClipBoard = %ClipBoard%       ; Convert to text
  ;SendInput %ClipBoard%        ; For best compatibility: SendPlay
  Send,^v
  Sleep 111                     ; Don't change clipboard while it is being pasted 
  ClipBoard = %Clip0%           ; Restore original clipboard
  VarSetCapacity(Clip0, 0)      ; Free memory
Return
#IfWinActive

[mikeyww]

I can't be of much help except to say that examining your KeyHistory might pinpoint a source of trouble for you.

[DavidP]

Thank you -- for the moment I use your proposed fix SendEvent {Shift Up}{Ctrl Up}{Alt Up} by having this called regularly by a timer, in case there has been no physical input by the user for a while, like so:

Code: Select all

SetTimer KeyStuckFix, 2222

KeyStuckFix: 
if (A_TimeIdlePhysical > 777)
SendEvent {Shift Up}{Ctrl Up}{Alt Up}
Return

I hope that this does not have unexpected side effects.

[pervect66]

It does, it keeps Windows from going to standby or even putting your display to sleep....

I made it a label, and gosub to it before ending the routines that are most likely to cause this.

[DavidP]

Thanks for the info.

Just for the record, I still get the ALT key stuck by AutoHotkey frequently. I have not been able to identify the reason yet. The current status is documented here.

[lexikos]

@DavidP
That will "release" the three keys even if they were not pressed in the first place, and then (approximately) another 2222 ms later it will "release" them again, and then 4444 ms later, and then 6666 ms... and so on until the user is no longer idle. This is why it would prevent Windows from going to standby.

You could improve it by checking the state of each key with GetKeyState prior to "releasing" it, but that may backfire if the modifiers can be "stuck down" within the active app without being down as far as the system is concerned.

[Miristegal]

I used to have control stuck sometimes, then I add SendInput '{Ctrl Up}' at the end of my code. This problem doesn't happen again.
Or to add OnError (exception, mode) => !SendInput('{Ctrl Up}'), in case of code is interrupted by error.

[PaulH]

I used to have control stuck sometimes, then I add SendInput '{Ctrl Up}' at the end of my code. This problem doesn't happen again.

Thank you!! This is absolutely brilliant and solved the problem, though it did cause two apostrophes to be added at the end of each send.
So I tried changing it to:
SendInput {Ctrl Up}
That worked.

Very happy to have a replacement for Macromaker (and the capabilities of AHK are so much more!) Thanks to all those who worked on this!!

[PaulH]

There are lots of issues with modifier keys getting stuck down. A variety of posts report it. Would be great to eliminate that problem.

I found someone else's suggestion to add this line:
SendInput {Ctrl Up}
It fixed my sticky CTRL key problem.

[mikeyww]

Thanks. I have an "emergency keyboard reset" like this as well.