2

I'm having an issue with the keyboard logger. Every system tested until today is working fine, except a Windows 7 Embedded Standard 32 bit that apparently freaks out with the current build.

What I need to do is record keystrokes entered from the keyboard, until I get a certain number of them. When I do, I call a certain procedure.

I have a hook defined like this:

SetWindowsHookEx(WH_KEYBOARD_LL, keyboardProcedure, GetModuleHandle(NULL), 0);

and a keyboardProcedure callback: 

LRESULT CALLBACK SystemKeyboardReadWrite::keyboardProcedure(int nCode, WPARAM wParam, LPARAM lParam)
{
   ... 
}

I'm using Qt 5.2 for this application.

So, in more depth, the problem occurs when you enter the keys too fast or hold a certain key for a longer period of time, which will force the keyboard to send multiple keyboard events. When that happens, the hook will freeze and not send any more events to the callback. (not the entire application, the app will still continue running with the exception of the keylogger)

This problem occurs only on this OS, on no other Windows 7 OS, or Windows XP have I noticed the issue. I have 2 computers with the same setup and they both show the same problem, also I'm developing the app on a Windows 7 professional and it also seems fine. I'm wondering if this is an issue with my application, or is it something outside of my control.

Thanks everyone for their help.

alexg
  • 902
  • 11
  • 37
  • 1
    Judging from the given signature, it looks like your hook procedure is a *member* function in a class. That shouldn't have ever worked. It needs to be a static function if it's defined in a class. I assume you just neglected to copy and paste the `static` modifier? Aside from that, the usual cause of this problem is doing too much work inside of the hook procedure. You don't show us any of the code that it contains, so we can only guess. Certainly should have caused problems on other systems, though. I'm not an expert on Embedded Windows by any stretch. Hard to imagine what's different. – Cody Gray - on strike Aug 22 '14 at 15:17
  • I pasted the code from the .cpp file. But yes, it's a static method, here's the definition from the header. `static LRESULT CALLBACK keyboardProcedure(int nCode, WPARAM wParam, LPARAM lParam);`. I pasted only the bare bones needed to solve the problem, I computed a small build, with the contents of the callback relatively small and the issue still persists, so the details inside the callback are irrelevant. But thank you for your attention – alexg Aug 22 '14 at 15:35

1 Answers1

2

I don't know Windows Embedded, but I am familiar with Windows 7 and the LowLevel Hooks, both mouse and keyboard.

The symptom of getting kicked off the hook list can be reduced/modified with the LowLevelHooksTimeOut registry value. You have to reboot the system after it is modified. Basically that value says the number of milliseconds that hooks have to interact with the keys.

If you writing your file from inside the hook method, too, that could be the exact time when it times out, too.

For example, you get 100 key strokes, then you write it to a file. If they are holding down the keys across 100 to 101+, and you are taking longer than the maximum time with the hook, then Windows will blacklist your hook call back and kick you off the list of hooks.

The default time on Windows 7 (desktop) is 200 ms, I think. For embedded I wouldn't be surprised if it is less. Also when multiple programs are all hooking the keyboard, it can affect the timing of how long your hook is allowed to access it.

I also have only really used hooks that are established in a dll, and hold onto a global HHOOK handle. Watching all the return codes of your functions may also shed some light onto the situation.

More info on LowLevelHooksTimeout:

Low level Keyboard Hook works on one on Windows 7 x64 and not another

Community
  • 1
  • 1
phyatt
  • 18,472
  • 5
  • 61
  • 80
  • Thank you, very useful! I'll try changing the registry value and see if it works. I'll let you know in a few hours. Thanks again :) – alexg Aug 22 '14 at 15:39
  • Also as a potential solution, I would try running the keyboard hook from a different thread, could that make a difference? I noticed this as a potential solution here: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/56093d14-c1bc-4d0a-a915-57fef0695191/windows-7-setwindowshookex-callback-proc-stops-getting-called-after-exceeding-max-time-allowed?forum=windowsgeneraldevelopmentissues#d378145f-ab4c-4108-9df3-22a7d3bb7e8f Thank you for your input :) – alexg Aug 22 '14 at 15:43
  • 1
    Yes. Besides running in a DLL, I've always started and ran my hooks in a separate high priority thread. – phyatt Aug 22 '14 at 15:46
  • oh, okay. Can you find me an example illustrating that? – alexg Aug 22 '14 at 15:49
  • Qt can do threading really well. Read up on QThread, and you should be able to. – phyatt Aug 22 '14 at 17:28