Desktop Heap, part 2

Desktop Heap, part 2

Rate This
  • Comments 21

 

Matthew here again – I want to provide some follow-up information on desktop heap.   In the first post I didn’t discuss the size of desktop heap related memory ranges on 64-bit Windows, 3GB, or Vista.   So without further ado, here are the relevant sizes on various platforms...

 

 

Windows XP (32-bit)

 

·         48 MB = SessionViewSize (default registry value, set for XP Professional, x86)

·         20 MB = SessionViewSize (if no registry value is defined) 

·         3072 KB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         512 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         128 KB = Winlogon desktop heap size

·         64 KB = Disconnect desktop heap size

 

 

 

Windows Server 2003 (32-bit)

 

·         48 MB = SessionViewSize (default registry value)

·         20 MB = SessionViewSize (if no registry value is defined; this is the default for Terminal Servers)

·         3072 KB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         512 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         128 KB = Winlogon desktop heap size

·         64 KB = Disconnect desktop heap size

 

 

 

Windows Server 2003 booted with 3GB (32-bit)

 

·         20 MB = SessionViewSize (registry value has no effect)

·         3072 KB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         512 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         128 KB = Winlogon desktop heap size

·         64 KB = Disconnect desktop heap size

 

You may also see reduced heap sizes when running 3GB.  During the initialization of the window manager, an attempt is made to reserve enough session view space to accommodate the expected number of desktops heaps for a given session.  If the heap sizes specified in the SharedSection registry value have been increased, the attempt to reserve session view space may fail.  When this happens, the window manager falls back to a pair of “safe” sizes for desktop heaps (512KB for interactive, 128KB for non-interactive) and tries to reserve session space again, using these smaller numbers.  This ensures that even if the registry values are too large for the 20MB session view space, the system will still be able to boot.

 

 

 

Windows Server 2003 (64-bit)

 

·         104 MB = SessionViewSize (if no registry value is defined; which is the default) 

·         20 MB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         768 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         192 KB = Winlogon desktop heap size

·         96 KB = Disconnect desktop heap size

 

 

 

Windows Vista RTM (32-bit)

 

·         Session View space is now a dynamic kernel address range.  The SessionViewSize registry value is no longer used.

·         3072 KB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         512 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         128 KB = Winlogon desktop heap size

·         64 KB = Disconnect desktop heap size

 

 

 

Windows Vista (64-bit) and Windows Server 2008 (64-bit)

 

·         Session View space is now a dynamic kernel address range.  The SessionViewSize registry value is no longer used.

·         20 MB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         768 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         192 KB = Winlogon desktop heap size

·         96 KB = Disconnect desktop heap size

 

 

Windows Vista SP1 (32-bit) and Windows Server 2008 (32-bit)

 

·         Session View space is now a dynamic kernel address range.  The SessionViewSize registry value is no longer used.

·         12288 KB = Interactive desktop heap size (defined in the registry, SharedSection 2nd value)

·         512 KB = Non-interactive desktop heap size (defined in the registry, SharedSection 3nd value)

·         128 KB = Winlogon desktop heap size

·         64 KB = Disconnect desktop heap size 

 

 

Windows Vista introduced a new public API function: CreateDesktopEx, which allows the caller to specify the size of desktop heap.

Additionally, GetUserObjectInformation now includes a new flag for retrieving the desktop heap size (UOI_HEAPSIZE).

 

 

[Update: 3/20/2008 - Added Vista SP1 and Server 2008 info.  More information can be found here.]

Leave a Comment
  • Please add 1 and 6 and type the answer here:
  • Post
  • We believe that we are running out of desktop heap, but when we check the number of user objects for our process, it is never even close to the 10000 object limit that is normally imposed in Windows XP. Are there other handles, or other statistics on the process that we need to be reviewing? Would information from Process Explorer help?

    [Keep in mind that desktop heap is a common heap for all threads that utilize a particular desktop. Be sure that you examine the USER object count of all processes that have threads that use the desktop in question.]
  • I tried to use EnumWindows and EnumChildWindows to see if I can account for all of the user objects of a given process (first looked for all top level windows followed by all children windows of the top level windows), and only about half of the user objects could be accounted for. This article mentions user objects have other means of creation other than CreateWindowsEx - http://msdn.microsoft.com/en-us/library/ms725486(VS.85).aspx. Are there similar functions that could be utilized to figure out what objects are being leaked? GDI leaks have several different tools to figure out what objects are leaking, but there does not seem to be an equivalent to user objects.

    [Not all USER objects come out of desktop heap, but windows, menus, and hooks do. So your EnumWindows strategy would work for tracking windows only, but as you discovered, other USER object types may be involved. I’m not aware of a tool for displaying a count of each USER object type in use. One option is to debug the process and set breakpoints on the relevant user32.dll function and observe as objects are created and destroyed, although this can be tedious.]
  • I too would like to echo the suggestion by Philippe Verd to add a permon counter since that's the first place I looked when I had an inkling of what the problem was.

    The other thing I'd like to see is an Event created in the Event Log if a window fails to be created with the appropriate error description, e.g.

    PID, Process name.exe, Failed to create window class 'BUTTON', title 'OK'. Desktop Heap Exhausted.

    Would probably tell you everything you needed to know.

    I'm asking for this as the Event Log was the other place I looked for errors but came up blank.

    [Thanks for your feedback. While this doesn’t fully address your ideas, the system can be configured to log an event upon desktop heap failures. More info on that here: http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx#4416605]
  • Has anyone (especially anyone at Microsoft) thought to use the Detours library (http://research.microsoft.com/sn/detours) to monitor create/delete of user objects, keep track of the stack (StackWalk64) and then provide information either on exit of the application or provide snapshot capabilities like other memory leak utilities. For those unfamiliar with Detours, it allows for very easy hooks in the application so that pre and post processing can occur anytime someone calls an API like CreateWindowEx and DestroyWindow. To use commercially or in a production setting does require a one-time fee.

    [Our team does use Detours from time to time; it is very useful. However, I'm not aware of anyone that has specifically used it in the way you describe.]
  • What the maximum heap sizes for 2008 32bit and 64bit servers?

    Interactive desktop heap size = ?

    Non-Interactive desktop heap size max = ?

    [The size of desktop heaps are limited by the size of session view space, which is a dynamic memory range. So the maximum size can vary.]
  • We met an issue when launching our WPF application on some laptops with windows XP.

    This issue is that bitmap screen will occur when launching our WPF application.

    It seems that this issue can be resolved after installing KB967328.

    And, it seems that this issue can be resolved too through modifying the desktop heap size from 3m to 8m.

    Could you please tell me what relation between KB967328 and desktop heap size? Thanks a lot!

Page 2 of 2 (21 items) 12