[Solved] Keyboard hook seems to stop working [v1.1.16.05] Topic is solved

[Maniac]

Hello, I am the author of the script TypingAid. I have recently started using AHK v1.1.16.5, until now I've been using 1.0.48.5.

I am experiencing a problem where my script will suddenly (and seemingly randomly) stop detecting my keyboard input. This happens upon switching away from my text editor. I'm not even getting to the code following the Input command. I know my script is still working because if I switch windows, my 100 ms timer to detect a window switch kicks in.
This did *not* happen with AutoHotKey 1.0.48.5.

As you can see from the pasted key history below, the keyboard hook is enabled. The reason I suspect the keyboard hook is two-fold:
1. There is no keyboard input in the below pasted keyboard history excerpt (I trimmed some entries, but they are all for the mouse). I switched to this window directly after typing some code in my text editor (which should be picked up by the script). When I was typing, the script was not paused and hotkeys were not suspended.
2. I selected some text and hit my defined hotkey Ctrl-Shift-C (which is a khook enabled hotkey). This adds the word to a list to be written to a file. The word was NOT written to the file upon exiting my script, so I believe that the hotkey never triggered.

Again, I did not have this problem with AutoHotKey 1.0.48.5. This is new with 1.1.16.5.
BTW, when switching away from my text editor, the script will suspend the hotkeys and re-enable them when I switch back. Maybe something is happening when the hotkeys are unsuspended that's not re-enabling the keyboard hook properly? A race condition?
Please see my above link for the link to the source code, but it's about 2500 lines. The Input command is in the TypingAid.ahk file. The timer that gets triggered is in Incudes\Window.ahk (it's set up in TypingAid.ahk).

Thank you for any help you can provide...
Maniac

Keybd hook: yes
Mouse hook: no
Enabled Timers: 1 of 1 (Winchanged)
Interrupted threads: 2 (preempted: they will resume when the current thread finishes)
Paused threads: 0 of 3 (3 layers)
Modifiers (GetKeyState() now) =
Modifiers (Hook's Logical) =
Modifiers (Hook's Physical) =
Prefix key is down: no

NOTE: To disable the key history shown below, add the line "#KeyHistory 0" anywhere in the script. The same method can be used to change the size of the history buffer. For example: #KeyHistory 100 (Default is 40, Max is 500)

The oldest are listed first. VK=Virtual Key, SC=Scan Code, Elapsed=Seconds since the previous event. Types: h=Hook Hotkey, s=Suppressed (blocked), i=Ignored because it was generated by an AHK script, a=Artificial, #=Disabled via #IfWinActive/Exist, U=Unicode character (SendInput).

VK SC Type Up/Dn Elapsed Key Window
-------------------------------------------------------------------------------------------------------------
01 000 u 0.05 LButton
01 000 h d 0.42 LButton
01 000 u 0.06 LButton
01 000 h d 0.38 LButton
01 000 u 0.06 LButton
01 000 h d 0.36 LButton
01 000 u 0.08 LButton
01 000 h d 2.20 LButton
01 000 u 0.08 LButton
02 000 h d 6.36 RButton
02 000 h d 18.02 RButton

[lexikos]

BTW, when switching away from my text editor, the script will suspend the hotkeys and re-enable them when I switch back.

Are you saying that your script is designed to suspend its hotkeys when the text editor is not active and un-suspend when it is reactivated, but this fails and the hotkeys stop working? I don't see any specific reason that it would fail in v1.1 and not v1.0, but I would expect it to be less reliable than #IfWinActive (which leaves the hook registered). Why don't you use #IfWinActive?

As far as I can recall, no changes have been made to the way the keyboard hook is registered, or the way the hook works in general. There have only been changes to the way certain hotkeys are handled within the hook.

Usually if the hook stops working due to the typical causes - like the OS disabling it because the script was unresponsive for too long - suspending and un-suspending all hotkeys gets it working again. I suppose that it would not if any hook hotkeys are exempt from suspension, since in that case suspending hotkeys would not deactivate the hook.

You keep saying that you did not have these problems with v1.0.48.05, but you have not said that you do not have these problems with v1.0. Has anything else changed when you updated AutoHotkey? I ask because several users have previously reported problems after updating AutoHotkey, and in some cases the real cause was the OS upgrade or computer replacement that they initially failed to mention.

Have you tried v1.0.48.05 again to confirm it still does not have problems? Do you have other scripts running, or keyboard-related programs like SetPoint or IntelliType?

[Maniac]

Yes, the script suspends/un-suspends based on which window is active. Both the "Input" command and hotkeys seems to be not working (or at least aren't doing what I expect, and aren't appearing in the Key history).

#IfWinActive is not quite flexible enough for my needs. I need to know what window I'm switching from/to, whether to inactivate/activate the script based on executable name and window title, etc.

I did make minor changes when I upgraded to 1.1.16.05, but they weren't really in relevant pieces of code. I definitely plan on doing more troubleshooting (rolling back my AHK version and/or the script version)- it's just the issue only happens once or twice a day, so troubleshooting it is a very slow process.

I don't recall any major changes to my PC beyond Windows Updates and an antivirus update (though I think I saw this issue before the antivirus update).

No other scripts running. I'm pretty sure I uninstalled Intellitype months ago... but I could be wrong. Regardless, its state hasn't changed.

I will keep you updated...

[lexikos]

I need to know what window I'm switching from/to,

Why is that? If it's only to decide whether the script's hotkeys should function on the active window, as in typical scripts, you don't need to know which windows the user switches between, or even when they switch. You only need to know which window is active when the hotkey is pressed - this is how #IfWin works. For other criteria, like which window the mouse is pointing at, you can use #If (expression).

If you had different behaviour for different windows, you could detect which window is active when the hotkey is pressed. Just add all of the window titles/executable names to a window group to define which windows the hotkeys should be active for.

whether to inactivate/activate the script based on executable name and window title, etc.

#IfWinActive can do that.

I can understand if you'd prefer to keep your script the way it is. But since the issue only happens once or twice a day for you - and you presumably use your script regularly - it doesn't seem worthwhile for me to try to reproduce the problem, in order to be able to find and fix it (if it's even an AutoHotkey bug).

[Maniac]

For a user-defined list of include/exclude Window Titles and/or executables, I need to be able to:
Suspend/unsuspend hotkeys
Show/hide the wordlist listbox gui
Prevent the main loop, which waits on the Input function, from executing for windows I don't care about
Change the process priority
Change SetTitleMatchMode

Unless I'm missing something I don't think #IfWin can handle the last 4 items, right?

I'm not asking for you to try to reproduce this. My initial question was to see if anything jogged your mind - "oh, that could cause it". I fully realize I didn't give you enough information to resolve this. I will continue to work on narrowing this down... when I get to the point that I'm able to determine it's not my script, I may need to ask you for some help (such as a version of AHK that allows me to forcibly load/unload the keyboard hook).

So can we tackle one thing at a time then? When the script is working, they keys show up in the key history. When the script is not working, it doesn't show up in the key history.
What would be a reason for a pressed key *not* to show up in the key history? I will try to look at it from that angle.

Also, I have put some more debugging code in my script - I have put variables to store the last "A_Now" values around my Input command to see if I'm getting stuck within the Input command.

Thanks for the help so far.

[lexikos]

Generally when someone posts in the Bug Reports forum, it's either to report a bug to be fixed, or misplaced.

such as a version of AHK that allows me to forcibly load/unload the keyboard hook

Suspend will do it unless the script contains #InstallKeybdHook or a hook hotkey exempt from suspension. You can verify that it uninstalls the hook by using KeyHistory after Suspend On.

What would be a reason for a pressed key *not* to show up in the key history?

Key History is turned off. Or no events were sent to the keyboard hook. This can happen under normal circumstances if the active window belongs to something running as admin while the script is not. It can also happen after the hook procedure fails to return within an OS-defined timeout (normally 5 seconds), but it's designed to avoid this. If you suspend the process using DllCall, for instance, it will cause this. If the hook timed out, you'd probably notice that the keyboard was unresponsive for 5 seconds.

Unless I'm missing something I don't think #IfWin can handle the last 4 items, right?

No, but using #IfWin in addition to a timer (and not Suspend) would totally avoid hook registration/unregistration problems.

Btw, you can use a shell hook to detect window activation without using a timer.

[Maniac]

Generally when someone posts in the Bug Reports forum, it's either to report a bug to be fixed, or misplaced.

Right... and there seems to be something wrong with the keyboard hook as I'm not seeing anything in my key history.

Suspend will do it unless the script contains #InstallKeybdHook or a hook hotkey exempt from suspension. You can verify that it uninstalls the hook by using KeyHistory after Suspend On.

I do not have #InstallKeybdHook or a hotkey that's exempt from suspension. However, it is not uninstalling the hook when suspend is on. My Input accepts 1 character and then checks to see if the window is one I care about, if not, it waits until there's one I care about (Using WinWait). However, my 100 ms timer will also detect if the window is one I care about, and if not, it will wait as well until there's one I care about (again, using WinWait). Would that leave the main thread stuck on the Input command and prevent the Keyboard hook from uninstalling?

Key History is turned off. Or no events were sent to the keyboard hook. This can happen under normal circumstances if the active window belongs to something running as admin while the script is not. It can also happen after the hook procedure fails to return within an OS-defined timeout (normally 5 seconds), but it's designed to avoid this. If you suspend the process using DllCall, for instance, it will cause this. If the hook timed out, you'd probably notice that the keyboard was unresponsive for 5 seconds.

I checked for #KeyHistory, it's not defined in my script. All the programs are running as an Admin, including the script (I have UAC off). I have not noticed the keyboard being unresponsive for 5 seconds. As mentioned though... when the script is working, I see the keys in the key history... when it's not, the keys aren't showing up.

No, but using #IfWin in addition to a timer (and not Suspend) would totally avoid hook registration/unregistration problems.

Btw, you can use a shell hook to detect window activation without using a timer.

Thanks, it sounds like there are some improvements I can make. I was not aware of Window Groups before, those sound useful. These both sound better than what I'm currently doing.

[Maniac]

However, my 100 ms timer will also detect if the window is one I care about, and if not, it will wait as well until there's one I care about (again, using WinWait). Would that leave the main thread stuck on the Input command and prevent the Keyboard hook from uninstalling?

This definitely seems to be the case. I think this would explain why I can't get the keyboard hook to unload. Since my keyboard hook isn't working, my Input command never receives a key - but it's still stuck on the Input command. As such, even if I switch windows and type a letter within 100ms, I never get out of the Input command and suspend while not waiting on Input.

I have some debugging code in place that will more clearly identify this as a problem. When this happens again, I will report back with my findings.

[lexikos]

Generally when someone posts in the Bug Reports forum, it's either to report a bug to be fixed, or misplaced.

Right... and there seems to be something wrong with the keyboard hook as I'm not seeing anything in my key history.

Something has gone wrong and it is causing you a problem. This does not necessarily indicate a bug in AutoHotkey. Since you don't expect me to reproduce and fix it, I guess you were just asking for help. There's another forum for that.

when I get to the point that I'm able to determine it's not my script

That's when you should post in Bug Reports, not sooner.

However, it is not uninstalling the hook when suspend is on. [...] Would that leave the main thread stuck on the Input command and prevent the Keyboard hook from uninstalling?

If the Input command has been called and has not yet returned - i.e. it is waiting for keystrokes - the keyboard hook cannot be uninstalled. You can try cancelling the Input (call Input with no parameters) before suspending the hotkeys.

Another possible cause I don't think I've mentioned:
If another program installs a keyboard hook and does not properly pass messages along to the next hook in the chain, AutoHotkey's hook will stop receiving keyboard messages even though the hook itself is still operational. Uninstalling and reinstalling the hook would put it back at the beginning of the hook chain, so would get it working again in that case.

[Maniac]

This seemed like the appropriate place to put it to me as the potential for it to be a bug (from my perception) was high. If you would prefer this to be in the Ask for Help forum, I would be fine with you moving it. I'm not trying to argue or cause problems here, and I'm sorry if I've given you that impression. I appreciate the help you've given.

If the Input command has been called and has not yet returned - i.e. it is waiting for keystrokes - the keyboard hook cannot be uninstalled. You can try cancelling the Input (call Input with no parameters) before suspending the hotkeys.

OK, thanks. Cancelling the Input (assuming unloading/reloading the keyboard hook works) seems like a good workaround to me. I will approach it from that angle, as it seems like a good change regardless. First though, I'd like to determine the actual cause, if at all possible.

If another program installs a keyboard hook and does not properly pass messages along to the next hook in the chain, AutoHotkey's hook will stop receiving keyboard messages even though the hook itself is still operational.

These programs stand out to me based on around when this problem started:
TortoiseGit (recently installed and has worker processes running)
Opera beta (I always have this running, but it updated around when the problem started)
SciTE4AutoHotkey (I develop with AHK in spurts, so I'm not typically using this program. I have been using it a lot recently, though)

I will approach it from the angle of those programs too.

[Maniac]

Lexikos, I think I figured out what's going on. I uninstalled AHK v1.1.16.05 and installed AHK v1.0.48.5. Yesterday (without SciTE running) and today (with SciTE running) I ran my script and have not had any issues.

I decided to check the Key history while my hotkeys were suspended and the Keyboard hook was *not* installed. I added some quick debugging with ListLines, and verified that my main thread was indeed waiting on the Input command. If I disable my window checks, I can see that the Keyboard Hook is getting installed.

So I think what's happening is that when AHK v1.0.48.5 suspends the hotkeys (or possibly when the main thread is interrupted?), the Keyboard hook is uninstalled (even though my interrupted main thread is still waiting on input). It's reinstalled when hotkeys are un-suspended (or maybe it's when the main thread is resumed?).
In AHK v1.1.16.05, it does not uninstall the keyboard hook when this happens (so there's no need to reinstall it).

This means that AHK v1.0.48.5 cannot experience the problem I'm having, because it always installs and uninstalls the keyboard hook, whereas v1.1.16.05 leaves it installed.

Was this an intentional change in v1.1 vs v1.0? Either way, I can probably work around this with the Input command when I suspend, as you've pointed out.

Please let me know if you need any more information or help from me regarding this. Thank you!

[Maniac]

With AHK v1.0.90.0, the keyboard hook uninstalls.
With AHK v1.1.3.0, the keyboard hook stays installed.

My guess is it's a change in AHK v1.0.91.01:
Fixed: Disabling the last hook hotkey breaks Input.

-------

I added the code to trigger "Input" before I call suspend. I confirmed this does now uninstall the keyboard hook when the hotkeys suspend.

[lexikos]

Right, it's not supposed to uninstall if it's in use.

I guess that you didn't encounter the problem in v1.0.48.05 because your script was effectively reinstalling the hook occasionally (despite that it was still in use). Thanks for posting your findings.

[Maniac]

So basically, the bug was in v1.0.48.5, and it just so happened to make my script work correctly.

I will commit my changes to use Input with no parameters when suspending.

Thanks for your help in finding a solution for this.

[Lisa19]

solved it by reloading the script

[eladkarako]

try switching between SendMode (Input/Event) it might help. I also explicitly use InstallKeybdHook and Persistent (must use ExitApp to close it). it helped with windows 10 recent builds. I also compile the ahk to exe without compression, and use an embedded manifest to make it run properly on Windows 10. (github / eladkarako / manifest / example_manifest / generic_with_info.manifest --- I also modified it to use requireAdministrator but it is not required. gdiScaling is optional to be added for old UI applications, it keeps the scale ration in dpi awareness).