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

Installer does not respect 'Start with Windows' setting #120

Closed
NomDeMorte opened this issue Nov 18, 2019 · 2 comments
Closed

Installer does not respect 'Start with Windows' setting #120

NomDeMorte opened this issue Nov 18, 2019 · 2 comments
Labels

Comments

@NomDeMorte
Copy link

NomDeMorte commented Nov 18, 2019

If I set the 'Start with Windows' option off, then install a new version, the installer always creates a new startup option.

The UI will still show that the option is off, when it is in fact on.

Since I have the startup entry, but it is disabled via task manager's 'Start-up' tab, This also means I can have a startup setting that is disabled, but enabled, but disabled, but enabled, but disabled. LOL. To be clear:

Disabled in the application settings
Enabled by recreating the entry with the installer
Still disabled in the application UI and settings file
Enabled as in the entry exists in task manager
Disabled as in that entry is disabled

Fun! hahaha

Perhaps the best way to handle this, would be to check when the app starts, that the appropriate startup setting is applied.

Either way it is set, there is the chance that it could behave opposite to the setting, if it is reinstalled/updated, and then rebooted - the only way I can imagine around that, would be to have the installer parse existing settings files, which sounds overly complex for a corner case.

Although, there's also Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run perhaps if you wanted to use the approach of disabling the startup entry (as I do manually) rather than removing it?
That way, when the installer creates the startup entry, it remains disabled as previously set by the user, and the application can just manage that entry - although it should probably ensure that the entry there, and in the settings file, match up, when the app starts.

The user has perms to that key, I'm unsure if there's an API to use it, but searching around I see a lot of people saying that setting it to anything other than 02 00 00 00 00 00 00 00 00 00 00 00 seems to disable it. There's some more info here suggesting that the strange numbers there are filetimes, I can't find any official docs at a first glance.

Observing the behaviour, it appears that whenever I enable and then re-disabled it, that timestamp changes, so I'm pretty sure that it's actually using the current time when it is disabled.

I've also found evidence of numbers other than 02 00.... enabling, and other than 03 00 .... disabling. Since this is a binary value, it got me to thinking bitwise, and I noticed I can change anything with a 02 to any other even number, and it will appear as enabled, and any odd number and it will appear as disabled.

image

Additionally, I have observed that when disabling it via the UI, it adds 1 to the highest byte, and then appends the current timestamp to the lowest 8, eg:

image

And then disabling it likewise subtracts 1 from the highest byte and clears the lowest 8 bytes.
The 2nd, 3rd, and 4th highest bytes are always 0.

Hopefully you know of an API to change this behaviour officially, but I imagine that's enough for you to get it working if you would like to. It would probably be more elegant than modding the installer and less messy for the user in that corner case, but certainly looks annoying for you to make :( Gotta love undocumented regkeys.

Edit: where I say "highest" byte here, I mean the one on the left.... Looking at it, perhaps the UI actually shows the least significant byte on the left, and when I say "highest" I should be saying "lowest" and vice versa... Not sure. Who would show them LSB-first in a left-to-right language? Oh wait, it's Microsoft ;)

@Tyrrrz Tyrrrz added the bug label Nov 19, 2019
@NomDeMorte
Copy link
Author

I noticed the new build and went to try it. The installer isn't creating the startup entry any more, it can be created and removed from the UI, and when it is, it retains any settings previously applied in task manager. Reinstalling over the top continues to use the existing settings and the existing startup entry remains. So that's all good!

I noticed that the application is installed to \Program Files (x86) and I think this has actually been happening since the 16th. If an existing installation is in place, the installer automatically installs to that location. I only noticed it today when I uninstalled intending to remove the settings file to clear the whitelisting for explorer (removing it using the UI does not work, but that's no issue, it can only get there by editing the config file or using the test version as I had).

Removing the settings with the uninstaller failed, which creates a failure mode here where the user uninstalls, the settings remain, the app can be reinstalled, and the app settings will say it's set to startup but there will be no startup entry. There is another issue (closed with the patch) related to the settings uninstall, so I will continue that there. Otherwise....

I think this issue is solved :)

@Tyrrrz
Copy link
Owner

Tyrrrz commented Nov 20, 2019

Great :)

@Tyrrrz Tyrrrz closed this as completed Nov 20, 2019
@Tyrrrz Tyrrrz changed the title Installer does not respect 'Start with Windows' setting. Installer does not respect 'Start with Windows' setting Dec 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants