Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not starting with windows #101

Closed
Litcube opened this issue Feb 6, 2022 · 2 comments
Closed

Not starting with windows #101

Litcube opened this issue Feb 6, 2022 · 2 comments

Comments

@Litcube
Copy link

Litcube commented Feb 6, 2022

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

@Codectory
Copy link
Owner

Could you send me a log file?

@xsilas43 xsilas43 mentioned this issue Jun 15, 2022
@ScottWell1
Copy link

ScottWell1 commented Sep 4, 2022

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:

  1. Don't place the AutoActions folder under "\program files". Place it somewhere the user has full control permissions (i.e, within user profile); or
  2. 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
  3. 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:

  1. 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
  2. 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).

@Codectory Codectory closed this as not planned Won't fix, can't repro, duplicate, stale Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants