winapi - Detect SetWindowsHookExA WH_MOUSE_LL detachment / unhooking -

i have little python script collects statistics keyboard , mouse usage on windows machine.

i set via windll.user32.setwindowshookexa(win32con.wh_mouse_ll, mouse_pointer, win32api.getmodulehandle(none), 0). write can see api i'm using. have been c++ programm.

it works fine, 1 exception: when use android studio compile app, core i7 4 cores maxes out @ 100% on cores, mouse , os in general becomes unresponsive, known issue android studio.

usually when such high cpu load occurs couple of seconds (4+) wh_mouse_ll hook gets detached os, if it's saying "nope, don't have time you, we're unregistering you"

i don't blame on python, because have sound volume manager called powermixer apparently registers mouse hook can track mouse scroll wheel actions on lower taskbar (explorer.exe shell_traywnd) , application looses it's ability use mouse hook after compiling.

also, when compiling , scroll scroll wheel (just fun) computer starts beep, in low level system beep , keyboard hooks unregistered well.

how can detect via windows api if hooks got detached / unhooked? don't require python specific answer, infos on proper way use win32 api deal this.

the remarks section of setwindowshookex documentation says:

if hook procedure times out, system passes message next hook. however, on windows 7 , later, hook silently removed without being called. there no way application know whether hook removed.

am out of luck here?

update: couple of weeks later, want inform hans passan's suggestion working well. recommend this. while 10.000 ms seems bit high, i've set value , have no negative effects. way go solve issue system wide within couple of minutes.

how can detect via windows api if hooks got detached / unhooked?

there no direct way it, , own question quoted msdn documentation backs up:

if hook procedure times out, system passes message next hook. however, on windows 7 , later, the hook silently removed without being called. there no way application know whether hook removed.

however, indirect way might have hook keep track of last time called, , main app/script can call getlastinputinfo() periodically , compare time tracked time. if difference significant margin higher hook timeout stored in registry (see documentation), bet hook may gone.

the following msdn blog explains details of hook timeout:

global hooks getting lost on windows 7

but, importantly, states:

my recommendation low level hooks should avoided whenever possible. if monitoring keystrokes (and not trying block them), can keyboard input via raw input. lighter weight hooks, won’t affect other apps’ responsiveness, , won’t turned off if app isn’t responsive.

which same microsoft's own recommendation in lowlevelmouseproc() , lowlevelkeyboardproc() documentations:

if application must use low level hooks, should run hooks on dedicated thread passes work off worker thread , returns. in cases application needs use low level hooks, should monitor raw input instead. because raw input can asynchronously monitor mouse , keyboard messages targeted other threads more low level hooks can. more information on raw input, see raw input.