AutoActions
AutoActions copied to clipboard
Not starting with windows
Describe the bug Will not start with windows, despite "Auto-Start" checked.
To Reproduce Check "Auto-Start". Reboot windows.
Expected behavior Auto Start should start with windows. It does show in task manager under "startup".
Desktop (please complete the following information): Win 11
V 1.9.18
Could you send me a log file?
I installed AutoActions today and had this problem. It was shown in Task Manager as a Startup task but did not start with windows. The problem is a windows permission issue.
I had initially placed AutoActions into subfolder below "\program files". That folder inherited default permissions from \program files, which means a normal user security context requires elevation to create/write files there (such as the settings and log files). If manually "run as administrator", it works fine. If launched without administrator permissions, it runs but cannot save settings or write logs. Adding "run as administrator" to the exe properties works interactively (an elevation prompt is displayed) but fails when launched via the AutoStart option's registry entry (hkcu\software\microsoft\windows\currentversion\run\AutoActions) because this launch mechanism does not support the "run as administrator" property.
There are some solutions USERS can take to fix this with the program as it is:
- Don't place the AutoActions folder under "\program files". Place it somewhere the user has full control permissions (i.e, within user profile); or
- If the AutoActions folder is placed under "\program files" (or another location where user needs elevation), override the folder permissions to explicitly add the user with "full control"; or
- Open Task Scheduler, create a task that runs at "logon of any user", runs with "highest privilege", and make sure the user(s) who need AutoActions have administrator rights. The "Auto-Start" setting within AutoActions becomes irrelevant as the program will be started from the scheduled task regardless of the program's setting. NOTE: All the above actions dilute the windows security model, as the user context has ability to change all AutoAction executables and dlls. The third option is the least damaging to security of these three, since only the process started with Admin rights from sched tasks has those rights.
Better solutions, if someone has time to do some coding and submit a pull request:
- The Auto-Start option could be implemented as a scheduled task instead of a registry "run" entry, and set to run with "highest privilege". This still dilutes security, requires users to be in the administrator group, and would require elevation to create the scheduled task; OR
- Preferred solution: The program should place any files it writes (log file, settings file, etc) in a user profile space (i.e., "my documents"). It can then start as a normal user process via the existing registry "run" mechanism, while the updater would need to request elevation (user prompt).