views:

308

answers:

5

We have some global keyboard hooks installed via SetWindowsHookEx with WH_KEYBOARD_LL that appear to randomly get unhooked by Windows.

We verified that they hook was no longer attached because calling UnhookWindowsHookEx on the handle returns false. (Also verified that it returns true when it was working properly)

There doesn't seem to be a consistent repro, I've heard that they can get unhooked due to timeouts or exceptions getting thrown, but I've tried both just letting it sit on a breakpoint in the handling method for over a minute, as well as just throwing a random exception (C#) and it still appears to work.

In our callback we quickly post to another thread, so that probably isn't the issue. I've read about solutions in Windows 7 for setting the timeout higher in the registry because Windows 7 is more aggressive about the timeouts apparently (we're all running Win7 here, so not sure if this occurs on other OS's) , but that doesn't seem like an ideal solution.

I've considered just having a background thread running to refresh the hook every once in a while, which is hackish, but I don't know of any real negative consequences of doing that, and it seems better than changing a global Windows registry setting.

Any other suggestions or solutions? Both the class that sets the hooks and the delegates they are attached to are static, so they shouldn't be getting GC'd.

EDIT: Verified with calls to GC.Collect(); that they still work, so they are not getting garbaged collected.

A: 

Check out this post:

Using global keyboard hook (WH_KEYBOARD_LL) in WPF / C#

It sounds like your object is getting garbage collected. If this isn't the case, can yo post your GlobalHooks class?

GalacticJello
Both the class and the delegates are `static` so this shouldn't be the case. I mentioned this in the last sentence of the question, but I could emphasize it more.
Davy8
+1  A: 

There are two things I have thought of that might help you figure out where the problem is.

  1. To help isolate the problem's location, run another WH_KEYBOARD_LL hook simultaneously with your current hook and have it do nothing other than pass the data on down the hook chain. When you find out that your original hook is unhooked, check and see if this "dummy" hook was also unhooked. If the "dummy" hook was also unhooked, you can be fairly certain the problem is outside of your hook (i.e. in Windows or something related to your process as a whole?) If the "dummy" hooks was not unhooked, then the problem is probably somewhere within your hook.

  2. Log the information that comes to your hook via the callback and run it until the hook gets unhooked. Repeat this a number of times and examine the logged data to see if you can discern a pattern leading up to the unhooking.

I would try these one at a time, just in case either would affect the others' outcome. If after that you have no leads on what the problem could be, you might try running them together.

Zach Johnson
We actually have 3 WH_KEYBOARD_LL hooks, each of which ends with `CallNextHookEx` When it stops working they all stop working and nothing gets hit with breakpoints set in all the callbacks.
Davy8
It's also kinda frustrating because it's not consistent, sometimes I can get it to unhook after a few minutes, other times it'll stay hooked for hours, so it's pretty annoying to debug.
Davy8
@Davy8: Are you able to reproduce the problem with only one `WH_KEYBOARD_LL` hook?
Zach Johnson
+2  A: 

I think this has to be a timeout issue.

Other developers have reported a Windows7 specific problem with low level hooks being unhooked if they exceed an (undocumented) timeout value.

See this thread for other developers discussing the same problem. It may be that you need to perform a busy loop (or a slow Garbage Collection) rather than a Sleep to cause the unhooking behavior. A breakpoint in the LowLevelKeyboardProc function might also create timeout problems. (There's also the observation that a heavy CPU load by another task might provoke the behavior - presumably because the other task steals CPU cycles from the LowLevelKeyboardProc function and causes it to take too long.)

The solution suggested in that thread is to try setting the LowLevelHooksTimeout DWORD value in the registry at HKEY_CURRENT_USER\Control Panel\Desktop to a larger value.

Remember that one of the glories of C# is that even simple statements can take an inordinate amount of time if a garbage collection occurs.. This (or CPU loading by other threads) might explain the intermittent nature of the problem.

MZB
A: 

Perhaps someone else has a hook that isn't calling CallNextHookEx()?

jeffamaphone
I don't believe so because when it gets in this state, `UnhookWindowsHookEx` on the hook returns `false` indicating that the hook was gone.
Davy8
A: 

It's a long shot, but by any chance do you have anti-virus software running? That could very well be noticing a keyboard hook and kicking it out.

It's more likely it would warn you, and remove it immediately, but it's one of those odd things worth checking.

peachykeen