It's a mystery. If all threads close gracefully and everything goes back to how it was before running the compiled script, reloading it should - theoretically - work just fine, as it worked before the reload. But it doesn't. In fact, I had a couple reloads without crash and then it started crashing. It's all apparently random, except for the addresses (instruction and memory) which are always the same for a given compiled script (or maybe for all builds of the script on a given machine).
I've had the very same compiled exe
crash consistently on reload in the work folder, while a copy of it, with the same additional files (.ini), placed in C:\Windows\Temp
reloaded many times without crash. Then I had the reverse, when another build of the script, after some small changes, would run fine on reload in the work folder and would crash on reload in Temp.
And then, the same script that worked fine in the work folder would crash on a 32bit Win7 machine.
Then, the very same script compiled on the Win7 machine with the very same AHK_H build 1.1.28.00-H003, when it reloaded correctly on Win7 would crash on reload in XP.
As you probably noticed, fellow robodesign
is having the same problem on an x64 Win10 machine with this script, where the 32bit build also crashes on reload. His build would crash on reload on my XP machine but would crash on start on the Win7 machine. He's been building with AutoHotkey.exe only, I tried both with the exe and the bin, and results were the same: random crashes on reload.
The script in question has a huge amount of keyboard and mouse hotkeys, timers, message hooks, four additional script threads, a serious amount of variables declared at start and then updated through ini file reads (and then IniWrites on exit, but not on straight reload), additional scripts and sound files included through compiler directives, a handful of files included through FileInstall, so it's quite hard to try and pinpoint any possible bug in it. But all this apart, running it uncompiled never crashes
- not on start, not on reload.
Actually I just realized the problem was put in the wrong way: it doesn't crash during the reload operation, but during the start, in the autoexec section (where threads are created), after reload.
And after today's tests, other weird thing happened: while using a couple OutputDebug commands and file creation (the thread scripts retrieved from resources), the compiled script never crashed upon a few reloads. After turning off the debug features, it started crashing again!
After more small changes I thought I nailed it: no crash either in work folder or Temp folder, for more than ten subsequent reloads in each folder. But then it started crashing again, even on start. Very same build at the very same instruction address and memory address as in the screenshot at the top. And now, after a couple minutes of not running it, it worked fine on three subsequent reloads.
I just can't make heads or tails of this situation, and the fact that the process can't be run through a debugger is a show stopper. That's why I asked you in a previous related topic for a compiler option to skip on demand anti-debugging features for the currently selected script, in order to try and solve this mystery.
There may also be a bad GDI leak related to relaunching (and crashing) of the compiled script too many times. Seconds ago I tried to get a file context menu and all I got was its shadow, then text only on hovering its apparent place. Something like that, in XP, should be very bad.
Fortunately I'm using Total Commander as file explorer so I could close and restart it; if it were Explorer the whole machine could've been brought to its knees.
Trying to #include <AhkThread> results in:
It only worked when AhkThread.ahk was placed in script's folder (or in its Lib subfolder, dunno exactly, put it in both places to be sure).
However, even without the #include, the main script still creates threads by calling ahkThread dynamically.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.