Mouse cursor very slow/choppy after Windows sleeps overnight

[Cedo]

Five days a week, I put my Windows 7 PC into sleep mode and then wake it up the next day. Roughly 1 in 10 of these wake ups (about twice per month) results in this mouse cursor error. Windows asks me to submit the error to them, and the details are:

Files that help describe the problem:
C:\Users\sklein\AppData\Local\Temp\WERED40.tmp.WERInternalMetadata.xml
C:\Users\sklein\AppData\Local\Temp\WERF2EC.tmp.appcompat.txt
C:\Users\sklein\AppData\Local\Temp\WERF627.tmp.mdmp

*The mouse cursor error begins a few seconds after loading the desktop from sleep mode.
*It continues indefinitely until my script is closed.
*It causes long (2-5 second) delays of mouse response time to all physical movements of the mouse.
*The mouse does not move smoothly - its movement only refreshes appx. every 1 second.
*Telling Windows to send the details to Microsoft results in closing the script, but it takes patience to aim the mouse at that button.
*I theorized this is because this PC may rely on a WAN connection to a server to host its own desktop. Trying to run the script from the server could be the cause of this intermittent issue.
*We once reproduced the issue by running a script from a remote drive, then deleting the file. We were unable to reproduce it again this way (with a single attempt.)

[guest3456]

how are we supposed to fix the bug if you dont post your script that causes it?

sounds like you just have a slow computer and need to upgrade

[Cedo]

The hardware's performance wouldn't make sense given the information provided, since it works fine until it comes out of sleep, then screws up the whole computer. Also it happens on all of the PCs on the network that I have tried out. They run i5 2400 CPUs or better and 8gb RAM.

As to posting the script, it is actually the same on multiple scripts, including one that is nothing more than a dozen or so hotstrings. They can be anything or nothing, pretty sure it's just a matter of having trouble accessing the script's source file over the network, or an issue coming out of sleep. However, I thought that once it's been run, it doesn't need the origin file anymore. So it's an issue with coming out of sleep mode on a network hosted operating system I think. Someone who developed the AHK software should be able to come up with some theories about what's going on, and maybe others as well.

Here's an example script, with setworkingdir, but it has the same issue without it:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
;#Warn Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir, C:\Temp ; Ensures a consistent starting directory.
DetectHiddenWindows, On
#SingleInstance, force

::test::this is a test hotstring

[lexikos]

I doubt that this is the result of an AutoHotkey bug.

Unless the script is compiled, the script's source file is read only on startup. It is never read after that. The program's executable (AutoHotkey.exe or a compiled script) may need to be read from the source media at some point (perhaps only if it gets pushed out of physical RAM), but that wouldn't explain your issue.

What happens if you add #Hotstring NoMouse to your example script?

Windows asks me to submit the error to them

What error? The details you have given are useless. They are only file paths of files that we don't have (and probably wouldn't be useful if we had them). Errors of the kind that can be submitted are usually program crashes ("xx has stopped working"), where the program terminates. Windows would never detect that your mouse is choppy and offer to report it.

We once reproduced the issue by running a script from a remote drive, then deleting the file. We were unable to reproduce it again this way (with a single attempt.)

It sounds like a complete coincidence.

Trying to run the script from the server could be the cause of this intermittent issue.

You should be able to easily rule out that as the cause: don't run the script from the server.

[Cedo]

Unless the script is compiled, the script's source file is read only on startup. It is never read after that. The program's executable (AutoHotkey.exe or a compiled script) may need to be read from the source media at some point (perhaps only if it gets pushed out of physical RAM), but that wouldn't explain your issue.

The scripts I'm using are all compiled, but back when I used the installed AHK, I never had this issue.

What happens if you add #Hotstring NoMouse to your example script?

I must try this!

Windows asks me to submit the error to them

What error? The details you have given are useless. They are only file paths of files that we don't have (and probably wouldn't be useful if we had them). Errors of the kind that can be submitted are usually program crashes ("xx has stopped working"), where the program terminates. Windows would never detect that your mouse is choppy and offer to report it.

I believe it says that the program myscriptname.exe has stopped. It didn't seem informative to me but it seems I overlooked that. I'll catch it next time to make sure that's what it says.

We once reproduced the issue by running a script from a remote drive, then deleting the file. We were unable to reproduce it again this way (with a single attempt.)

It sounds like a complete coincidence.

Trying to run the script from the server could be the cause of this intermittent issue.

You should be able to easily rule out that as the cause: don't run the script from the server.

The issue I'm having with running it locally is that my workstation's C:\ drive is not local, somehow. The whole desktop is run remotely. I didn't think that it was possible, but someone in Information Security explained to me that's how it works so I just go with that. I think of it as a kind of telecommuting while in the office.

[lexikos]

The scripts I'm using are all compiled, but back when I used the installed AHK, I never had this issue.

So why are you compiling?

You don't need to install AutoHotkey to use it.

The whole desktop is run remotely.

Do the terms "terminal server", "thin client" or "Citrix" ring any bells?

The important point is that the file is stored on the same system which is running the software. In your case, that system is likely on a server elsewhere on the network (which you view and control remotely), and C:\ drive is likely local to that system. In other words, the processes running on that system can access the drive directly, not through the network.

[Cedo]

The only issue I have with running without installing is, I'm not sure how. I read the whole section and nothing jumps out to me as both immediately understandable and actionable. Do you just drag and drop the .ahk file onto the autohotkey.exe?

EDIT: I felt lame asking the above when I could just test it. I wanted to ensure that the issue was addressed on the forums for the purpose of sharing.
**I just tested it and it does work when you drag and drop! Cool!

[lexikos]

You can also just run the AutoHotkey.exe (renamed or not), as per the link I posted.

Or you can pass the script path on the command line, as shown on that same page.