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_…

Working with Xmpp in Python

Xmpp is an open standard for messaging and presence, used for instant messaging systems. It is also used for chat systems in several games, most notably League of Legends made by Riot Games.

Xmpp is an xml based protocol. Normally you work with xml documents - with Xmpp you work with a stream of xml elements, or stanzas - see for the full definitions of these concepts. This has some implications on how best to work with the xml.

To experiment with Xmpp, let's start by installing a chat server based on Xmpp and start interacting with it. For my purposes I've chosen Prosody - it's nice and simple to install, especially on macOS with Homebrew:

brew tap prosody/prosody
brew install prosody

Start the server with prosodyctl - you may need to edit the configuration file (/usr/local/etc/prosody/prosody.cfg.lua on the Mac), adding entries for prosody_user and pidfile. Once the server is up and running we can start poking at it to get a feel for h…

Expiring records in Erlang

I'm continuing my experiments with Erlang - this time trying out gen_server with a simple key/value store with a twist - the values have an expiration date. As a first iteration I'm simply using a dictionary to store the values, and only expiring records when they are looked up. My plan is to extend this later on so that this can be a global key/value store across multiple Erlang nodes but for now I'm focusing on two things - get something going using gen_server, and try out the common_test testing framework. The code is here: Let's first take a look at a couple of the test functions, to show the usage of this: get_non_expired_record(Config) ->Pid=?config(pid, Config), Record= {"bingo", "bongo", erlang:system_time(second) +3600}, ok=gen_server:call(Pid, {add, Record}), {ok, "bongo"} =gen_server:call(Pid, {fetch, "bingo"}). get_expired_record(Config) ->Pid=…