wiresock / WireSockUI

GUI to use Wiresock VPN Client in application mode
https://www.wiresock.net/
302 stars 14 forks source link

[Bug]: WireSockUI launches twice on Windows startup #46

Closed XFox111 closed 9 months ago

XFox111 commented 10 months ago

Description

I've noticed that after 0.2.1 update WireSockUI tries to launch twice during Windows Startup - first time it launches normally, the second time it raises UAC prompt and then terminates because there's an instance running already.

Reproduction steps

Note: Clean installation is probably required for this repro

  1. Install WireSockUI pre v0.2.1 (v0.2.13 or earlier)
  2. Go to settings
  3. Turn off option "Run when Windows starts" and save
  4. Turn it back on to make sure that startup entries are up to date
  5. Upgrade WireSockUI to the latest 0.2.1 version
  6. In settings again turn off "Run when Windows starts", save, turn it back on and save
  7. Restart PC and log in
  8. In ~15 seconds check that WireSockUI is in system tray and running
  9. After ~1 minute another instance should pop up and prompt for UAC (unless UAC is disabled)
  10. Click "Yes" or "No"
  11. A pop-up saying "there's another instance is running" should appear

Expected behavior

WireSockUI should start only once on Windows startup.

System info

WireSockUI version 0.2.1
Edition Windows 11 Pro
Version 23H2
Installed on ‎29-‎Sep-‎23
OS build 22631.3007
Experience Windows Feature Experience Pack 1000.22681.1000.0

Additional context

I believe that this is because v0.2.1 has migrated from a startup shortcut at C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup (which didn't really work on my machine) to a proper entry in Task Scheduler and the shortcut was never removed, causing it to launch first time via TS, and then via this startup shortcut. After manually removing the shortcut, the issue has been fixed.

wiresock commented 10 months ago

In version 0.2.1, WireSockUI is capable of operating both as an Administrator and as a non-Administrator. It can be configured to autostart in either mode, though the methods for setting this up differ. Consequently, there's a possibility that both autostart methods could be activated simultaneously. For instance, you might first run it as a non-administrator, enable autostart, exit, and then run it again as an administrator, enabling autostart once more. Both settings can be disabled following the same procedure used to enable them.

XFox111 commented 10 months ago

Ah, that makes sense. But it's still rather confusing though. It would be better to have some unified mechanism instead to prevent double startup. Or at least make them check for each other. Because this can lead to a bunch of different use cases where the issue can occur.

wiresock commented 10 months ago

When WireSockUI operates under a user account, it lacks access to the Task Manager, which restricts its control capabilities. However, by running it in Admin mode, where the necessary permissions are available, I can verify and, if needed, disable the autostart set up for the user account. I'll consider this approach further.

wiresock commented 9 months ago

Version 0.2.4 partially addressed an issue, but a small problem persists: WireSockUI might launch twice if autostart is initially enabled in Admin mode and subsequently in non-Admin mode. This occurs because, in non-Admin mode, the application lacks sufficient permissions to determine if a Task Scheduler task already exists.

XFox111 commented 9 months ago

Yeah, but I think it's a minor issue, since elevated version on launch will override startup entry of non-elevated one, and the next time it will do okay (unless non-admin instance will always launch first).

Though, there might be another approach: you can check for duplicate startup entries before checking if another instance is running. So, in that case, even there's another non-admin instance is running, the elevated instance at least will remove duplicate startup entry, resolving issue for the next startup.

wiresock commented 9 months ago

Starting with version 0.2.5, users will not have the ability to modify Autorun settings if they have been enabled by an Administrator. This change ensures that the Autorun configurations set by an Admin user remain secure and unaltered by other users.