A Case Study: Supreme Commander

As we stated earlier, the inspiration behind this article is Supreme Commander, which was crashing during gameplay due to what we discovered to be was the game exhausting its user space. Without taking extreme and convoluted measures, most applications can do little besides (gracefully) crash when they've exhausted their user space. Server applications, which on the whole tend to be the king of memory hogs in the first place, tend to have some sort of compensation mechanism, but for more generalized applications like games this is not the case.

In this case, Supreme Commander was crashing late in to big games on a system that otherwise is completely stable. No amount of testing could come up with a problem outside of Supreme Commander, and most telltale of all was that it was only a problem with large maps with large number of players with high quality settings; turning anything down made the crashing stop. Although not clearly a memory error it greatly reduces the list of possible problems to a few things. The entire process, we suspect, will be similar for everyone hitting the 2GB barrier: the affected application is crashing under heavy load. Thankfully the problem is possible to debug, albeit with moderate difficulty.

With all of that said, I did not come up with the diagnosis or the solution myself and while the problem in retrospect is quite obvious, at the time I did not even take the 2GB barrier in to consideration. As such, credit for the diagnosis and solution belongs to MadBoris of the Gas Powered Games forums who identified Supreme Commander as hitting the 2GB barrier and publishing a solution for it, which we will cover here.

Getting to the root of the problem requires additional tools beyond what comes with Windows XP or Vista. The task manger, the logical tool for this task, doesn't track the information we need to know. At best, the task manager can list how much data is in the various memory pools altogether, however this is not the metric we're looking for. What we actually need to know is how much of the application's share of the virtual address space has been allocated (the fundamental problem after all is when we run out of unused virtual address space to allocate) which due to a multitude of reasons can be much greater than the amount of memory in use by an application. For finding this we'll need Sysinternals' Process Explorer.

The above screenshot was taken as this paragraph was written, showcasing several different memory values for the running processes. The WS Private (Working Set Private) column lists how much physical memory the application is using, and this is the same column listed by the Windows Task Manager for memory usage. The Private Bytes column is the total amount of memory the application is using. Last but not least however is the Virtual Size column, which finally lists the amount of virtual address space allocated, the metric we're after.

We'll quickly focus on Microsoft Word as an example of the discrepancy between physical memory usage and private size. While Word is only using 17MB of physical memory, its virtual size is 170MB, 10 times the physical memory usage and 9 times the total memory usage. This is more or less a worse case scenario but it also points out just how misleading any memory usage - physical or total - is when trying to diagnose this kind of problem. Applications or games with high memory usage tend to not have nearly as a severe spread, but as we can see it's possible for an application to hit the 2GB barrier well before it needs 2GB of physical memory.

Getting to the meat of things however, the process readout for Supreme Commander basically says everything that needs to be said. In order to prove an exaggerated point, we started a 6 player game with 5 AI units on a maximum size map (81km x 81km) and set the game speed to maximum with maximum quality settings, while patching Supreme Commander and adjusting our system configuration to break the 2GB barrier. This actually isn't very playable for a variety of reasons (we'll overtax the CPU quickly due to all the AI units, slowing the game down dramatically) but represents not only what can happen in bad situations, but also is something that happens even in more manageable situations on smaller maps later in to the game.

Just at the start of the game, our virtual size was already in excess of 1.6GB, dangerously close to the 2GB barrier. 16 minutes in to the game, we have already hit a virtual size of 2.2GB, meaning had we not broken the 2GB barrier the game would have already crashed. At this point our total memory usage (private bytes) is only at 1.7GB, with 1.4GB of that in physical memory, nearly maximizing the RAM usage of our 2GB system. Our spread between memory usage and virtual size is .5GB, showcasing how deceptive memory usage is in identifying 2GB barrier issues.

Finally at 22 minutes in to the game, the game crashes as the virtual size has reached the 2.6GB barrier we have reconfigured this system for. Perhaps the most troubling thing at this point is that Supreme Commander is not aware that it ran out of user space in its virtual address pool, as we are kicked out of the game with a generic error message. Unfortunately Windows Vista reverted to a non-accelerated desktop at this point, preventing us from capturing a screenshot of the exact memory readouts or the error message.

Removing the 2GB Barrier A Case Study, Cont
POST A COMMENT

69 Comments

View All Comments

  • nullpointerus - Thursday, July 12, 2007 - link

    64bit versions of Windows(i.e. XP and Vista) do not suffer from the traditional 2GB barrier, as all the kernel mode addressing is usually moved to well above the confines of the limited 32bit addressing area. As such, these versions of Windows don't need to have their space allocations adjusted for an application to gain access to more addressing space, bypassing the instability and any possible performance problems that occurs as a result of making this adjustment.

    I used 64-bit Vista for a while but just couldn't deal with the BSOD's and other wierd behavior that would happen with 4 GB RAM installed and the BIOS memory hole option set. For example, the nVidia SATA drivers (3 updates on Windows Update alone) for my board would BSOD on every boot when the BIOS memory hole option was enabled, and the PVR-150's driver would randomly corrupt itself and turn into a green/garbled slideshow:

    http://www.hauppauge.co.uk/board/showthread.php?t=...">http://www.hauppauge.co.uk/board/showthread.php?t=...

    I wish the 64-bit driver developers would get off their butts and fix this stuff.
    Reply
  • gersson - Thursday, July 12, 2007 - link

    Large Address Aware Status

    it says, "STALKER: Oblivion Lost"
    Reply
  • Ryan Smith - Thursday, July 12, 2007 - link

    I'm not sure I see what the problem is. Could you go in to more detail? Reply
  • gersson - Thursday, July 12, 2007 - link

    You meant to place 'Stalker' cos there is already an entry for oblivion and 'lost' (I assume you mean 'lost planet')
    Read like this:

    Observe first line:

    STALKER: Oblivion Lost Yes
    Lost Planet No
    Company of Heroes Yes
    Supreme Commander No
    Enemy Territory: Quake Wars Yes
    Battlefield 2142 No
    Call of Juarez DX10 BM No
    World of Warcraft No
    The Elder Scrolls IV: Oblivion No
    Photoshop CS3 Yes
    Dreamweaver CS3 No
    Reply
  • DigitalFreak - Thursday, July 12, 2007 - link

    No. Stalker had the working title of Stalker: Oblivion Lost... Reply
  • gersson - Thursday, July 12, 2007 - link

    hmm ok, didn't know that -- but you can see how I had arrived @ my conclusion :-P Reply
  • The Boston Dangler - Thursday, July 12, 2007 - link

    the game was released as STALKER: Shadow of Chernobyl. no biggie Reply
  • Ryan Smith - Thursday, July 12, 2007 - link

    Fixed. I keep forgetting they changed the name. Reply
  • grant2 - Thursday, July 12, 2007 - link

    So this game will crash reproducably when using a large map, with many players, and many units.

    And GPG released it like this? Either their QA department is rather incompetent, or management were buffoons to ignore such an obvious error.

    Very disapointing!
    Reply
  • EODetroit - Thursday, July 12, 2007 - link

    I've been hoping Anandtech would take memory issues more seriously for a while now, glad you're getting your teeth into it for real now!

    "Unfortunately Windows Vista reverted to a non-accelerated desktop at this point, preventing us from capturing a screenshot of the exact memory readouts or the error message."

    Use a camera!
    Reply

Log in

Don't have an account? Sign up now