HKLM Run key doesn't seem to be triggering on W10 - but works on W7

Hello folks.

I could use a sanity check on this one. I've got an AutoIt EXE that I've built to accomplish a couple of simple tasks, and I need this to run when a user logs into the machine. So I've got the EXE tucked away at "C:\Windows\Temp\EXEname.exe"

I've got a registry value in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to launch the EXE. On Windows 7, this runs without an issue - on Windows 10, following a reboot the key doesn't seem to be triggered. There are no other Run or RunOnce keys in HKLM\SOFTWARE or HKLM\SOFTWARE\Wow6432Node.

A couple of things I've tried verifying

• The path in the registry value is correct - I can launch the EXE from this path manually
• The EXE is not being launched by Windows (verified through observance and use of procmon)
• I've tried manually granting full control on the C:\Windows\Temp to a user account for testing and then logging in with that user to verify it's not a permissions issue.

Any other ideas for troubleshooting, or any ideas on changes between W7 and W10?

dalchina said:

Hi, I note: C:\Users\-name-\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Thanks for the reply!

I need this to run for all users - so C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup would be a better option - however, I'm more concerned with determining why this key isn't firing off when it should, as opposed to finding another way to launch the EXE.

If you mean here:



The HKLM, "Software\Microsoft\Windows\CurrentVersion\Run(or RunOnce) definitely work under Windows 10. I in fact changed the authority to read only so Windows 10 would not be able to add (and then re-open) apps after a restart which is something I don't like.

If it isn't running make sure you are doing restart not shutdown. If that works then turn off fast startup and/or check authority on the keys.

It works the same as in 7 (or at least it should). Make sure your .exe isn't trying to run under admin privileges - that will not work (but I don't think it did in 7 either).

You just need an Elevated Shortcut in your startup folder.

Callender said:

You just need an Elevated Shortcut in your startup folder.

You could. Or you could schedule it through Task Scheduler. Depends what you want to do.

If the OP wants it to be for all users it would have to be %ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp
not %appdata%\Microsoft\Windows\Start Menu\Programs\StartUp though.

In any case, any of these methods will only work if your user is part of the Administrators group. You can't run Admin tasks for a standard user at logon or startup. The OP hasn't said if the exe requires admin rights and if the user is a standard or admin user although I read from "a simple task" "when a user logs on" it doesn't require admin rights and is for any user (not just a specific one).

In that case sticking a value "Whatever" with Value Data "C:\Temp\Whatever.exe" in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run should definitely work (it does for me).

The only issue I can think is the OP is using C:\Windows\Temp\Whatever.exe and perhaps C:\SomewhereElse\Whatever.exe would be better (i.e. not using the Windows directory). That is only a guess though but sticking an exe in a temp folder seems a bit weird as a long term solution as something like Disk Cleanup would presumably delete it eventually.

For clarification, this wasn't an issue of "we have no Run/RunOnce keys" or "none of our Run/RunOnce keys work" it was an issue with a specific Run key for an app that was developed in-house.

lx07 said:

If you mean here:
It works the same as in 7 (or at least it should). Make sure your .exe isn't trying to run under admin privileges - that will not work (but I don't think it did in 7 either).

I discovered this to be the issue before heading out for lunch today. We run a locked down image in our labs which has UAC disabled on W7. While we have neutered its ability to notify users on W10, we haven't fully disabled it. While we have it set to Never Notify, we don't want to break any of the Win10 apps, so we can't modify the EnableLUA registry value.

In this instance, the AutoIt EXE we crafted required admin rights to properly detect elements inside a software installer GUI. Since UAC was disabled on 7, it would elevate itself and run. On 10, we were running into UAC not displaying a notification (as our settings intended) but even though an Administrator was logging in, they weren't trying to run the program specified by the key as an Administrator.

After working out the cause of the issue we elected to go with a scheduled task that was configured to run the EXE with the highest level of permissions available when a user logs in. Almost all of our software is deployed during the initial rollout of a machine while an Administrator service account is logged in, so things are running smoothly. Well, as smoothly as they can when a software vendor decides to address HIPAA compliance issues by building a new version of their software that cannot be traditionally deployed.

lx07 said:

You could. Or you could schedule it through Task Scheduler. Depends what you want to do.
The only issue I can think is the OP is using C:\Windows\Temp\Whatever.exe and perhaps C:\SomewhereElse\Whatever.exe would be better (i.e. not using the Windows directory). That is only a guess though but sticking an exe in a temp folder seems a bit weird as a long term solution as something like Disk Cleanup would presumably delete it eventually.

As mentioned above, this EXE was built as a helper for deploying a PITA installer for software that can no longer be automated by command line switches, is on too many workstations for us to push manually, and for reasons chosen by the software developers cannot be recaptured (securely) into an MSI with a product like AdminStudio. We've got this helper self-deleting upon a successful completion, and as you've mentioned it would be cleaned up automatically as we run Disk Cleanup at the tail end of our machine rollout.

I know this is a reply to an old thread, but I'm adding this for future answer seekers.
I ended up solving this by adding an AppCompatFlag to the registry to get mine to work.

"HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "c:\folder\file.exe" /d "~RUNASADMIN"

This is in addition to the RunOnce key to get the installer to execute.

Hope this helps someone.