mouse hotkeys stop working after some time and memory usage

[Owyn]

ahk hotkeys stopped working at all after some heavy RAM & paging file usage

this bug was in 1.13 and still present in 1.19

F1 hotkey still works and sends F11

058: Send,{F11} (0.01)
059: Return (205.16)

but there is just no sigh of mouse hotkeys in the log (neither in recently executed or in key history)

Keybd hook: yes
Mouse hook: yes
Enabled Timers: 0 of 0 ()
Interrupted threads: 0
Paused threads: 0 of 0 (0 layers)
Modifiers (GetKeyState() now) =
Modifiers (Hook's Logical) =
Modifiers (Hook's Physical) =
Prefix key is down: no
70 03B h d 0.94 F1
7A 057 i d 0.00 F11
7A 057 i u 0.00 F11
70 03B s u 0.11 F1

and no sight of mouse being clicked, no mouse1, no mouse2 or mouse4 & 5, no even in windows hotkey should not be used at all - it just doesn't log mouse clicks anymore.

Type Off? Level Running Name
-------------------------------------------------------------------
m-hook XButton1 & WheelUp
m-hook XButton1 & WheelDown
m-hook XButton1 UP
m-hook XButton1
m-hook XButton2 UP
m-hook XButton1 & LButton
m-hook XButton1 & RButton
k-hook F1
k-hook Backspace
k-hook w
k-hook s
k-hook a
k-hook Left
m-hook XButton2
k-hook d
k-hook Right

full script:

Code: Select all

#SingleInstance force
Menu, Tray, Icon , m2.ico

;// Programs
EList =
(LTrim
ahk_class Chrome_WidgetWin_1
ahk_class MozillaWindowClass
ahk_class Notepad++
)

Loop, parse, EList, `n
{
  GroupAdd, Programs, %A_LoopField%
}

; horizontal scroll
XButton1 & WheelUp:: 
	; Scroll to the left
	MouseGetPos,,,id, fcontrol,1
	;Loop 8 ; <-- Increase for faster scrolling
		SendMessage, 0x114, 0, 0, %fcontrol%, ahk_id %id% ; 0x114 is WM_HSCROLL and the 0 after it is SB_LINERIGHT.
return
 
XButton1 & WheelDown:: 
	;Scroll to the right
	MouseGetPos,,,id, fcontrol,1
	;Loop 8 ; <-- Increase for faster scrolling
		SendMessage, 0x114, 1, 0, %fcontrol%, ahk_id %id% ;  0x114 is WM_HSCROLL and the 1 after it is SB_LINELEFT.
return

#IfWinActive ahk_group Programs 

; Next tab
XButton1 UP::
	Send ^{Tab}
return
XButton1::return

; Prev tab
XButton2 UP::
	Send +^{Tab}
return

; Close tab
XButton1 & LButton:: 
	Send ^{F4}
	;Send {Ctrl Up} ; fix lol
return

; Refresh
XButton1 & RButton:: 
	Send {F5}
return

; F1 to FullScreen
F1::
	Send {F11}
return

; // Custom Actions for custom Applications

; Win7 back button in explorer - up one level
#IfWinActive, ahk_class CabinetWClass
Backspace::
	ControlGet renamestatus,Visible,,Edit1,A
	ControlGetFocus focussed, A
	if( renamestatus != 1 && (focussed = "DirectUIHWND3" || focussed = "SysTreeView321") )
	{
		SendInput {Alt Down}{Up}{Alt Up}
	}
	else
	{
		Send {Backspace}
	}
return

; Configure Hotkeys for CDisplay
#IfWinActive, ahk_class TMainDisplayForm
w::
	Send {Up}
return

s::
	Send {Down}
return

a::
Left::
XButton2::
	Send {PgUp}
return

d::
Right::
XButton1::
	Send {PgDn}
return

made a dump with both task manager and windbg using .dump /ma, not sure if it contains personal information, gonna upload it here or send you to an address you'd write if it could help.

[Owyn]

ok, bug is still there and seems to be well known among AHK users cuz I've found a fix "launch AHK script as admin" in the internet, can't this be fixed so it'd work without admin rights fine?...

[lexikos]

I don't believe what you've found is a bug.

Unless some other application which runs as admin is interfering, I see no reason for running as admin to have any effect on this sort of issue.

AutoHotkey registers keyboard and mouse hooks to be notified of keyboard and mouse input by the OS. If the OS - or some other application's hook - chooses not to call the hooks, it will appear to AutoHotkey that the keyboard/mouse input never happened in the first place.

You can try to avoid "heavy RAM & paging file usage" or other conditions that might cause AutoHotkey to become unresponsive. You can also try increasing LowLevelHooksTimeout.

The hook procedure should process a message in less time than the data entry specified in the LowLevelHooksTimeout value in the following registry key:

HKEY_CURRENT_USER\Control Panel\Desktop

The value is in milliseconds. If the hook procedure times out, the system passes the message to the next hook. However, on Windows 7 and later, the hook is silently removed without being called. There is no way for the application to know whether the hook is removed.
Source: LowLevelMouseProc callback function (Windows)

[Owyn]

I've upgraded my PC since the 1st post of this thread to have 16 gb ram and no paging file...

[guest3456]

I've upgraded my PC since the 1st post of this thread to have 16 gb ram and no paging file...

maybe try using something as a paging file/virtual memory. having none at all doesn't seem like a good idea

[Guest]

I've had this issue with a script that disables mouse buttons and redirects input elsewhere using AHKHID. It happens intermittently. The script also has BlockInput, MouseMove but that keeps blocked even after mouse buttons fail. The script runs as admin.

[Owyn]

hmm, launching script as admin seem to have fixed this for me