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

Optimizing Wine on OS X

I've been doing some performance analysis of EVE running under Wine on OS X. My main test cases are a series of scenes run with the EVE Probe - our internal benchmarking tool. This is far more convenient than running the full EVE client, as it focuses purely on the graphics performance and does not require any user input.

Wine Staging One thing I tried was to build Wine Staging. On its own, that did not really change anything. Turning on CSMT, on the other hand, made quite a difference, taking the average frame time down by 30% for the test scene I used. While the performance boost was significant there were also significant glitches in the rendering, with parts of the scene flickering in and out. Too bad - it means I can't consider this yet for EVE, but I will monitor the progress of this. OpenGL Profiler Apple has the very useful OpenGL profiler available for download. I tried running one of the simpler scenes under the profiler to capture statistics on the OpenGL calls mad…