Run Auto Hot Key issues

I’ve got several bots all attempting to run the same script that utilizes a call to the UiPath.Script.Activities.AutoHotKey.RunAutoHotKeyScript activity (Studio version 2016.16137). On some bots, the AHK script runs just fine. On others, I get syntax errors. The AHK script is hosted on a networked location, so I know all bots are calling the same version of the AHK script.

I checked each bot’s version of the AutoHotKey.dll (which gets installed to .{User}\AppData\Local\Temp) and found that there were several different versions of the DLL present on the various bots. Even more interestingly, the .DLLs have different modify dates. All bots were built off the same Windows image and all bots have the same version of UiPath Studio.

  1. What in UiPath studio installs the AutoHotKey.dll? None of these bots have it in the image and it was not installed manually as a standalone program.

  2. Is UiPath modifying the AutoHotKey.dll? Not sure what else would be causing version differences.

  3. Which dll is actually used? Each bot has different versions of AutoHotKey.Interop.dll. Some bots also have a AutoHotKey.dll (not an interop, but is inside the AutoHotkey.Interop folder inside of .{User}\AppData\Local\Temp).

  4. What can I do to ensure each bot is using the same verison of the correct AutoHotKey.dll?

Can you please check if {User} contains the spaces in between the names
might cause an issue. Compare the user names/path in the working machines and non working machcines

1 Like

No part of the path, including {User}, contains spaces.

In both the machines ie working and non working machines

Correct. Working and non-working do not have spaces in the path.

So if you remove the space than will this work fine for you

There are no spaces to remove. . .

Ok got it

For those interested, there is a pseudo-workaround. You can delete the .{User}\AppData\Local\Temp\nuget folder when AHK is throwing errors (studio must not be open when you delete this folder). The next run, AHK will work until it self-corrupts once again.

I’ve also been testing on a newer Studo version (2016.2.6274) and haven’t run across the same issue yet. However, this might be obfuscated by the slight changes to the rest of the script I’ve had to make, as I’ve had less overall up-time since upgrading.

1 Like