Conquer Desktop Heap Problems

As an administrator, you've probably run into a desktop heap problem (e.g., an out of memory error message or failed application startup) and know firsthand how tough this type of problem is to solve. Part of the difficulty lies in first identifying that your symptom is related to an exhaustion of desktop heap memory. Another challenge is discovering which process or service is consuming the greatest amount of desktop heap, then determining what registry parameter to change to work around the problem. This month, I'll show how to quickly identify whether your system is running out of desktop heap. (See the box below for a list of common symptoms of a desktop heap problem.) Then I'll give you some tools and best practices you can use to resolve the problem or progress toward a solution before contacting tech support.

Windows Internals Background
Before starting our desktop heap troubleshooting, you'll need some Windows internals background to understand how desktop heap problems occur. Windows 2000 and later systems have a configurable area of kernel mode memory called session space. Session space represents a single user’s logon environment; you can also think of session space as each user’s sandbox of windows and desktops.

You should also know that each session (e.g., Session 0, Session 1) contains window stations that act as a security boundary for desktops. Although the term “desktop” may bring to mind the interactive desktop that each user sees when logged onto Windows, actually not every desktop interacts with the user. Each window station contains desktop objects, and every session will have one interactive window station named WinSta0 that users will see when they log into their systems.

Another way to conceptualize the desktop tree system is that every Win32 thread belongs to a desktop. Every desktop belongs to a window station; one window station per session interacts with the user, while the rest do not. And every window station belongs to a session. The schematic in Figure 1 depicts the desktop tree on a typical system. In Figure 1, two sessions are listed: Session 0 and Session 1. Session 0 is where services typically run and also represents the console (prior to Windows Vista). Any other session such as Session 1 or Session 2 typically represents a Terminal Services or Fast User Switching session.

What Is Desktop Heap Exactly?
Every desktop object requires memory to store UI objects, such as windows and menus. This memory is called desktop heap. When applications require a UI object, functions within user32.dll are called, and desktop heap memory is allocated. There is one desktop heap per desktop, and the heap memory itself is allocated from session-view space, which is a subset of session space.

While this process of allocating desktop heap memory for storing windows and menus works behind the scenes, there are two primary scenarios in which failures can occur. Session-view space can become fully utilized so that no new desktops can be created. This scenario can occur when multiple services run under a nonlocal system-specific user account, creating a new desktop for every instance of the service. In the second scenario, existing desktop heaps can become fully utilized, so that threads running in that desktop can't use more desktop heap memory. This is the more common scenario and can be caused by running many instances of the same process (e.g., several instances of Internet Explorer) or by a single process that has heavy UI object usage.

Diagnostic Tools
Let’s look at some methods that make diagnosing desktop heap exhaustion issues much easier. Desktop Heap Monitor 8.1 (Dheapmon), available at tinyurl.com/Dheapmon, is a handy tool to use for Windows XP or Windows Server 2003 systems (Dheapmon doesn’t run on Vista or Windows Server 2008). The tool's output provides a user-friendly menu describing the total number of desktops, sessions, and window stations. The output, which Figure 2 shows, displays how fully utilized each desktop is on a percentage basis.

The most important numbers in the Dheapmon output are those in the Used Rate (%) column, which will help you determine whether any of the desktops being monitored is becoming fully utilized (i.e., 90 percent or more). Another number to watch is the Total Desktop value—the total amount of memory allocated by all desktops. If this number approaches the total size of the session-view space, then Windows can't create any more new desktops in a session. If this is the case, you may need to change a registry value to increase the default session-view size. Table 1 shows the default session-view sizes for Win2K, XP, and Windows 2003.