Windows 10: 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?

:)

 

Dual boot W7 and W10 activation

I have been running a W7 Pro OS for some years now. I have three hard drives installed.

I created a seperate 25GB partition (H) on one of the spare hard drives that was not the C drive.

I installed W10 from a downloaded "setup" app from MS.

On turning on the PC I get the choice of what OS to run, W7 or W10.

W7 runs just as it used to.

W10 loads and opens as I would expect, but is apparently not activated. It will not accept the W7 Key, and I don't know how to obtain the W10 activation Key. I had assumed that as W7 is activated and associated with the same mother board, that would allow
me to use W10 fully activated as well. Can I activate W10 or must I puschase an activation key for W10 Pro, which seems to go against the MS offer of a free OS upgrade to holders of W7/8 licences.

Thanks for your help,

Regards

David D

 

WINDOWS 10 ACTIVATION WOES

Yes I've tried the original w7 key plus about 4 or 5 other w7 keys and three w10 keys

manual activation doesn't work it keeps coming up with error codes and saying unable to

reach activation servers

 

Hi, I note:

I have some entries there, but of course it depends what you have installed:




- but all that says is, well, surprise, they're used in Win 10 as you'd expect.

You could try putting a shortcut here:
C:\Users\-name-\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

or here

= any
C:\ProgramData\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.

 

Suggest you post a screenshot of your reg. key.

Is the entry still there after you reboot?

 

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.

 

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.

 

We'll know more if @FlatJackBob posts a screenshot- a bit more info.

 

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.

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.

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.