Bug Report (AHK.dll) Topic is solved

[Masonjar13]

Updating ScriptUp with some new features, so I made a sample script to test them out.

Code: Select all

#singleInstance force
#persistent
#include *i <Lib_1>

loop
    msgbox Test

I downloaded the newest version (1.1.28.00-H004), and I'm using the 64-bit version. Using ahkTerminate on the thread will crash the process. ahkReload works fine, as does ahkPause or anything else as far as I can tell. Trying to terminate while paused doesn't make a difference. The previous version I was using (1.1.26.01-H001) doesn't cause a crash, same script.

[HotKeyIt]

I can't reproduce it on Win 10 64-bit, in your script you are not using ahk.dll, can you provide a full example showing the problem?

[Masonjar13]

Right, it's a script that's being ran with ahk.dll. Specifically, I'm using ScriptUp, which you can download and add the above script to. That's exactly my use case. However, I don't use Win 10, so it may or may not be different.

[HotKeyIt]

What OS do you use?
Can you write down the steps you do to cause the crash?

[Masonjar13]

Windows 7
1. Open ScriptUp with _L v1.1.27.7 (updated to 1.1.28.0, still crashes) (64-bit)
2. In the ScriptUp GUI, press "Settings" > "Set DLL: Std" and select v1.1.28.00-H004 of ahk.dll (64-bit)
3. Save the script above (any infinite loop seems to work) and add it to ScriptUp by dragging it to the GUI. Set it to use the Std DLL.
4. Try closing ScriptUp (from tray menu).

This will 100% of the time crash for me. If I remove that particular script, perfectly fine. This is the only time ahkTerminate is called, so I can only presume this is the problem (I can't check exactly where it crashes).

[HotKeyIt]

Tried but it did not add the script to the list, when starting again I got this error:

There were errors while trying to run scripts:

DLL path not specified: Std

I believe the bug has been fixed in the last release, can you test it please: https://github.com/HotKeyIt/ahkdll-v1-r ... master.zip

[Masonjar13]

Hm, that's not an issue I've ever had (unless I purposely caused it). If you added the DLL then moved it, the path would be incorrect and cause that error. You can check %appdata%\..\Local\ScriptUp for the ini config file. Should be key "Std" under section "dlltypes." If the script didn't have privilege to write to there, that would also be a problem (though any scripts added would also be forgotten).

I've tested H008 and it seems to work perfectly fine! Fixed

[Drugwash]

@ Masonjar13: Around the same time, I tested your script and got the same error as HotkeyIt above. Can't remember exactly how I fixed it but I think both paths to standard DLL and mini DLL must be specified at first run, otherwise only specifying one of them will not hold, and scripts will not be added to the list.
You may wanna double-check that part of the script and maybe notify the user about the requirements.

[Masonjar13]

You may wanna double-check that part of the script and maybe notify the user about the requirements.

Thanks for the heads up. I checked the code again, and that isn't the case. I even manually removed the path to the mini DLL and restarted it. As expected, all scripts using the standard DLL were running, but the mini ones were not. When a DLL path is changed, it changes it both in the object and the ini file, so it can't be missed.

I see no errors in the code, but if you'd like to test it further, please let me know if you find anything

Thought: If it's W10, maybe it's a permissions issue? I could add an admin check.

[Drugwash]

I tested in XP where I am definitely admin, so that's not the issue.
There must be a niche situation where it's not behaving quite correctly, since it's at least two of us (HotkeyIt and myself) who experienced this issue.
Unfortunately I can't remember the exact steps to reproduce it. Maybe if you start from scratch with no ini file, try to add a script and run it, restart ScriptUp script when failed, try to set only Std DLL path, try to add and run a script again, restart ScriptUp, then change both DLL paths.
I couldn't even get it to add a script to the list, at first, before setting the DLL path, if I recall correctly.
Anyway, this issue is not related to AHK_H itself so we're not quite in the right place to discuss it. Just wanted to let you know HotkeyIt's report does have a plausible ground.