Is it possible to detect when a low-level keyboard hook has been automatically disconnected by Windows?

问题

I am working on a program that uses keyboard hooks. However, when the PC that the program is running on is just slightly overloaded, it causes Windows to disconnect the hook from the program, causing it to no longer respond to keystrokes.

Is there a way to prevent this, or even better, propose a different way of solving the exact same problem, by using a different architecture, maybe involving a pipeline?

回答1:

You can't "detect" this, and you absolutely shouldn't need to. What you're describing is a feature, specifically one introduced in Windows 7 to protect your system from rogue applications.

The applicable documentation describes it thusly (pay particular attention to the bolded section):

The hook procedure should process a message in less time than the data entry specified in the LowLevelHooksTimeout value in the following registry key:
HKEY_CURRENT_USER\Control Panel\Desktop
The value is in milliseconds. If the hook procedure times out, the system passes the message to the next hook. However, on Windows 7 and later, the hook is silently removed without being called. There is no way for the application to know whether the hook is removed.

The solution here is most certainly not to figure out a way to "detect" when the hook is uninstalled and reinstall it. You should have figured out that you're doing something wrong when the operating system uninstalled the hook the first time.

The actual solution is to redesign your application to return from the hook procedure more quickly. Ideally, you should return almost immediately. If you need to run some type of intensive calculation in response to the low level messages (and I can't really imagine why you would), then you should store the information you receive, return from the hook procedure, and do your processing at a later time (probably on a separate thread).

In fact, that's almost exactly what the documentation continues on to suggest:

Note: Debug hooks cannot track this type of low level keyboard hooks. If the application must use low level hooks, it should run the hooks on a dedicated thread that passes the work off to a worker thread and then immediately returns. In most cases where the application needs to use low level hooks, it should monitor raw input instead. This is because raw input can asynchronously monitor mouse and keyboard messages that are targeted for other threads more effectively than low level hooks can. For more information on raw input, see Raw Input.

回答2:

I am not so sure that the keyboard hook is always to blame. We all seem to agree that under ideal or average conditions everything should be responsive. But during its lifetime from startup to shutdown a hook also has to survive some worst-case scenarios. In my company we wrote some keyboard hooks, and they are as lightweight and asynchronous as possible, yet they still occasionally appear to get disconnected.

As a user, every day I type several ten-thousand characters. I reboot once a month at best, and on occasions I am guilty of skipping a Windows Update. With options like suspend and hibernate, I don't think I am alone. As a developer, I have to make sure that the hook keeps running from beginning to end, regardless of what happens to the system.

Normally my system is very responsive. But there can be brief, exceptional moments where it is on its knees to the point that even Windows Aero gets switched off. Right now it is very snappy. But if I press the Show Desktop button, the mouse will freeze for at least a second during the time that my 65 or so open windows are all collapsed. What if I press a key during one of these moment?

If Windows can freeze the mouse for one second, if Windows can even switch off Aero during a brief moment of heavy load, why can't a keyboard hook be allowed to survive a similar exceptional time of overload? Instead, because of one exceptional moment, Windows pulls the plug, silently affecting the remaining computing experience until system shutdown. For 200 ms affecting just one keypress out of the thousands we press every day, for just that fraction of a second, I, the user, have to reboot the system because that's the only way I understand will bring back the keyboard macro or whatever utility I depend on for my productive work.

Even if it was guaranteed to prevent the above (which worst-case experience seems to suggest is not the case), I am not so sure that everything can easily be done in a separate thread. For example, let's say the user sets up a hotkey that is to start an application. Couldn't there be reasons for starting the application from the current context (foreground window, privileges, etc.)? And wouldn't it be reasonable for the user to actually expect and accept a delay, because he knows that, using the keyboard, he just started something that takes longer? I don't know if the example is technically sound, but I wanted to illustrate how sometimes things that otherwise may be unacceptable could be acceptable, as a result of a known event.

Keyboard hooks can be very useful for many things, from macros to error correction to launching things, and this behavior introduced in Windows 7 is putting the good and the bad, the acceptable and the unacceptable, the average and the exceptional, all in the same basket. This hurts both users, because quality keyboard hooks may get killed, and developers. Just imagine what a support nightmare it is when you have no official solution to your application working well under normal conditions, but being killed at random under some heavy load (or other inexplicable) circumstance.

To conclude this with a question, does anyone know what the status is under Windows 8, has anything changed?

回答3:

Cody Gray's response is excellent, but FWIW, and purely for testing purposes, you may be able to detect a disconnected hook.

When your hook proc is invoked, store the current tick count in a variable accessible to the main thread. In the main thread, periodically call GetLastInputInfo. It will give you the tick count for the last input event in the system (not just in your process). If the value provided by GetLastInputInfo is significantly later (newer) than your last hook proc tick count, it's a good guess that hook has been disconnected.