AutoHotkey installation hangs

[PietBlaBla]

i'm new to Autohotkey and trying -for the first time- to install latest version "AutoHotkey112305_Install.exe" downloaded from official site (3.010 KB)

1. starting the EXE as limited user, installation program reacts oke and notice this, but hangs completely
2. starting the EXE as administrator, it starts but the process hangs also for minutes with a completely white window (no msgs / info or anything)

Environment: Windows7-X64 up-to-date
No relevant events in System or Apps log
TotalInstall tracing of installation: no single action on registry / files occurred.
No virus warning by Windows defender
No internet access noted by firewall

HOW TO DEBUG THIS ????

(Note: portable version works normal)

[Asmodeus]

try this:
1. re-download, check MD-5 for 1.1.23.05 is 74FDBAF763D4B30C87DBE566C257095B then re-install in different folder (make sure to not select %ProgramFiles%),
2. turn off UAC, antivirus, firewall, any other security software (try this while offline to avoid any infection) then do as described in # 1
3. create a new windows test user (admin) then do as described in # 1
4. install process monitor then monitor the installation
5. install a debugger then troubleshoot application hang reason

work-around:
if nothing above helped, install ahk in a VM, monitor changes done in registry and apply them locally afterwards

[PietBlaBla]

thanks Asmodeus for the reply; in the mean time

1. checked MD5 oke.
2. install on WinXP oke
3. first larger scipt written (noticed first unexpected effect: a "text-parameter with an included space" in a function call must be given between quotes.
4. sometimes a "{" in the body of a function call is not handled correctly (i.e. not expected) but recoded my first script (batch filling forms on internet / downloading, renaming download)

Will check / debug the install script that i noticed on WinXP; setup-exe unpacked on Win7-x64 with 7Zip thus now a directory with complete install package available. Called from the unpacked install-package the real SETUP.EXE file and again: no single file-system or registry modification; i.e. hangs immediately. Will report later back.

Made a Sysinternal procmon trace until the setup hangs: http://home.concepts.nl/~oo14194/Downlo ... pTrace.PML The setup process really hangs without anything doing to its environment. Looks like that the setup is searching in HKCU and HKCR\Protocols\Handler\res\CLSID and can't find anything as well as HKCU\Software\Classes\Ptotocols\Handler\res.

Don't know what protocol handler is needed by AHK setup.

[Guest]

thanks Asmodeus for the reply; in the mean time

Made a Sysinternal procmon trace until the setup hangs: http://home.concepts.nl/~oo14194/Downlo ... pTrace.PML The setup process really hangs without anything doing to its environment.

Looks like that the setup is searching in HKCU and HKCR\Protocols\Handler\res\CLSID and can't find anything
as well as HKCU\Software\Classes\Ptotocols\Handler\res.

Don't know what protocol handler is needed by AHK setup.

[lexikos]

Please download and try v1.1.23.06. I have added some checks that might detect the GUI failure and offer alternatives.

Also see the new FAQ: What can I do if AutoHotkey won't install?

Looks like that the setup is searching in HKCU and HKCR\Protocols\Handler\res\CLSID and can't find anything as well as HKCU\Software\Classes\Ptotocols\Handler\res.

That's interesting. AutoHotkey setup doesn't use the res:// protocol at all, but it is used by the Web Browser control to display error pages, such as if it is unable to load a page. It shouldn't be showing any such error page, but it may if there is something wrong with the Web Browser control (or Internet Explorer, or related policies) on your system. (It's also possible that the WebBrowser control normally accesses the res:// protocol when loading the about:blank page which is used by the installer; I've never monitored it, so I don't know.) The res protocol is defined in HKLM, so I suppose it is not surprising that it wasn't found in HKCU. It is probably standard procedure for the system to look in HKCU before HKLM for any protocol.

If the GUI isn't working, the simplest solution is to bypass the GUI as described in the FAQ.

[PietBlaBla]

Dear Lexicos:

thanks; i tried to install the latest version v1.1.23.06 and the following occurred:

1. received (after 2 seconds unpacking delay or so) the window "setup is in trouble shooting mode, ...." without pressing the control or shift button (as recommended in the FAQ)
2. clicked the YES-button and NO further info msg on installation result, but

AUTOHOTKEY was installed with all changes to the registry (context to Run / Compile / Edit script, new script file) but ONLY for user administrator; NOT FOR ALL USERS. Thus: at least considerable progress with this new version.

How to assist you in further debug what is going wrong? Make a procmon trace again, or analyse the install-script (quite some work for a newbee)??


Think the following is relevant to the problem with PROTOCOLS -after verification of the install-script with IE-access:
HKCR/PROTOCOLS/HANDLER/ with entries /RES, /ABOUT, /MAILTO all have no CLSID. However, on my system, under the entry HKCR/PROTOCOLS/HANDLER/AUTORUNSDISABLED they are stored with their CLSID, thus somehow -may be years ago- these protocol handlers were disabled by ....? and are blocking normal AHK-installation.

Edit: found that these protocols were disabled with Sysinternals Autorun/Explorer tab! Thus to prove impact, i've to uninstall AHK, change Aútoruns and reinstall AHK. Will come back.

[lexikos]

Dear Lexicos:

No.

1. received (after 2 seconds unpacking delay or so) the window "setup is in trouble shooting mode, ...." without pressing the control or shift button (as recommended in the FAQ)

That is likely because I added a 2 second timeout to the code which waits for the WebBrowser control to load. I suppose it means that after we call wb.Navigate("about:blank"), the control is not entering ReadyState 4 (document loaded and ready for us to inject our content).

AUTOHOTKEY was installed with all changes to the registry (context to Run / Compile / Edit script, new script file) but ONLY for user administrator; NOT FOR ALL USERS.

That's unlikely. Setup registers the file type only in HKLM. If it is not working for another user, that user probably has some registry association for .ahk files already present, overriding the system-wide registration. I would suggest running the .reg file I posted here for each user who is missing the context menu options, and restarting the computer. If HKEY_CURRENT_USER\Software\Classes\.ahk exists it should also be deleted, but the UserChoice key (see the link) is much more common on Vista and later.

Think the following is relevant to the problem with PROTOCOLS -after verification of the install-script with IE-access:
HKCR/PROTOCOLS/HANDLER/ with entries /RES, /ABOUT, /MAILTO all have no CLSID.

That is likely to be the cause. Without the about: protocol, we can't load about:blank. We could still load a .htm file (if the file: protocol is present), but that would require writing the HTML content from Installer.ahk into a temporary file.