The EVE launcher has an auto update feature - when it detects that a newer version has been deployed, it downloads any changed files and updates itself. The launcher executable can't overwrite the itself or the DLLs loaded so it uses a separate updater. After downloading, the launcher starts the updater and shuts itself down, then the updater replaces the launcher files and restarts the launcher.
If the launcher is installed in Program Files, a protected folder, the launcher has to run the updater as an elevated process. Otherwise the updater will not able to overwrite any changed files in the launcher.
This got me thinking, and I looked over the code in the updater. It certainly wasn't doing anything to elevate the launcher process it started. It was simply calling ShellExecute with nullptr for the verb, meaning use the default action. I had foolishly assumed that would always run the process normally, that is, not elevated. Well, it did, it just runs the process in the current context - if the launcher elevated the updater, then the updater would run the launcher elevated as well. Turns out I have to do something to go back to the regular user.
Of course I'm not the first programmer to run into this issue. No matter what problem you're facing, it seems that somebody else has faced it before, so after a bit of Googling I found a blog that covers this exact issue - how to launch an unelevated process from an elevated process.
Now I finally have an explanation for this issue. It needs a rather specific series of events so we've never been able to reproduce this on demand - those events are not that unlikely, but things still have to line up the right way:
If the launcher is installed in Program Files, a protected folder, the launcher has to run the updater as an elevated process. Otherwise the updater will not able to overwrite any changed files in the launcher.
Going up?
At EVE Fanfest we had a roundtable where my team met with players to discuss the things we're working on - the launcher and Wine support. One player mentioned that he had noticed that the launcher would sometimes run in elevated mode, and asked me if it was possible that the update process was the reason.This got me thinking, and I looked over the code in the updater. It certainly wasn't doing anything to elevate the launcher process it started. It was simply calling ShellExecute with nullptr for the verb, meaning use the default action. I had foolishly assumed that would always run the process normally, that is, not elevated. Well, it did, it just runs the process in the current context - if the launcher elevated the updater, then the updater would run the launcher elevated as well. Turns out I have to do something to go back to the regular user.
The elevator only goes up!
Running an elevated process from a regular process is simple enough - you call ShellExecute with runas for the verb. When that runs, Windows prompts you for permission to elevate that process (unless you've turned that off for your system). If the current user does not have administrator privileges, you have to enter the user name and password for an administrator. This implies that the elevated process is not necessarily running as the user that ran the regular process. This also explains why ShellExecute has no verb for un-elevating - it is more complicated to go down than up. You have to know where you came from.Of course I'm not the first programmer to run into this issue. No matter what problem you're facing, it seems that somebody else has faced it before, so after a bit of Googling I found a blog that covers this exact issue - how to launch an unelevated process from an elevated process.
Explorer to the rescue!
The approach is basically to get a third party to help - use the Explorer to launch the process. The Explorer runs as a regular process, so processes it launches will be regular processes. I'm not going to go into details of how to do this - read that other blog for those.There's your problem!
I've heard sporadic reports from players where the launcher fails to update the EVE client and the symptoms were consistent with problems with permissions. The launcher downloads the client files to a cache, then copies the files for a given client version to a staging folder. For some reason the files in the staging folder could not be overwritten, even though the staging folder ought to have proper permissions as it was created by the launcher and all files in there written by the launcher.Now I finally have an explanation for this issue. It needs a rather specific series of events so we've never been able to reproduce this on demand - those events are not that unlikely, but things still have to line up the right way:
- The launcher has to be installed in Program Files (a protected folder, causing the updater to run elevated).
- The launcher updates itself, coming back from the update in elevated mode.
- The launcher updates the client in that elevated session.
- Close the launcher.
- Restart the launcher normally, without it updating itself.
- The launcher will now fail to update the client.
For a while we had fairly frequent updates to the launcher, masking this issue as players would often be running the launcher elevated. The issue only rears its head when the launcher is started normally.
Sometimes you will find connections in the weirdest places...
Comments
Post a Comment