1

I have a problem when trying to hook the keyboard (not a keylogger!) I´m trying to automate Word, then i´m calling dll with a especific hook.

I have a desktop and a notebook (the two have same antivirus + windows 7 x64), the only diference is that in the notebook the windows was installed with a newer version. THE PROBLEM: In the notebook EVERYTHING WORKS FINE. But in the desktop odd things happen: the hook was installed and works well if targeted to Notepad, but, when targeted to Word, though the hook was installed, the call to a external function is supressed!

 LRESULT CALLBACK HookProc(int code, WPARAM wParam, LPARAM lParam)
 {
   if (code<0) {
      return CallNextHookEx(HookHandle,code,wParam,lParam);
   }

   bool callNextHook = true;
   if (callFunction != NULL) {
          // ONLY WITH WORD AND ONLY IN THE DESKTOP callFunction SEENS TO BE NULL!!!
          // this is a pointer to a function in main application
      callFunction(code,wParam,lParam,&callNextHook);
   } else {
      ShowMessage("THE UNKNOW ERROR! THIS MESSAGE IS SHOWED, THEN HOOK IS INSTALLED");
   }

   //Call the next hook in the chain
   if (callNextHook) {
      return CallNextHookEx(HookHandle,code,wParam,lParam);
   }

   return 0;
 }

I already tried disabling antivirus, changing user account control, running the program as admin... nothing works. What is causing this difference?

Kate Gregory
  • 18,808
  • 8
  • 56
  • 85
sgm
  • 196
  • 3
  • 14
  • I'm sure there's a more appropriate site somewhere in the StackExchange network for this question... – Chip Bennett Aug 30 '12 at 01:54
  • Well I'was searching on the stack overflow and on the web, only thing I found is about hook timeout in windows 7, I tried the solution but not works. Try to desinstall antivirus and don´t works too. Try change the code to use RegisterHotKey, but unfits the needs. All are 32bits (app,dll,target), no 64bits dll injection problem. If the hook fail at all, or at lest fail in both same OS machines, I think will be a easier task... – sgm Aug 30 '12 at 11:55
  • Odds... in fact is a 32/64 bit problem, the ODD is: app is 32bits, dll is 32bits, work only with 64bits targets! I think is cause the OS is 64 bits, try tests in other OS systems... – sgm Aug 30 '12 at 12:49

2 Answers2

1

It probably has to do with the LowLevelHooksTimeout value in the registry.

On faster machines, they can process the hooks fast enough and make it under the default 200 ms to process timeout. On slower machines, they have a harder time.

For me I've had to bump up this value from the default to 500 ms (0x1F4) for my application involving hooks, to be reliable across machines.

To see the effect of changing this registry value, you have to restart your computer.

See the fourth paragraph in the remarks on the documentation here:

LowLevelKeyboardProc callback function

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.

Hope that helps.

Community
  • 1
  • 1
phyatt
  • 18,472
  • 5
  • 61
  • 80
  • Hi, thanks for the answer. I already have setted LowLevelHooksTimeout as high as 0x2710, but still have same problem. – sgm Oct 29 '12 at 21:38
  • Have you looked at the UI-Access = true stuff? I put some information about it in a similar post here: http://stackoverflow.com/questions/10930353/injecting-c-dll/11008591#11008591 Setting the UI-Access to true, and having your executable in C:/Program Files/, and having your dll digitally signed helps to access some of the secure windows in Windows. Here is an article that discusses some of these things. – phyatt Oct 30 '12 at 22:24
0

Seems to be a bug in rad studio xe2, compiling the hook dll with xe6 resolved the issue. Interesting, with this bug and some extra code, was possible to hook both 32 and 64 programs with only one dll. This way, I continue using the old dll compiled with xe2.

sgm
  • 196
  • 3
  • 14