Virtual address space usage in Windows Vista game development

Support for Windows Vista without any service packs installed ended on April 13, 2010. To continue receiving security updates for Windows, make sure you're running Windows Vista with Service Pack 2 (SP2). For more information, refer to this Microsoft web page: Support is ending for some versions of Windows


This update reduces the use of virtual address space in certain scenarios. After you install this update, applications that run on hardware configurations that have a large amount of video memory may be less likely to reach virtual address space limits. This update may improve application performance on certain hardware configurations.

This update is included in Windows Vista Service Pack 1 (SP1).

For more information how to obtain the latest Vista Service Pack or how to verify that you have the latest Vista Service Pack installed, click the following article number to view the article in the Microsoft Knowledge Base:

935791 How to obtain the latest Windows Vista service pack

More information for advanced users

This article discusses virtual address space usage in Windows game development. The article describes potential problems that may occur when you run applications in a modern operating system such as Windows Vista. The article contains information about an update that may resolve some of these problems. For more information about these problems, visit the following Microsoft Web site: On a modern operating system such as Windows Vista, applications run within their own private virtual address space. Typically, the size of the virtual address space is fixed at 2 gigabytes (GB) for 32-bit applications. How much virtual address space is available is not related to how much physical memory there is on the computer.

Every memory allocation, file mapping, or library that is loaded by an application consumes space in this virtual address space. When the application consumes all its virtual address space, any additional such operations fail. Although all applications should be coded to handle memory allocation failures, many applications do not recover correctly from such failures. Therefore, the programs may become unstable or stop responding after they recover from such failures.

Existing games and other graphics applications frequently allocate virtual memory for a copy of the video memory resources that the application uses. The application uses this copy to restore the display quickly if the contents of video memory are lost. For example, the application uses this copy if the user presses ALT+TAB or if the user puts the computer in standby. Typically, the DirectX run time manages the copy on behalf of the application when the application creates a managed resource. However, an application can also manage the copy itself. The virtual memory that the copy uses is directly proportional to the video memory resources that the application allocates.

A modern graphics processing unit (GPU) can have 512 MB or more of video memory. Applications that try to take advantage of such large amounts of video memory can use a large proportion of their virtual address space for an in-memory copy of their video resources. On 32-bit systems, such applications may consume all the available virtual address space.

With the introduction of DirectX 10 and Windows Display Driver Model (WDDM) in Windows Vista, it is no longer necessary for an application to maintain a copy of its resources in system memory. Instead, the video memory manager makes sure that the content of every video memory allocation is maintained across display transitions. For compatibility reasons, Windows Vista emulates "device lost" for DirectX versions that are earlier than DirectX 10 to make sure that no application-visible API behavior changes.

To virtualize video memory, the video memory manager in Windows Vista assigns a virtual address range to every video memory resource. This range is conceptually similar to the copy that an application might create. However, the video memory manager manages the process more efficiently than the application might. The video memory manager uses the virtual address range to handle transitions or over-commitment of video memory. However, the virtual address range is typically unused on a system that has lots of video memory. As long as this virtual address range remains unused, no physical memory is allocated for it. In contrast, the system memory copy that is maintained in the older driver model is guaranteed to be fully populated with physical memory.

If an application creates its own in-memory copy of its video resources, or the application uses DirectX 9 or an earlier version, the virtual address space contains the WDDM video memory manager's virtualized range and the application's copy. Applications that use graphics APIs that are earlier than DirectX 10 and that target GPUs that have large amounts of video memory can easily exhaust their virtual address space.

To address this problem, Microsoft is changing the way that the video memory manager maintains the content of video memory resources. This change is being made so that a permanent virtual address range does not have to be used for each virtualized allocation. With the new approach, only allocations that are created as "lockable" consume space in the virtual address space of the application. Allocations that are not created as "lockable" do not consume space. This approach significantly reduces the virtual address space that is used. Therefore, the application can run on large video memory configurations without reaching the limits.

Although this approach reduces virtual address consumption, it does not eliminate the 2 GB virtual address space limit that many applications are quickly approaching on their own. Eventually, applications will reach the limit for other reasons.

Update information

The following files are available for download from the Microsoft Download Center:

Windows Vista, 32-bit versions

Download Download the 940105 package now.

Windows Vista, 64-bit versions

Download Download the 940105 package now.

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.


If you are running a Windows Vista-based computer that has multiple graphics cards, we recommend that you first install the hotfix that is included in Microsoft Knowledge Base article 936710. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

936710 When a DirectX 10 application runs on a Windows Vista-based computer that has multiple graphics cards, the computer does not use the secondary graphics card

Restart requirement

You must restart the computer after you apply this update.

Update replacement information

This update does not replace a previously released update.

File information

The English version of this update has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.
Windows Vista, 32-bit versions
File nameFile versionFile sizeDateTimePlatform
Update.mumNot Applicable1,78827-Jul-200717:27Not Applicable
X86_5e2dac6229b5926b0c74da835150f1a5_31bf3856ad364e35_6.0.6000.20648_none_42a29c9b7959cc08.manifestNot Applicable69627-Jul-200717:27Not Applicable
X86_microsoft-windows-lddmcore_31bf3856ad364e35_6.0.6000.20648_none_aa48b77dff9d11aa.manifestNot Applicable8,95827-Jul-200717:27Not Applicable
Windows Vista, 64-bit versions
File nameFile versionFile sizeDateTimePlatform
Amd64_ce07f9e62de28926f56e50610267ed82_31bf3856ad364e35_6.0.6000.20648_none_ff82e7b15cf29216.manifestNot Applicable70027-Jul-200717:27Not Applicable
Amd64_microsoft-windows-lddmcore_31bf3856ad364e35_6.0.6000.20648_none_06675301b7fa82e0.manifestNot Applicable9,22327-Jul-200717:31Not Applicable
Update.mumNot Applicable1,78827-Jul-200717:27Not Applicable