As we saw in part 1 of this series, large applications and games under Windows are getting incredibly close to hitting the 2GB barrier, the amount of virtual address space a traditional Win32 (32-bit) application can access. Once applications begin to hit these barriers, many of them will start acting up and/or crashing in unpredictable ways which makes resolving the problem even harder. Developers can work around these issues, but none of these except for building less resource intensive games or switching to 64-bit will properly solve the problem without creating other serious issues.

Furthermore, as we saw in part 2, games are consuming greater amounts of address space under Windows Vista than Windows XP. This makes Vista less suitable for use with games when at the same time it will be the version of Windows that will see the computing industry through the transition to 64-bit operating systems becoming the new standard. Microsoft knew about the problem, but up until now we were unable to get further details on what was going on and why. As of today that has changed.

Microsoft has published knowledge base article 940105 on the matter, and with it has finalized a patch to reduce the high virtual address space usage of games under Vista. From this and our own developer sources, we can piece together the problem that was causing the high virtual address space issues under Vista.

As it turns out, our initial guess about the issue being related to memory allocations being limited to the 2GB of user space for security reasons was wrong, the issue is simpler than that. One of the features of the Windows Vista Display Driver Model (WDDM) is that video memory is no longer a limited-sharing resource that applications will often take complete sovereign control of; instead the WDDM offers virtualization of video memory so that all applications can use what they think is video memory without needing to actually care about what else is using it - in effect removing much of the work of video memory management from the application. From both a developer's and user's perspective this is great as it makes game/application development easier and multiple 3D accelerated applications get along better, but it came with a cost.

All of that virtualization requires address space to work with; Vista uses an application's 2GB user allocation of virtual address space for this purpose, scaling the amount of address space consumed by the WDDM with the amount of video memory actually used. This feature is ahead of its time however as games and applications written to the DirectX 9 and earlier standards didn't have the WDDM to take care of their memory management, so applications did it themselves. This required the application to also allocate some virtual address space to its management tasks, which is fine under XP.

However under Vista this results in the application and the WDDM effectively playing a game of chicken: both are consuming virtual address space out of the same 2GB pool and neither is aware of the other doing the exact same thing. Amusingly, given a big enough card (such as a 1GB Radeon X2900XT), it's theoretically possible to consume all 2GB of virtual address space under Vista with just the WDDM and the application each trying to manage the video memory, which would leave no further virtual address space for anything else the application needs to do. In practice, both the virtual address space allocations for the WDDM and the application video memory manager attempt to grow as needed, and ultimately crash the application as each starts passing 500MB+ of allocated virtual address space.

This obviously needed to be fixed, and for a multitude of reasons (such as Vista & XP application compatibility) such a fix needed to be handled by the operating system. That fix is KB940105, which is a change to how the WDDM handles its video memory management. Now the WDDM will not default to using its full memory management capabilities, and more importantly it will not be consuming virtual address space unless specifically told to by the application. This will significantly reduce the virtual address space usage of an application when video memory is the culprit, but at best it will only bring Vista down to the kind of virtual address space usage of XP.

Testing the KB940105 Hotfix


View All Comments

  • MadBoris - Monday, August 13, 2007 - link

    bah no edit function...correction...

    "the problem is all developers are being handicapped by RAM for PC now."

    ...handicapped by the 2GB memory ceiling for PC now. (handicapped in development)
  • stash - Monday, August 13, 2007 - link

    Calling PSS for hotfixes is no longer required. You can request hotfixes through the web.">
  • Rebel44 - Tuesday, August 14, 2007 - link

    Direct link to hotfix download"> - its password protected (password: {8ly8YX2 is valid untill 8.17.07) Reply
  • leexgx - Tuesday, August 14, 2007 - link

    password must change offen link">

    has both files to x86 and x64 (useing the 64 one now)

    uses with cards that are less then 512mb (e.g. 256mb) are likey to be less affected or not affected at all as most games would be unplayable on Very high detail settings on them type of games so running out of ram probly not happen on lower end cards
  • n0nsense - Tuesday, August 14, 2007 - link

    stay with "quality" buggy products of MS and you will experience much more :)
    Linux (and all xNIX OSes including Mac OS X) moved to native 64 bit few years ago. I'm personally use Gentoo x64 since my upgrade to C2D (more then year) and i didn't felt the transfer. Almost every software available as native 64 (including commercial soft like Nero). and what is not, working seamless (even 32bit drivers on 64bit system).
    for people that does not have 64 bit hardware, there is a kernel (OS) support for 64GB of RAM. and first 4GB can be shared between system and user spaces as 1/3 GB (respectively) 2/2GB and 3/1GB. this can solve the issue for microsoft, but it seems they are too greedy to solve the problems for what you already have paid, they will force you to pay for something else with different problems ;)
    this is not anti MS or pro xNIX post, the suggestion for solution is inside.

Log in

Don't have an account? Sign up now