Partager via

Desktop Heap, part 2

  • Article

 

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.]

Comments

  • Anonymous
    July 05, 2007
    Does anybody know anything about the 4th SharedSection parameter? This is from Windows 2000 Advanced Server SP4: %SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,3072,512,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16 Can this 4th parameter occur on newer Windows too? Thanks for the answers!

  • Anonymous
    July 05, 2007
    The comment has been removed

  • Anonymous
    July 06, 2007
    Thanks for the information in this and the previous article. Upgrading the desktop heap size resolved a lot of issues on my development system with several IEs, Explorers and Visual Studios open at the same time

  • Anonymous
    July 09, 2007
    Is the Vista 32 bit setting for 'Interactive desktop heap size' really 3072MB now?  Or is that a typo? [That's a typo. Thanks for catching it. I've corrected it now. - Matthew]

  • Anonymous
    July 10, 2007
    In that case, I wonder why it hasn't been increased at all from XP to Vista (32 anyway).  I run XP with 2GB RAM, and was never able to get anything like all of it it use running lots of windows until I upped that value to 9072KB - no science, just changed the 3 to a 9 :-)  Now it's great.  Given that Vista seems to need at least a gig and preferably 2, you'd thunk it would have been sensible to change the default. Andy

  • Anonymous
    July 27, 2007
    Could you please provide a helper DLL for XP, Server 2003 and Vista that will implement a Performance Monitor object that can be displayed directly in the Perfomance Analysis tool; make this helper DLL (similar to ToolHelp when it was developed in windows 95) redistributable, so that it may be used in applications so that they can self-diagnose the problem of desktop-heap exhaustion or by services or interactive virtual desktop managers that fail to create a new session or desktop. Then other accessorires (similar to those that existed in Windows 9x to display the current GDI heap and USER heap status) could be made to display the current status of the desktop heap (i.e. its fill level) so that users will know inadvance that their desktop is too crowded. Applications could also use this feature to help disagnose the problem for example after CreateWindow(Ex) fails: it may attempt to query the Performance Object (if it is present) to see if the Desktop Heap exhaustion is the problem, so that it could guide the user about what he can do to solve the problem, instead of just failing miserably without clear indication of why a window could not be created.

  • Anonymous
    August 28, 2007
    The comment has been removed

  • Anonymous
    September 11, 2007
    Based upon a lot of testing we discovered that a certain graphically intensive application required around 24MB of preallocated SessionViewSize per concurrent session. Given that each user typically runs 4 copies at a time I have had to increase the default value to 96MB per session in order for all copies of the application to load without any graphics glitches being introduced. I am concerned that there may be a finite limit to the overall amount of SessionViewSize memory that might limit the number of sessions that each server can run. I read with interest the last comments that implied that this will not limit the amount of virtual kernel space, i.e. per session, but if say 20-30 users were logged in simultaneously I need to make sure that 30 * 96MB of RAM will not exceed some system memory total. I am planning to implement 8 CPU core servers with 32GB RAM per 20-30 users using 32-bit Windows Server 2003 R2. Could I find that I exceed the total non-paged/paged pool/kernel memory limits somehow? I don't have the luxury of being able to prove this on a test bench as reluctantly all of the testing has been done on VMs with only a small number of users. [Each session uses the same virtual address space range for SessionViewSpace, but the physical pages that back SessionViewSpace are unique for each session. So each new session will grow the total committed bytes in use. That is, the virtual addresses will be backed by physical storage either in RAM or the page file. You won’t be exceeding a kernel virtual memory limitation, since the amount of VA space used is fixed at 96MB (in your case). - Matthew]

  • Anonymous
    October 06, 2007
    I would just like to echo the suggestion posted by Philippe Verdy.  My wife and I are usually both logged into our new PC, running Windows Vista, which has 2 GB of RAM.  Task manager says we're currently using 52% of RAM, but I can't do anything that would require a new window to open without first closing another window (open another tab in IE, right click, start another program).  Windows just silently fails.  I ran perfmon (which, by the way, I'm very impressed with given the improvements in vista), because I remember the GDI object count in previous versions of windows.  No luck finding any indication of hitting a ceiling in any resource there... After searching the web for a couple of hours I think I've stumbled upon the solution... but it certainly wasn't obvious; I think I only found it because I had an idea what might be going on (I develop software for a living).  'Regular' users who like to really multitask will probably be ticked and mystified because programs don't tell you why they can't open another window...

  • Anonymous
    November 08, 2007
    I am repeaatedly running into a Desktop Heap Alloction issue, in which i can no longer open more windows, or even access the popup menus for existing ones. Adjusiting the heapsizes makes things a bit more stable, but i still run into the issues! Any idea on how to deal with this once and for all?

  • Anonymous
    December 11, 2007
    We have a VMWare Server running a virtual session 64-bit Windows Server 2003 R2, SQL Server Standard SP4 64-bit. The server is basically configured and used as a distribution server. It has over 200 publications, with multiple subscriptions each. When attempting to run some of the subscriptions continues we run into a 'waiting on worker thread' message and the subscriptions will normally go into suspect mode. This happens when more than 15 run continuously or at the same time. The solution and what has worked previously on a physical server non virtualized was to increase the 3rd value of the desktop heap. This allowed for more memory to be allocated in order to use more worker threads. However this same fix has not worked on the virtualized server. The increase in the value has had no affect on the server. Could the issue be due to the server running on VM or is the problem else where? [I don’t know offhand why running in a VM would make a difference in this scenario. I suggest you run dheapmon from session 0 and check the desktop heap usage of non-interactive desktop heaps.]

  • Anonymous
    April 02, 2008
    We have had Desktop heap issues from running LOTS of non-interactive System services (each of which is a Java VM) for some time.  With 2000 server, the largest we could make the 3rd SharedSection value was about 2500.  Using 2003 Server (Ent, 32 bit), we have no problem with the value of 4096 on the 3rd value.  With about 150 added JVM services, increasing the 3rd value to 5120  prevents services from starting with Event ID: 7023 A dynamic link library (DLL) initialization routine failed. Event ID: 1046 HKLMSYSTEMCurrentControlSetControlSessionManagerSubSystemsWindows registry contains a substring SharedSection=. The values for this SharedSection are too big. The Default values are SharedSection=1024,3072,512 Please change the registry values for Windows to load up properly. We would like to run say 300 services on each web server instead of adding another every 150 instances, but have never had much luck. With Term Services only for two Admin RDs, and no /3GB switch, is there something we could be doing that would let us get to 250 extra Services with the current 2003 32 bit Servers?   [The inability to further increase the 3rd value is likely due to session view space being fully consumed by too many large desktop heaps. A 3rd value of 4096 is already quite large; keep in mind that multiple heaps are created with the specified size, each one consuming a chunk of session view space. You could increase SessionViewSize to allow for larger non-interactive desktop heaps. However, do this with caution. An increase in the size of session view space means a decrease in one or more other kernel virtual address ranges.]< DIV>

  • Anonymous
    April 09, 2008
    I do not know if this is true or not, but I have read that the 4th parameter is used during a terminal server session. [I've heard that before too, but it isn't true.  The value isn't used by Windows.  It certainly is a persistent rumor!]

  • Anonymous
    June 19, 2008
    This tool give us the total number of the User objects, but how can I know the type of the User object?

  • Anonymous
    June 26, 2008
    I want to know WHAT is taking up my Desktop Heap!! See output below Desktop Heap Information Monitor Tool (Version 8.1.2925.0)
    Copyright (c) Microsoft Corporation.  All rights reserved.
    -------------------------------------------------------------
     Session ID:    0 Total Desktop: (  5824 KB -    8 desktops)
     WinStationDesktop            Heap Size(KB)    Used Rate(%)
    -------------------------------------------------------------  WinSta0Default                    3072             98.7
     WinSta0Disconnect                   64              4.5
     WinSta0Winlogon                    128              9.5
     Service-0x0-3e7$Default            512             36.0
     Service-0x0-3e4$Default            512              8.3
     Service-0x0-3e5$Default            512              8.2
     SAWinStaSADesktop                  512              0.5
     __X78B95_89_IW__A8D9S1_42_ID       512              0.5

What is using all of that heap? [I recommend you start by looking at the USER object count in task manager, and see if any process has a high USER object count. That will at least tell you what process is the likely primary consumer of desktop heap. If you stop the process in question, you should see desktop heap usage drop in dheapmon. Alternately, you can just kill processes in your session, watch the desktop heap usage in dheapmon after you kill each one, and observe how much desktop heap each process was using.]

  • Anonymous
    August 14, 2008
    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.]
  • Anonymous
    August 22, 2008
    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.]
  • Anonymous
    September 02, 2008
    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]
  • Anonymous
    September 04, 2008
    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.]
  • Anonymous
    March 12, 2009
    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.]
  • Anonymous
    February 24, 2010
    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!