Skip to main content

What goes up must come down

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.

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:

  1. The launcher has to be installed in Program Files (a protected folder, causing the updater to run elevated).
  2. The launcher updates itself, coming back from the update in elevated mode.
  3. The launcher updates the client in that elevated session.
  4. Close the launcher.
  5. Restart the launcher normally, without it updating itself.
  6. 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...

Popular posts from this blog

Mnesia queries

I've added search and trim to my expiring records module in Erlang. This started out as an in-memory key/value store, that I then migrated over to using Mnesia and eventually to a replicated Mnesia table. The fetch/1 function is already doing a simple query, with match_object. Result=mnesia:match_object(expiring_records, #record{key=Key, value='_', expires_at='_'}, read) The three parameters there are the name of the table - expiring_records, the matching pattern and the lock type (read lock). The fetch/1 function looks up the key as it was added to the table with store/3. If the key is a tuple, we can also do a partial match: Result=mnesia:match_object(expiring_records, #record{key= {'_', "bongo"}, value='_', expires_at='_'}, read) I've added a search/1 function the module that takes in a matching pattern and returns a list of items where the key matches the pattern. Here's the test for the search/1 function: search_partial_…

Replicated Mnesia

I'm still working on my expiring records module in Erlang (see here and here for my previous posts on this). Previously, I had started using Mnesia, but only a RAM based table. I've now switched it over to a replicated disc based table. That was easy enough, but it took a while to figure out how to do, nonetheless. I had assumed that simply adding ... {disc_copies, [node()]} ... to the arguments to mnesia:create_table would be enough. This resulted in an error: {app_test,init_per_testcase, {{badmatch, {aborted, {bad_type,expiring_records,disc_copies,nonode@nohost}}}, ... After some head-scratching and lots of Googling I realized that I was missing a call to mnesia:create_schema to allow it to create disc based tables. My tests for this module are done with common_test so I set up a per suite initialization function like this: init_per_suite(Config) ->mnesia:create_schema([node()]), mnesia:start(…

Waiting for an answer

I want to describe my first iteration of exsim, the core server for the large scale simulation I described in my last blog post. A Listener module opens a socket for listening to incoming connections. Once a connection is made, a process is spawned for handling the login and the listener continues listening for new connections. Once logged in, a Player is created, and a Solarsystem is started (if it hasn't already). The solar system also starts a PhysicsProxy, and the player starts a Ship. These are all GenServer processes. The source for this is up on GitHub: Player The player takes ownership of the TCP connection and handles communication with the game client (or bot). Incoming messages are parsed in handle_info/2 and handled by the player or routed to the ship, as appropriate. The player creates the ship in its init/1 function. The state for the player holds the ship and the name of the player. Ship The ship holds the state of the ship - …