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

Large scale ambitions

Learning new things is important for every developer. I've mentioned  this before, and in the spirit of doing just that, I've started a somewhat ambitious project. I want to do a large-scale simulation, using  Elixir  and Go , coupled with a physics simulation in C++. I've never done anything in Elixir before, and only played a little bit with Go, but I figure,  how hard can it be ? Exsim I've dubbed this project exsim - it's a simulation done in Elixir. Someday I'll think about a more catchy name - for now I'm just focusing on the technical bits. Here's an overview of the system as I see it today: exsim  sits at the heart of it - this is the main server, implemented in Elixir. exsim-physics  is the physics simulation. It is implemented in C++, using the Bullet physics library. exsim-physics-viewer  is a simple viewer for the state of the physics simulation, written in Go. exsim-bot  is a bot for testing exsim, written in Go.

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

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 wh