Fix for AutoHotkey Not Working in Windows 10

[chazcon]

UAC rules have changed with Windows 10.

AutoHotkey scripts that worked fine in Windows 7 no longer work in Windows 10.

1) Find your AutoHotkey executable, typically here: C:\Program Files\AutoHotkey\AutoHotkey.exe

2) Right-click on AutoHotkey.exe

3) Select the Compatibility tab

4) Enable Run this program as Administrator

5) Click OK

Note you have to do this even though you are running as an Administrator.

This caused me to go back to Windows 7 until I could figure it out. Gamer, I need my scripts! Very frustrating. Hope this helps others.

[lexikos]

No, the UAC rules changed with Windows 8. In Windows 8.1 and 10 the rules remain the same as in Windows 8.

If UAC is enabled in any version of Windows, most programs do not run as administrator by default, even if you are an administrator. That is basically the purpose of UAC. Your instructions would apply to any system with UAC enabled. The difference between Vista/7 and 8/8.1/10 is that in the latter, the "Never notify me" setting in Control Panel doesn't actually disable UAC, just the Yes/No prompts.

I would generally not recommend running every script (or program) as administrator. Any programs that the script launches will also run as administrator. If you just need to automate windows of programs running as admin, you can use EnableUIAccess instead.

[chazcon]

This is incorrect. Even with UAC off you need to run AutoHotkey as an administrator.

If there's another method, let's hear it.

[lexikos]

Right back at you. You are incorrect. If you have any facts to back up your claims, let's hear them.

1. AutoHotkey does not need to be run as administrator. I frequently run it as a limited user. By default it can only automate windows which are not running as administrator (due to security restrictions), but if you use EnableUIAccess as I said, it can automate any window even while running as a limited user. Specific scripts might still need to be run as administrator, such as if they write to the Program Files directory; but the majority of scripts do not.
2. If UAC is disabled and the current user is an administrator, every program run by that user gets administrative privileges.
   
   On Windows Vista at least, you can't even turn on the option if UAC is disabled. If you temporarily disable UAC, turn on the option and re-enable UAC, there will be a tick in the box but the box itself will be disabled and the setting will have no effect. Even "Run as administrator" from the context menu just runs the script normally - without admin if the user isn't an admin.
   
   If you are using Windows 8 or later, it is very unlikely that you have UAC disabled. On Windows 8 and later, UAC can only be disabled by modifying the registry, and doing so breaks apps. As I said, "turning off" UAC in Control Panel on Windows 8 and later just suppresses the Yes/No prompts; programs are still run with limited privileges by default.
   
   Supposedly turning off "admin approval mode" has a similar effect to disabling UAC, but I haven't tried it and wouldn't recommend it either.

[Opensecret]

Apologies for bringing this thread back from the dead, but it just solved a problem for me.

I’ve started using Sticky Password as a password manager, and I mostly like it. But whenever I was in it (in Win10), my keyboard reverted to the standard layout, ignoring my AHK script. I hadn't run into this problem in any other app. When I tried setting AHK to run as administrator, it seemed to solve the problem.

Thanks for the help.

[Scout_N6]

And so it shall be revived again...
I was receiving "ERROR" outputs from several of my scripts that relied on .ini files and other outputs that were being saved on a network folder. All of my scripts are saved and converted to .exe format, and were themselves saved to a similar network folder/location.
I've run them as administrator and in compatability mode with no success. I even copied them to the local machine with no change in any format (.ahk, .exe, Admin, Standard, Compatability, No Compat, etc.).
The fix I have found that is working so far is to move the files (ini, exe, everything) to the local machine, and change the file paths from a network location to the local location.

Old Script File Path Examples:
;Runs exe script for setting class controls to different ClassNNs
Run, "\\NetworkPath\Scripts\Programs\PgrmData.exe"

;Uses network .INI File to temporarily save data and send to CMD.EXE window to check domain account info. The %UID% vairable is being replaced with the above mentioned "ERROR"
IniRead, UID, U:\Pogrm.ini, UID_temp, UserID
winactivate, ahk_exe cmd.exe
winwaitactive, ahk_exe cmd.exe
Sleep, 150
WinMove, ahk_exe cmd.exe,,,,680,655
Sleep, 150
ControlSendRaw,,net user, ahk_exe cmd.exe
ControlSend,,{space}%UID%{space}, ahk_exe cmd.exe
ControlSendRaw,, /domain, ahk_exe cmd.exe
Sleep, 150
Send, {space down}{space up}
SendRaw, /active:yes
Sleep, 150
ControlSend,, {enter}, ahk_exe cmd.exe
Return

New Script File Paths:
Run, "C:\IT\scripts\3_exes\PgrmData.exe"
IniRead, DlyPass, C:\IT\scripts\4_ini_bat\Pogrm.ini, DLY_Pass, Password

I'm still running the new script as an .EXE in Compatability Mode (win7) as an Administrator.
Running a WIN10 PRO 64bit, Version 1903, OS Build 18362.329.

[MarcusK35]

This worked for me. Thanks!