AutoHotkey Community

Hallo,
i have Win7 32Bit rtm. AHK is loaded with scheduler (at user logon/high privileges). This is the script:

Everything works as expected but...
Whenever there is high load (especially HDD activity) the program somewhat crashes. It still sits in the infobar running (context menus and such still working most of the time) but no functionality (like AHK wouldn't be there at all). It works for hours correctly but if i produce high traffic like changing an audio track on avi file with avidemux its nearly instantly gone.

It somewhat doesn't like stress or something. Its just AHK, no other Program shows this behavior. I think it appeared first when i updated to latest AHK version some days ago.

Anything know about it?

does downgrading fix it ?

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

I'll go back version by version. It'll need some time.
Is there any debug, verbose or logging function that could help?

I am experiencing the same problem under Windows 7 (both x86 and x64 versions).

After considerable testing I have tracked the problem down to AHK scripts which use the mouse-hook. The problem only presents when the system is under maximum load - specifically, when the CPU is pegged.

I found a similar sounding post from 2004 in the forum describing mouse pointer lag under heavy CPU load. So it seems that, specifically under Windows 7, AHK's mouse-hook is not receiving an adequate slice of the CPU pie, which is inducing severe mouse pointer lag along with general system unresponsiveness (e.g. display updates lag too).

I was running the same AHK script under Server 2008 and XP, and did not get *any* pointer lag under those OS's. So it seems to be a Win7 specific issue.

Additionally, I discovered that when I have my Wacom tablet plugged in under Win7, the Tablet PC Input service (enabled by default in Win 7) causes the exact same problem. Disabling that service and killing my AHK script mostly eliminates said pointer lag. Though I should note I still see a small bit of pointer lag even under this circumstance when the CPU is pegged.

A final thought: running the latest Intellipoint 7.0 driver for Win 7 does *not* cause the pointer lag problem as described. Like AHK, Intellipoint (ipoint.exe) runs as a normal process in user space. So I'm wondering if there is some new trick that must be used with mouse-hooks in Windows 7 to avoid being afflicted by the problem described. I wonder if it's got something to do with Win 7's new "Windows Driver Foundation - User-mode Driver Framework" infrastructure.


There's no way I am giving up my AHK script to use Windows 7, so I'm hoping a fix can be found for the problem with respect to AHK's mouse-hook implementation. Fortunately the problem is more of an annoyance than a show-stopper for me.

I don't know if this is of any help, but this sounds like it *may* be related to some changes to how mouse hooks are being handled in Win 7.

http://support.teamdev.com/message/11254

joelpt, I don't think so.

AutoHotkey already uses low level keyboard and mouse hooks (WH_KEYBOARD_LL and WH_MOUSE_LL). Also,

Edit, unedit. Too Slow...

I see what you are saying Lexikos. Sounds like that post is referring to some other issue then.

I may try installing XP and Vista again in a day or three and see if the problem exists there and I just missed it ... though I am virtually certain I *never* saw mouse pointer lag under XP, even when the CPU was maxed out.

My "steps to reproduce" for this problem, in case anyone wants to try:

1. Install Google Chrome.
2. Start a persistent AHK script which uses the mouse hook, e.g. the one earlier in this thread.
3. Launch Chrome. In Wrench->Options->Basics set the "reopen the pages that were open last" option.
4. Open about 20 tabs (duplicating one tab 20 times via the tab's right click menu is sufficient).
5. Close and restart Chrome.
6. Observe pointer lag in Windows 7 whilst Chrome is restoring tabs.

I am sure the issue could be reproduced through some other CPU-pegging activities, but this is the specific circumstance I keep seeing it occur on.

FYI, I make frequent use of a mouse hook on Windows 7 64-bit, and have not encountered this problem. I think it's too early to assume it is specific to Windows 7.

However, I've seen "something similar" on XP, Vista and 7 when the process stops checking for messages; e.g. while running a time-consuming DllCall. If the main script thread doesn't check for messages, it can't route the appropriate messages to the keyboard/mouse hook thread. (My point is that it might not be caused by high CPU usage/no CPU time for the script.)

Perhaps this may be of some help:

Well, I tried setting this reg key to 10 (ms). I still experienced the pointer lag during Chrome launch, up until about halfway through its startup. It then went away -- but my AHK mouse hotkeys then stopped functioning altogether. Subsequently restarting Chrome presented no lag. But when I then restarted the AHK script again to make the mouse hotkeys work, the lag problem returned -- up until the moment the mouse hook bailed again.

Based on this, it seems that once a mouse hook is found to exceed the LowLevelHooksTimeout, it is essentially disabled by Windows. And as expected, the lag problem only appears while the AHK mouse hook is functioning.

I should also note that I've seen this problem exhibited on clean installs of Win 7 x86/x64 and Server 2008 R2 x64 -- installing nothing more than Chrome and a mouse-hooking AHK script and then immediately testing.

Well, after much fussing I just implemented a "band-aid" fix that works well enough for my needs. Basically this script watches the CPU% and when it gets close to 100%, it temporarily suspends the script's hotkeys. Almost completely eliminates the unresponsiveness/pointer-lag, at the obvious expense of the hotkeys being briefly unavailable.