none
Hooking problem in Windows 7

    Question

  • I have developed on-screen keyboard using mouse hooking. (SetWindowsHookEx/WH_MOUSE_LL)
    It worked fine with Windows XP/Vistam. 
    Windows7 had some troublesome but normally, it worked fine in Windows7(when no-busy)
    When CPU is very busy(ex, playing Full-HD Movies), the hook function became disabled.
    Another problem didn't appeared. Process is also Okay. Only hook function was killed.
    Can someone give me any answer?
    Thanx!
    Friday, August 21, 2009 1:33 AM

Answers

  • Dear colleagues,

       I believe that this method (increasing timeout to 10 sec) was wrongly marked by moderator as the answer to the problem. 
    By such logic - another "answer" would be to exchange computer to faster one, because it probably will solve the problem.
    This really shows that the reason is the bug in Windows 7 : "No low level mouse hook calls will be made after any exceeding of
    the LowLevelHooksTimeout occurs. And it is true only for Windows7"


       More of that, such change could lead to system performance issues and not acceptable solution for the commercial programs.

    I have the following workaround:
    Create and start during initialization a separate thread which sets the mouse_ll hook and proceeds win message queue,
    like this:

    DWORD WINAPI mouseLLHookThreadProc(LPVOID lParam)
    {
        MSG msg;

        _hMouseLLHook = SetWindowsHookEx( WH_MOUSE_LL, .....);

        while(GetMessage(&msg, NULL, 0, 0) != FALSE)
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

        return 0;
    }

    This will make your mouse_ll processing independent of main GUI thread of the application.
    But, again, this is just workaround for Win7 bug behavior

    Regards
    Tuesday, September 22, 2009 9:13 PM
  • Removing hooks which time out repeatedly is not a bug: it is deliberate behavior in Windows 7 to protect system responsiveness from slow hooks. Input for every application in the desktop is slowed down by low level hooks: they require that every keystroke or mouse event switch to the hooking thread and wait for the hook to complete (or timeout) before switching back to the target thread and delivering the input event. Slow hooks can noticeably delay input for other applications.

    Vista instituted some protections against apps with slow low level hooks, but these protections weren't sufficient and there were still many user complaints about system responsiveness caused by such applications. Because of this, Windows 7 added a feature to unhook low level hooks which timed out multiple times.

    Ideally, applications should not use low level hooks at all.

    In most cases where low level hooks are used, other methods would be much better. Most uses of low level hooks that I've seen would have been much better implemented with RegisterHotKey or the Raw Input API.

    If you do have a use case which requires low level hooks then Alex's solution is the recommended behavior: make sure the hook runs on a dedicated thread and does as minimal processing as possible before returning. Anything lengthy should be performed asynchronously on an alternate thread.

    The LowLevelHooksTimeout registry key is a workaround for users of applications which time out, but it should not be used as an excuse for developers to continue to write slow hook code.

    --Rob

    Tuesday, May 01, 2012 11:24 PM

All replies

  • Hello Hyoil,

    I performed a test on my side, but I cannot reproduce the problem. I just took the sample from our CodeFx sample, you can get it from


    To troubleshoot this issue, could you please show us the source code and the detailed steps to reproduce the problem? So that we can investigate the issue locally. It is not necessary that you send out the whole of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business details from it. I appreciate your work on providing these information.

    Thanks,
    Rong-Chun Zhang

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, August 21, 2009 11:08 AM
  • Thank you for your answer.
    I made a new simple program for you.
    It's just a simple sample using low-level hook api.
    My test environment is Intel Atom Z520 / 1GB RAM / Windows 7.
    And played Full-HD video with launching simple hook program(attached) for making busy CPU.
    Troublesome appear in only Windows 7, so you must run in windows 7.

    Thank a lot.

    http://hldec.net/attachment/cfile5.uf@122033174A9217252B699D.zip
    Monday, August 24, 2009 4:42 AM
  • Hello Hyoil,

    I've tried the project on my side, but I still cannot reproduce the issue. I just write an application that will consume the CPU with a high percentage(even 100%), but I still cannot reproduce the issue.

    To isolate the problem, could you please also try the following thing on your side

    1. Try to run the hook application on another machine(if possible) to see if the problem still happens.
    2. Try with another appliction(not the media player) that will consume the CPU to see if the problem continues.

    Thanks,
    Rong-Chun Zhang



    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, August 24, 2009 8:05 AM
  • Hello Rong-Chun,

    I ran my hook application. And played Full-HD video.
    My capture test result can be show to below link.

    http://hldec.net/99

    My test environment :
    VirtualBox 3.0 (Single Core)
    Windows 7 Starter (7600)
    RAM 1G

    You can see killed hook procedure at about 25sec.

    Thank you.
    Thursday, August 27, 2009 2:51 AM
  • Hello Hyoil,

    I still cannot reproduce the issue, as I've suggested, did you try to run the hook application on another machine or try another application to consume the CPU resource?

    Thanks,
    Rong-Chun Zhang
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, August 27, 2009 9:55 AM
  • Hello Rong-Chun,

    I was test on my MID(Intel ATOM Z520/1GB/Win7) and VirtualBox system in my desktop.
    And, this program (using hooking) will be take in our new MID. So, I think, video playback is best method suited to test.
    If you possible, you can control and test my MID by remote access.

    My MSN ID is "onetop21@hotmail.com"

    Thanks,
    Thursday, August 27, 2009 12:23 PM
  • Hi,

       I have the similar problem with low level mouse hook on TPC with Windows 7 (XP/Vista are ok).
    Installed hook is stopped to call if during the start of main application pen is left within tablet proximity.
    If I quickly take pen out of proximity after double click (to start app) - mouse_ll hook works.
    This behavior is 100% reproducible.
    Seems like this is the real problem in Windows 7 (e.g see forum at http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/56093d14-c1bc-4d0a-a915-57fef0695191)

    Forgot to mention: this app sets some other global hooks as well  - all they always work as designed, the problem is only fith mouse_ll one.

    Thanks,
    Alex
    Monday, August 31, 2009 4:40 PM
  • I have the same problem with keyboard low-level hook. Again, the problem occurs only on Windows 7.
    Unfortunately, in my case it seems to occur randomly and can't be reproduced easily. It happens each day after some hours of work on Windows 7 workstation.
    Thanks
    Wednesday, September 02, 2009 3:47 PM
  • We have just found this in our application. We added this DWORD to the registry and the problem went away.

    HKEY_CURRENT_USER\Control Panel\Desktop\

    LowLevelHooksTimeout=10000

    We set it to 10000 as a first attempt. I have seen this key on other images set to 5000.

    It must be set by default in the system to something lower on Win 7 than in Vista.

    Hope this helps you guys as we were really worried about this one.
    Thursday, September 17, 2009 7:16 PM
  • Additional: You need to restart after adding the registry key above.
    Thursday, September 17, 2009 7:17 PM
  • Thank you!

    I'm testing now, but I couldn't find any problem. :)
    Friday, September 18, 2009 2:06 AM
  • Dear colleagues,

       I believe that this method (increasing timeout to 10 sec) was wrongly marked by moderator as the answer to the problem. 
    By such logic - another "answer" would be to exchange computer to faster one, because it probably will solve the problem.
    This really shows that the reason is the bug in Windows 7 : "No low level mouse hook calls will be made after any exceeding of
    the LowLevelHooksTimeout occurs. And it is true only for Windows7"


       More of that, such change could lead to system performance issues and not acceptable solution for the commercial programs.

    I have the following workaround:
    Create and start during initialization a separate thread which sets the mouse_ll hook and proceeds win message queue,
    like this:

    DWORD WINAPI mouseLLHookThreadProc(LPVOID lParam)
    {
        MSG msg;

        _hMouseLLHook = SetWindowsHookEx( WH_MOUSE_LL, .....);

        while(GetMessage(&msg, NULL, 0, 0) != FALSE)
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

        return 0;
    }

    This will make your mouse_ll processing independent of main GUI thread of the application.
    But, again, this is just workaround for Win7 bug behavior

    Regards
    Tuesday, September 22, 2009 9:13 PM
  • I personally agree with Alex that this isn't the best fix. But for a quick fix to a released product it is what we'll do.


    Here is a registry script to insert SMenagh's sln. copy paste into a ".reg" file.
    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Control Panel\Desktop]
    "LowLevelHooksTimeout"=dword:00002710

    And here is a script to delete it again.
    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Control Panel\Desktop]
    "LowLevelHooksTimeout"=-

    Friday, March 05, 2010 6:03 PM
  • This is also giving us fits at Lake Software.  We use LL mouse hooks in our products, and every time a user bogs their Windows 7 system down, we loose the hook and stop working correctly.  And, Windows gives us no way of knowing we have to re-hook.  It's not the time we spend in MouseProc.  It's the time windows 7 takes to schedule us.

    You can't tell a dissatisfied user their brand new super Windows 7 system is at fault.  All they know is "Your software isn't Windows 7 ready."

    We have added the LowLevelHooksTimeout registry hack to our installation procedure, but that only helps the Administrator's account used to install the software.  We have been forced to add a "Fix for Windows 7" link to our start menu, with an explanation ReadMe file and a .reg patch.  What a kluge!

    In God's name, is Microsoft aware of this problem?  Do they have any intention to ever fix it?  Or, is it not worth fixing if it probably doesn't break any "Microsoft Products"?

    Thanks,
    Bob

    Monday, March 15, 2010 4:26 PM
  • Hi there!

    I had the same problem: hooks that perfectly works with Windows XP, not working on Windows 7. I have read already the most popular questions, e.g. this link, but didn't find the solution.

    Thanks,

    Max


    Tuesday, May 03, 2011 12:08 PM
  • Hi

    I have also problems with SetWindowsHookEx on Windows 7 64Bit (VS2010 : dot net framework 4.0)

    SetWindowsHookEx is returning a handle but my Keyboard Hook Call Back has never called.

    SetWindowsHookEx is called in DLL.

                        hHook = SetWindowsHookEx(WH_KEYBOARD_LL,
                                                                       _keyboardHook,
                                                                       Process.GetCurrentProcess().MainModule.BaseAddress,
                                                                       0);

    I tryed several solution that I found over Internet but nothing works.

    Anyone has an idea for the solution ?

    Monday, January 16, 2012 9:40 PM
  • Removing hooks which time out repeatedly is not a bug: it is deliberate behavior in Windows 7 to protect system responsiveness from slow hooks. Input for every application in the desktop is slowed down by low level hooks: they require that every keystroke or mouse event switch to the hooking thread and wait for the hook to complete (or timeout) before switching back to the target thread and delivering the input event. Slow hooks can noticeably delay input for other applications.

    Vista instituted some protections against apps with slow low level hooks, but these protections weren't sufficient and there were still many user complaints about system responsiveness caused by such applications. Because of this, Windows 7 added a feature to unhook low level hooks which timed out multiple times.

    Ideally, applications should not use low level hooks at all.

    In most cases where low level hooks are used, other methods would be much better. Most uses of low level hooks that I've seen would have been much better implemented with RegisterHotKey or the Raw Input API.

    If you do have a use case which requires low level hooks then Alex's solution is the recommended behavior: make sure the hook runs on a dedicated thread and does as minimal processing as possible before returning. Anything lengthy should be performed asynchronously on an alternate thread.

    The LowLevelHooksTimeout registry key is a workaround for users of applications which time out, but it should not be used as an excuse for developers to continue to write slow hook code.

    --Rob

    Tuesday, May 01, 2012 11:24 PM
  • I agree, I would much rather be using RegisterHotKey.  However Windows seems to pre-register some key combinations such as Alt+Tab, Win+Right, Win+U, Win+P in a way that is (as far as I can tell from quite detailed on-line research) impossible to disable.  Some of these keys were available in prior Windows versions and I have got used to using them.

    My hook code is minimal.  However my code is written in C#, and so I guess it might garbage collect or similar; especially it seems vulnerable on resume from suspend.

    So whilst I can appreciate the rationale behind your answer of "you are doing it wrong", my perception is that my problem has come about by

    • using C#, a Microsoft product
    • a Microsoft decision that makes weak provision for flexibility and back-compatibility.

    As a workaround, I offer the suggestion of running a timer of duration e.g. 5 minutes, and unhooking/rehooking.

    Tuesday, March 25, 2014 9:30 PM