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.

Answer 1

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.

Answer 2

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