Low level mouse hook - mouse freeze on breakpoint

Question

I would like to draw and move my windows by myself (using chromium embedded framework). To do this, i need a global callback when the mouse is being moved, outside of my window - so i installed a low level mouse hook:

hMouseLLHook = SetWindowsHookEx(WH_MOUSE_LL, (HOOKPROC)mouseHookProc, hInstance, NULL);

The hook simple grabs the mouse events and calls "CallNextHookEx". No problems here, everything works as excpected. My problem now: if the debugger breaks or an exception is being thrown, I can't move the mouse anymore..

I tried processing the hook in another thread, like so:

HANDLE mouseProcHandle = CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE)mouseProcessor, NULL, NULL, &dwMouseProcThread);

DWORD WINAPI Win32Application::mouseProcessor(LPVOID lpParm) {
    hMouseLLHook = SetWindowsHookEx(WH_MOUSE_LL, (HOOKPROC)mouseHookProc, ((Win32Application*)Application::getInstance())->hInstance, NULL);

    MSG message;
    while (GetMessage(&message, NULL, 0, 0)) {
        TranslateMessage(&message);
        DispatchMessage(&message);
    }

    UnhookWindowsHookEx(hMouseLLHook);
    return 0;
}

But this also does not solve the problem. Is there a workaround, solution or another method to do this? Also, I think a low level hook may not be necessary, as I only need to be informed about the moevement and it wouldn't be a problem if I would be the last one in line, so the system/other processes can process the mouse callbacks first.

Do you really need a hook for this? Is capture not good enough? — Raymond Chen, Mar 02 '14 at 17:55
Would be enough, but it must be everywhere and window independent. Do you have another solution to archive this? — lunatix, Mar 02 '14 at 18:55

score 7 · Answer 1 · answered Mar 02 '14 at 16:54

To shed a little more light on this: When you intercept all mouse move events they all end up in your hook which can modify or swallow them. The system therefore calls for every mouse move event your hook and waits until your hook routine is done with it until it calls your hook again for the next pending mouse move event.

Guess what happens when you break into the debugger in your hook event? No more mouse events until you have stepped through your hook routine. Normally you could bring down your whole system with such a central hook. But luckily Windows did anticipate bad hooks. You will notice that after some timeout the system responds to mouse events again. My guess would be that Windows simply removes your hook when it does hang once.

Now about debugging: The only way to safely break into the debugger is to never touch the mouse after you are in the hook. Not very practical. The only way out is to trace the interesting things and look into your log file what did happen inside the hook. If you are after example code how to hook mouse and keyboard events you can have a look here:

http://etwcontroler.codeplex.com/SourceControl/latest#ETWControler/Hooking/Hooker.cs

Thanks for the C# link, i'll keep this in mind for .net development :) Oh and I was not speaking of breaking only inside the hook itself, it was more general - breaking anywhere causes the problem - as like as you mentioned it, because my method stops the callback queue. My application is running several threads so maybe it is possibly to only stop the applications thread but not the hook thread (like @deviantfan posted above). — lunatix, Mar 02 '14 at 17:12

score 3 · Accepted Answer · answered Mar 02 '14 at 16:35

3

As your debugger stop the whole program (all threads of it)
there is probably no workaround if using the hook.
Not as accurate, but you could poll GetCursorPos in a thread instead.

answered Mar 02 '14 at 16:35

deviantfan

11,268
3
32
49

this would be an acceptable solution for the debug version, i think.. not a "nice" workaround but it would do the job :) – lunatix Mar 02 '14 at 16:40
...or maybe http://social.msdn.microsoft.com/Forums/vstudio/en-US/d6d18a8e-5b2d-4fe3-bc80-6e6b61d256b1/vs2008-multithread-debug-keep-1-thread-running-while-stepping-through-other-thread helps. I too didn´t know this was possible until now (if this is correct), thanks for bringing this topic up :) – deviantfan Mar 02 '14 at 16:45
Accepted this answer because it pointed me in the right direction. Final solution was to use a normal mouse hook (not lowlevel) on each of the windows which are being created from chromium - mapping is done with the HWND handle (it's a child window, so simply seek it's parent) of the given MOUSEHOOKSTRUCTEX. Works like a charm. Thanks @all :) – lunatix Mar 04 '14 at 21:42

Low level mouse hook - mouse freeze on breakpoint

2 Answers2

Linked