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 8 and 3 and type the answer here:
  • Post
  • Does anybody know anything about the 4th SharedSection parameter?

    This is from Windows 2000 Advanced Server SP4:

    %SystemRoot%\system32\csrss.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!

  • andrej,

    Good question.  The 4th parameter is not read by the window manager, and it does not affect desktop heap sizes.  In fact, I’m not aware of any component in Windows that uses the 4th parameter.  Despite that, as you have observed, from time to time we see the 4th parameter appear in the registry of Windows 2000 machines.  Perhaps this value is put there incorrectly during Windows setup or service pack install.  Or maybe some 3rd party software writes this value.  In any case, the value isn’t actually used by Windows.

  • 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

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

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

  • How can I use dheapmon to determine if a server is running out of heapspace on a terminal server? I am having issues where after so many users log into the server I am seeing weird issues. I think it is the desktop heap needing to be increased but how can I verify this? I am talking about the total sessionViewsize for the server. For terminal servers is there a way to see what each session is using, etc? Or is it just simple math, if each default session allocates 3mb than the max terminal sessions able to run on the box would be 16?

    [This is a common point of confusion. Let me try to clear things up. Let’s assume your server is set up with SessionViewSize = 20 MB. In that case, each session gets 20 MB of session view space. Session view allocations (like desktop heaps) that are allocated in session 1 have no affect on session view usage in session 2, or session 3, etc. So every session has 20 MB of session view space to play with, and if session 2 runs out of session view space, that has no bearing on any other session. Furthermore, session view space takes up 20 MB of the (typical) 2 GB of kernel virtual address space, not matter how many sessions you have. That is because session view space uses the same range of virtual addresses in every session. Depending on the current session context, the physical pages backing that virtual address range will change, but only 20 MB of kernel virtual address space will be consumed. - Matthew]
  • 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]
  • 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...

  • 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?

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

    HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems\Windows 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>
  • 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!]
  • This tool give us the total number of the User objects, but how can I know the type of the User object?

  • 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)
     WinStation\Desktop            Heap Size(KB)    Used Rate(%)
    -------------------------------------------------------------

     WinSta0\Default                    3072             98.7
     WinSta0\Disconnect                   64              4.5
     WinSta0\Winlogon                    128              9.5
     Service-0x0-3e7$\Default            512             36.0
     Service-0x0-3e4$\Default            512              8.3
     Service-0x0-3e5$\Default            512              8.2
     SAWinSta\SADesktop                  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.]
Page 1 of 2 (21 items) 12