Summary
With UseAutoRestartHooks=1, Volume2 repeatedly unhooks and reinstalls its global low-level mouse and keyboard hooks about every 625 ms. On my machine this correlates with intermittent global mouse/input stutter, and Frida instrumentation captured slow WH_MOUSE_LL callback executions from Volume2 itself.
Environment
- Volume2 version:
1.1.8.465
- Package type: portable
Volume2.exe
- OS: Windows 10
Relevant config
[UserVariables]
DelayBeforeRestartMouseHook=500
UseAutoRestartHooks=1
LowLevelHooksTimeout=10000
[MouseMoveVolumeControl]
UseMoveWatch=1
[MouseActions]
UseMouseScroll=1
What I observed
I attached Frida to Volume2.exe and instrumented:
user32!SetWindowsHookExWuser32!UnhookWindowsHookEx- the registered
WH_MOUSE_LL / WH_KEYBOARD_LL callback functions
Volume2 repeatedly performs this sequence:
UnhookWindowsHookEx(old mouse hook) -> success
SetWindowsHookExW(WH_MOUSE_LL) -> new hook
UnhookWindowsHookEx(old keyboard hook) -> success
SetWindowsHookExW(WH_KEYBOARD_LL) -> new hook
The hook callback addresses are stable:
WH_MOUSE_LL callback Volume2.exe + 0x2da5d4
WH_KEYBOARD_LL callback Volume2.exe + 0x2d8fd4
In one 20 second run:
hook_registered: 64
hook_unregistered: 64
mouse hook registration interval: avg 625 ms, min 618 ms, max 631 ms
In a separate 45 second run after restarting Volume2:
hook_registered: 144
WH_MOUSE_LL: 72 registrations
WH_KEYBOARD_LL: 72 registrations
mouse hook registration interval: avg 625.2 ms, min 603 ms, max 662 ms
In a 120 second Frida-only run, the WH_MOUSE_LL callback had slow calls:
The intermittent mouse stutter happens while overall CPU, memory, DPC and interrupt usage remain low. A separate low-level mouse hook probe measured WM_MOUSEMOVE gaps in the 100-300 ms range during continuous mouse movement.
Why this looks problematic
I understand that "auto restart hooks" may be intended as a compatibility watchdog, but reinstalling global low-level hooks about every 0.6 seconds seems very aggressive. Since low-level mouse hooks run synchronously in the global input path, any slow callback or hook-chain interaction can stall mouse input for all applications.
Would it be possible to make UseAutoRestartHooks less aggressive, event-driven, or disabled by default? At minimum, it would help if the hook restart interval were much longer or if hooks were only restarted after an actual failure is detected.
Related note
I found issue #155, but that report used UseAutoRestartHooks=0, so this appears to be a different problem path.
Summary
With
UseAutoRestartHooks=1, Volume2 repeatedly unhooks and reinstalls its global low-level mouse and keyboard hooks about every 625 ms. On my machine this correlates with intermittent global mouse/input stutter, and Frida instrumentation captured slowWH_MOUSE_LLcallback executions from Volume2 itself.Environment
1.1.8.465Volume2.exeRelevant config
What I observed
I attached Frida to
Volume2.exeand instrumented:user32!SetWindowsHookExWuser32!UnhookWindowsHookExWH_MOUSE_LL/WH_KEYBOARD_LLcallback functionsVolume2 repeatedly performs this sequence:
The hook callback addresses are stable:
In one 20 second run:
In a separate 45 second run after restarting Volume2:
In a 120 second Frida-only run, the
WH_MOUSE_LLcallback had slow calls:The intermittent mouse stutter happens while overall CPU, memory, DPC and interrupt usage remain low. A separate low-level mouse hook probe measured
WM_MOUSEMOVEgaps in the 100-300 ms range during continuous mouse movement.Why this looks problematic
I understand that "auto restart hooks" may be intended as a compatibility watchdog, but reinstalling global low-level hooks about every 0.6 seconds seems very aggressive. Since low-level mouse hooks run synchronously in the global input path, any slow callback or hook-chain interaction can stall mouse input for all applications.
Would it be possible to make
UseAutoRestartHooksless aggressive, event-driven, or disabled by default? At minimum, it would help if the hook restart interval were much longer or if hooks were only restarted after an actual failure is detected.Related note
I found issue #155, but that report used
UseAutoRestartHooks=0, so this appears to be a different problem path.