Desktop Heap Overview

Desktop Heap Overview

Rate This


Desktop heap is probably not something that you spend a lot of time thinking about, which is a good thing.  However, from time to time you may run into an issue that is caused by desktop heap exhaustion, and then it helps to know about this resource.  Let me state up front that things have changed significantly in Vista around kernel address space, and much of what I’m talking about today does not apply to Vista.


Laying the groundwork: Session Space

To understand desktop heap, you first need to understand session space.  Windows 2000, Windows XP, and Windows Server 2003 have a limited, but configurable, area of memory in kernel mode known as session space.  A session represents a single user’s logon environment.  Every process belongs to a session.  On a Windows 2000 machine without Terminal Services installed, there is only a single session, and session space does not exist.  On Windows XP and Windows Server 2003, session space always exists.  The range of addresses known as session space is a virtual address range.  This address range is mapped to the pages assigned to the current session.  In this manner, all processes within a given session map session space to the same pages, but processes in another session map session space to a different set of pages. 

Session space is divided into four areas: session image space, session structure, session view space, and session paged pool.  Session image space loads a session-private copy of Win32k.sys modified data, a single global copy of win32k.sys code and unmodified data, and maps various other session drivers like video drivers, TS remote protocol driver, etc.  The session structure holds various memory management (MM) control structures including the session working set list (WSL) information for the session.  Session paged pool allows session specific paged pool allocations.  Windows XP uses regular paged pool, since the number of remote desktop connections is limited.  On the other hand, Windows Server 2003 makes allocations from session paged pool instead of regular paged pool if Terminal Services (application server mode) is installed.  Session view space contains mapped views for the session, including desktop heap. 

Session Space layout:

Session Image Space: win32k.sys, session drivers

Session Structure: MM structures and session WSL

Session View Space: session mapped views, including desktop heap

Session Paged Pool


Sessions, Window Stations, and Desktops

You’ve probably already guessed that desktop heap has something to do with desktops.  Let’s take a minute to discuss desktops and how they relate to sessions and window stations.  All Win32 processes require a desktop object under which to run.  A desktop has a logical display surface and contains windows, menus, and hooks.  Every desktop belongs to a window station.  A window station is an object that contains a clipboard, a set of global atoms and a group of desktop objects.  Only one window station per session is permitted to interact with the user. This window station is named "Winsta0."  Every window station belongs to a session.  Session 0 is the session where services run and typically represents the console (pre-Vista).  Any other sessions (Session 1, Session 2, etc) are typically remote desktops / terminal server sessions, or sessions attached to the console via Fast User Switching.  So to summarize, sessions contain one or more window stations, and window stations contain one or more desktops.

You can picture the relationship described above as a tree.  Below is an example of this desktop tree on a typical system:

- Session 0

|   |

|   ---- WinSta0           (interactive window station)

|   |      |

|   |      ---- Default    (desktop)

|   |      |

|   |      ---- Disconnect (desktop)

|   |      |

|   |      ---- Winlogon   (desktop)

|   |

|   ---- Service-0x0-3e7$  (non-interactive window station)

|   |      |

|   |      ---- Default    (desktop)

|   |

|   ---- Service-0x0-3e4$  (non-interactive window station)

|   |      |

|   |      ---- Default    (desktop)

|   |

|   ---- SAWinSta          (non-interactive window station)

|   |      |

|   |      ---- SADesktop  (desktop)

|   |

- Session 1

|   |

|   ---- WinSta0           (interactive window station)

|   |      |

|   |      ---- Default    (desktop)

|   |      |

|   |      ---- Disconnect (desktop)

|   |      |

|   |      ---- Winlogon   (desktop)

|   |

- Session 2


    ---- WinSta0           (interactive window station)


           ---- Default    (desktop)


           ---- Disconnect (desktop)


           ---- Winlogon   (desktop)


In the above tree, the full path to the SADesktop (as an example) can be represented as “Session 0\SAWinSta\SADesktop”.


Desktop Heap – what is it, what is it used for?

Every desktop object has a single desktop heap associated with it.  The desktop heap stores certain user interface objects, such as windows, menus, and hooks.  When an application requires a user interface object, functions within user32.dll are called to allocate those objects.  If an application does not depend on user32.dll, it does not consume desktop heap.  Let’s walk through a simple example of how an application can use desktop heap. 

1.     An application needs to create a window, so it calls CreateWindowEx in user32.dll.

2.     User32.dll makes a system call into kernel mode and ends up in win32k.sys.

3.     Win32k.sys allocates the window object from desktop heap

4.     A handle to the window (an HWND) is returned to caller

5.     The application and other processes in the same session can refer to the window object by its HWND value


Where things go wrong

Normally this “just works”, and neither the user nor the application developer need to worry about desktop heap usage.  However, there are two primary scenarios in which failures related to desktop heap can occur:

  1. Session view space for a given session can become fully utilized, so it is impossible for a new desktop heap to be created.
  2. An existing desktop heap allocation can become fully utilized, so it is impossible for threads that use that desktop to use more desktop heap.


So how do you know if you are running into these problems?  Processes failing to start with a STATUS_DLL_INIT_FAILED (0xC0000142) error in user32.dll is a common symptom.  Since user32.dll needs desktop heap to function, failure to initialize user32.dll upon process startup can be an indication of desktop heap exhaustion.  Another symptom you may observe is a failure to create new windows.  Depending on the application, any such failure may be handled in different ways.  Note that if you are experiencing problem number one above, the symptoms would usually only exist in one session.  If you are seeing problem two, then the symptoms would be limited to processes that use the particular desktop heap that is exhausted.


Diagnosing the problem

So how can you know for sure that desktop heap exhaustion is your problem?  This can be approached in a variety of ways, but I’m going to discuss the simplest method for now.  Dheapmon is a command line tool that will dump out the desktop heap usage for all the desktops in a given session.  See our first blog post for a list of tool download locations.  Once you have dheapmon installed, be sure to run it from the session where you think you are running out of desktop heap.  For instance, if you have problems with services failing to start, then you’ll need to run dheapmon from session 0, not a terminal server session.

Dheapmon output looks something like this:

Desktop Heap Information Monitor Tool (Version 7.0.2727.0)

Copyright (c) 2003-2004 Microsoft Corp.


  Session ID:    0 Total Desktop: (  5824 KB -    8 desktops)


  WinStation\Desktop            Heap Size(KB)    Used Rate(%)


  WinSta0\Default                    3072              5.7

  WinSta0\Disconnect                   64              4.0

  WinSta0\Winlogon                    128              8.7

  Service-0x0-3e7$\Default            512             15.1

  Service-0x0-3e4$\Default            512              5.1

  Service-0x0-3e5$\Default            512              1.1

  SAWinSta\SADesktop                  512              0.4

  __X78B95_89_IW\__A8D9S1_42_ID       512              0.4



As you can see in the example above, each desktop heap size is specified, as is the percentage of usage.  If any one of the desktop heaps becomes too full, allocations within that desktop will fail.  If the cumulative heap size of all the desktops approaches the total size of session view space, then new desktops cannot be created within that session.  Both of the failure scenarios described above depend on two factors: the total size of session view space, and the size of each desktop heap allocation.  Both of these sizes are configurable. 


Configuring the size of Session View Space

Session view space size is configurable using the SessionViewSize registry value.  This is a REG_DWORD and the size is specified in megabytes.  Note that the values listed below are specific to 32-bit x86 systems not booted with /3GB.  A reboot is required for this change to take effect.  The value should be specified under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management


Size if no registry value configured

Default registry value

Windows 2000 *

20 MB


Windows XP

20 MB

48 MB

Windows Server 2003

20 MB

48 MB

* Settings for Windows 2000 are with Terminal Services enabled and hotfix 318942 installed.  Without the Terminal Services installed, session space does not exist, and desktop heap allocations are made from a fixed 48 MB region for system mapped views.  Without hotfix 318942 installed, the size of session view space is fixed at 20 MB.

The sum of the sizes of session view space and session paged pool has a theoretical maximum of slightly under 500 MB for 32-bit operating systems.  The maximum varies based on RAM and various other registry values.  In practice the maximum value is around 450 MB for most configurations.  When the above values are increased, it will result in the virtual address space reduction of any combination of nonpaged pool, system PTEs, system cache, or paged pool.


Configuring the size of individual desktop heaps

Configuring the size of the individual desktop heaps is bit more complex.  Speaking in terms of desktop heap size, there are three possibilities:

·         The desktop belongs to an interactive window station and is a “Disconnect” or “Winlogon” desktop, so its heap size is fixed at 64KB or 128 KB, respectively (for 32-bit x86)

·         The desktop heap belongs to an interactive window station, and is not one of the above desktops.  This desktop’s heap size is configurable.

·         The desktop heap belongs to a non-interactive window station.  This desktop’s heap size is also configurable.


The size of each desktop heap allocation is controlled by the following registry value:

            HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows


 The default data for this registry value will look something like the following (all on one line):

               %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows

               SharedSection=1024,3072,512 Windows=On SubSystemType=Windows

               ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3

               ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off




The numeric values following "SharedSection=" control how desktop heap is allocated. These SharedSection values are specified in kilobytes.

The first SharedSection value (1024) is the shared heap size common to all desktops. This memory is not a desktop heap allocation, and the value should not be modified to address desktop heap problems.

The second SharedSection value (3072) is the size of the desktop heap for each desktop that is associated with an interactive window station, with the exception of the “Disconnect” and “Winlogon” desktops.

The third SharedSection value (512) is the size of the desktop heap for each desktop that is associated with a "non-interactive" window station. If this value is not present, the size of the desktop heap for non-interactive window stations will be same as the size specified for interactive window stations (the second SharedSection value). 

Consider the two desktop heap exhaustion scenarios described above.  If the first scenario is encountered (session view space is exhausted), and most of the desktop heaps are non-interactive, then the third SharedSection can be decreased in an effort to allow more (smaller) non-interactive desktop heaps to be created.  Of course, this may not be an option if the processes using the non-interactive heaps require a full 512 KB.  If the second scenario is encountered (a single desktop heap allocation is full), then the second or third SharedSection value can be increased to allow each desktop heap to be larger than 3072 or 512 KB.  A potential problem with this is that fewer total desktop heaps can be created.


What are all these window stations and desktops in Session 0 anyway?

Now that we know how to tweak the sizes of session view space and the various desktops, it is worth talking about why you have so many window stations and desktops, particularly in session 0.  First off, you’ll find that every WinSta0 (interactive window station) has at least 3 desktops, and each of these desktops uses various amounts of desktop heap.  I’ve alluded to this previously, but to recap, the three desktops for each interactive window stations are:

·         Default desktop - desktop heap size is configurable as described below

·         Disconnect desktop - desktop heap size is 64k on 32-bit systems

·         Winlogon desktop - desktop heap size is 128k on 32-bit systems


Note that there can potentially be more desktops in WinSta0 as well, since any process can call CreateDesktop and create new desktops.

Let’s move on to the desktops associated with non-interactive window stations: these are usually related to a service.  The system creates a window station in which service processes that run under the LocalSystem account are started. This window station is named service-0x0-3e7$. It is named for the LUID for the LocalSystem account, and contains a single desktop that is named Default. However, service processes that run as LocalSystem interactive start in Winsta0 so that they can interact with the user in Session 0 (but still run in the LocalSystem context).

Any service process that starts under an explicit user or service account has a window station and desktop created for it by service control manager, unless a window station for its LUID already exists. These window stations are non-interactive window stations.  The window station name is based on the LUID, which is unique for every logon.  If an entity (other than System) logs on multiple times, a new window station is created for each logon.  An example window station name is “service-0x0-22e1$”.

A common desktop heap issue occurs on systems that have a very large number of services.  This can be a large number of unique services, or one (poorly designed, IMHO) service that installs itself multiple times.  If the services all run under the LocalSystem account, then the desktop heap for Session 0\Service-0x0-3e7$\Default may become exhausted.  If the services all run under another user account which logs on multiples times, each time acquiring a new LUID, there will be a new desktop heap created for every instance of the service, and session view space will eventually become exhausted.

Given what you now know about how service processes use window stations and desktops, you can use this knowledge to avoid desktop heap issues.  For instance, if you are running out of desktop heap for the Session 0\Service-0x0-3e7$\Default desktop, you may be able to move some of the services to a new window station and desktop by changing the user account that the service runs under.


Wrapping up

I hope you found this post interesting and useful for solving those desktop heap issues!  If you have questions are comments, please let us know.


- Matthew Justice


[Update: 7/5/2007 - Desktop Heap, part 2 has been posted]

[Update: 9/13/2007 - Talkback video: Desktop Heap has been posted]

[Update: 3/20/2008 - The default interactive desktop heap size has been increased on 32-bit Vista SP1]


Leave a Comment
  • Please add 3 and 7 and type the answer here:
  • Post
  • I found myself might suffer from the resource leak with IE7, ever found the GDI of IE7 grew up to 3xxx (and total system 93xx). I tweak the heap from 3072 to 8192, and both GDIProcessHandleQuota, USERProcessHandleQuota to 15000(Dec). While still could not help. Now I stop use IE7 and try to monitor by taskmgr.exe But I got confused because there are three columns GDI, USER, Handles ...

    (1) are GDI/USER limited by GDI/USERProcessHandleQuota ?

    (2) what's the meaning of Handles in taskmgr.exe as compared to GDI/USERProcessHandleQuota ...

    [GDIProcessHandleQuota and USERProcessHandleQuota are used to set per-process limits for GDI objects and USER objects, respectively. This caps the number of objects that a single process can use. The “handles” column in task manager refers to handles to kernel objects, rather than handles to USER or GDI objects.]
  • C:\kktools\dheapmon8.1\x86>dheapmon -s

    Desktop Heap Information Monitor Tool (Version 8.1.2925.0)

    Copyright (c) Microsoft Corporation.  All rights reserved.


     Session ID:    0 Total Desktop: (  5312 KB -    7 desktops)

     WinStation\Desktop            Heap Size(KB)    Used Rate(%)


     WinSta0\Default                    3072             10.4

     WinSta0\Disconnect                   64              4.5

     WinSta0\Winlogon                    128              8.8

     Service-0x0-3e7$\Default            512             23.8

     Service-0x0-3e4$\Default            512              4.3

     Service-0x0-3e5$\Default            512              2.4

     SAWinSta\SADesktop                  512              0.5



    This is the output I am getting after running Dheapmon on a particular PC.

    If you notice it only says 7 desktops insteas of 8.

    Could you give me any possible reason why this would be.


    [The number of desktops in a given session will vary based on what is running in that session. This isn’t unusual.]
  • Summary Opening too many tabs in Internet Explorer 7 can cause the Windows shell to switch to "Evil Mode

  • We have a Windows 2003 St, x64 with heap memory problems. Microsoft support recommended increasing the value to SharedSection=1024,20480,2048 and after 2 or 3 weeks the heap gets full. this is what we get from the dheapmon tool. Could someone help with this?

    Desktop Heap Information Monitor Tool (Version 9.0.3040.0)

    Copyright (c) Microsoft Corporation.  All rights reserved.


     Session ID:    0 Total Desktop: ( 51488 KB -    9 desktops)

     WinStation\Desktop            Heap Size(KB)    Used Rate(%)


     WinSta0\Screen-saver              20480              0.1

     WinSta0\Default                   20480              0.2

     WinSta0\Disconnect                   96              5.0

     WinSta0\Winlogon                    192              8.9

     Service-0x0-3e7$\Default           2048              5.1

     Service-0x0-3e4$\Default           2048              0.9

     Service-0x0-3e5$\Default           2048              0.2

     SAWinSta\SADesktop                 2048             96.1

     __X78B95_89_IW\__A8D9S1_42_ID      2048              0.2


    [Based on the output you provided, the SADesktop is the desktop with an exhausted heap. This desktop is used by processes launched by the Task Scheduler service. My guess would be that your server has a scheduled task that runs regularly, allocates USER objects (and thus desktop heap), and isn’t terminating, so the desktop heap is never freed. You can check to see if there are any scheduled tasks that are hanging around for longer than expected. It may help to look for processes with an open handle to the SAWinSta windowstation. You can do this by running the following from session 0 “handle.exe -a SAWinSta”. ]
  • Thanks for writing the definitive article on this subject.

    I've got a Server implemented as Service that spawns many subprocesses and runs into the 512K Desktop Heap limit, as verified via Dheapmon. All code is written in Delphi-5 and the host is running Win2000.

    I have tried setting up my subprocesses as console processes and creating with the DETACHED_CONSOLE and CREATE_NO_WINDOW flags. This  greatly reduces Desktop Heap consumption, but there is still about 3K allocated for each new process, and I would like to reduce this to zero.

    For testing, the subprocess is a minimal console app that does no real work. The only resources it's allocating are a couple of Events to control the interprocess communication with the server. Do these events and handles perhaps get allocated from the D.H.?

    Could you shed some light on what still might be getting allocated from the Desktop Heap, and suggestions on how to eliminate the heap usage altogether?

    [If a process loads user32.dll, it will use desktop heap. If you want to completely eliminate desktop heap usage, you will need to remove any dependency on user32.dll. Regarding your question about events - object manager does not use desktop heap, so event objects and their corresponding handles should not affect desktop heap usage. Event objects are allocated from nonpaged pool.]
  • Thanks for the article.  I've recently been experiencing Desktop Heap issues in Windows Vista Ultimate (32-bit).  Context menu not appearing, can't open more windows, can't display task manager, etc.  

    However, I've been running into these problems even when running only 1-2 windows.  I have AIM open, as well as an anti-virus and firewall program in the background, but that's all.  I have 2 GB RAM at ~50% utilization.  

    After a restart, I can open as many IE windows as I want (10+, although I typically only have 5-6).  However, after a short period of time, the Desktop Heap issue shows up.  As I close windows (typically 2), the problem fixes itself, but when I open another window, it reappears.  Each time I can open one less window, until I finally start seeing the problem after I have one window open (such as the one I'm typing in now).  

    I have no other windows open besides the task manager, but I can't bring up a context menu in this IE window, and can't open another window.  When it got to this point before, I was able to regain functionality by shutting down my graphics card control program (that had been running in the background), but the problem has re-occured (I never restarted the control program, so that wasn't the cause).  

    Before a few days ago, I never had this problem (regardless of how many windows I had open).  I haven't installed any new programs in the mean-time.  I know I can up the heap size, but I don't want this problem to keep appearing.

    Do you know what could be causing this problem, or any way to find out?  I can't check my heap usage because Dheapmon does not work for Vista, so I don't know what I can do.  It seems like I'm just running out of heap space regardless of how many windows I close.  Is there any way some sort of leakage could be occuring?

    [Keep in mind that desktop heap allocations are for user interface objects. Assuming desktop heap is the limiting resource here, take a look at USER object count for each process running in your session and see if anything is using a large number of USER objects. Also, can you reproduce the issue in safe mode or using the msconfig diagnostic startup mode? If not, then you can use process of elimination to determine what is starting up in normal boot that leads to this problem.]
  • Well, it seems that even for console apps, Delphi initialization apparently pre-loads user32 along with GDI32 and various other key components. We'll probably need some user32 procedures anyway, so I guess we can live with that.

    Now the problem has become, how can our server running as a service get an interactive 3072K desktop heap?

    If we run the service under LocalSystem and check the "Interacts with desktop" box, I believe we'll be assigned to WinSta0\default. Is that correct? Once there we should be able to create another desktop and use that in our CreateProcess calls, thus getting all 3072K for our child processes.

    Another alternative would be to simply run our server as an ordinary interactive app and not as a service, but we'd prefer to keep it as a service, if possible.

    However, we are currently running the service under a "power-user" userid, and are thus assigned a 512K non-interactive heap. We've tried a SetProcessWindowStation to WinSta0, but apparently that requires Admin privileges. Is there any way for a service started the way we are doing it to latch into an interactive station and get the bigger heap?

    The new Vista CreateDesktopEx function looks like it would solve the whole problem (would it?), but we're stuck with Windows 2000 Pro for the time being.

    Thanks again.

    [Yes, the “interact with desktop” checkbox allows the service to run in the interactive window station, and the service could then create more interactive desktops if needed. I wouldn’t typically recommend trying to force your non-interactive service (or its child processes) to run in an interactive windowstation simply to take advantage of the larger heap size. In general, increasing the 512K heap size (and possibly SessionViewSize too) is a better solution, assuming you can increase them sufficiently for your needs. You’ve probably already considered this, but if your service could be re-architected to reduce the number of child processes (perhaps handling the tasks with worker threads instead), you could scale back the desktop heap usage requirements. You are right about CreateDesktopEx; that may be a future solution for you.]
  • When I leave my computer on for a few days, I tend to have problems which seemed to be related to the desktop heap.

    Is it possible that applications can cause leaks with this memory - leaks that don't get dealt with when closing the process. I think our application might be causing some leaks.

    e.g. run program - no errors, close, run again, some errors, close, run again, errors even earlier, etc. To fix I then close other apps, or just logout then log in.

    (these errors are related to calls to GDI calls e.g. CreateCompatibleBitmap with the GetLastError returning ERROR_NOT_ENOUGH_MEMORY or similar)

    [Desktop heap allocations are for user interface objects, which should be cleaned up upon process termination. If GDI bitmap allocations are failing, then you are likely running out of session view space or session pool. !vm 4 in a kernel debugger will show you overall session pool usage. This could be the result of a GDI object leak (likely bitmaps).]
  • DeskTop Heap Exhaustion Ran into another mine field the other day - blew my foot right off before I could

  • Great comments!!  I have a theoretical question:  If I wanted to create 1 WindowStation and 1 Desktop and 1 IE process for 100 users, how would I go about getting the screen DC for each IE instance, so I could take the screen shot, modify it, and send it?

    Basically, I'm trying to utilize a stream of screen shots from hidden desktops for a highly optimized terminal server type application.  I only want 1 user account controlling all the WindowStations, because I don't want 100 instances of winlogon.exe in memory.  I can't use Terminal services because I have to change the network protocol on the fly.

    Any ideas?  Regular screen capture code doesn't work with a hidden windowstation..

  • I have been constantly having a problem with IE7 not being able to open a browser window over the last 6 months, or applications not loading, and I would have to reboot to clear the problem.  All would be well for a couple of weeks then this scenario repeated.  Researching, I found the dheapmon tool and have been using it, lauching it from a winapp I wrote to make it convienient to use.  Now I could see the problem, with WinSta0/default going to 99% and freezing windows, sometimes flakyness occurring at 95%.  Closing all the browser windows lowered the percent but, it would slowly climb back up even with only 1 window open, requiring a reboot.  Over time I narrowed it down to a program I wrote or IE7.  But one day I rebooted, and within the day I ran out memory (err 7) as reported by my program, and I had plenty of physical memory and page and virtual available.  I looked at the desktop heap and it was already at 99%.  I immediately suspected IE7 since my program runnning for a weeks at a time never caused such an heap shortage so quickly, indicating a serious memory leak.  Mimicking my actions, I was able to reproduce the problem 100% with IE7 being the cause.   So here is how  >> with Dheapmon running, go to a site that has lots of jpgs to view, shown as thumbnails. Read the heap, open a jpg by clicking on a thumnail, configure IE7 so that it opens a new browser window, not a tab off the same window. Note the heap again, close the jpg window, read the heap, you will have noticed that it didn't release all of the heap it used.  Repeat this process, the heap in use will start climbing with each opening and closing of the jpg windows, it seems especially hungry opening the same jpg that is already sitting in IE Content cache.  Perhaps you could persuade someone at MS to fix this bug!  Email me for any clarifications.

  • This is an excellent excellent article. This helped a lot in fixing the multiple process issues that we faced in one of our products. We start processes from Java and found that even though system resources allow, we could only start a fixed number of processes. We were using the Java Process and Runtime.exec API at that point. We are now using JNI and starting the processes by creating a desktop (CreateDesktop) and then starting processes using CreateProcess from that desktop. This has fixed our problem.

    One small question: The solution I described above worked seamlessly on Windows XP and 2000. On one 2003 machine, I had to change the Application Server service's "Log In As" to an administrative account to make the CreateProcess work (CreateDesktop worked fine). We are currently looking into this issue. Any pointers will be very helpful.

    Once again thanks for a great article.

    [I’m glad you found the article helpful. I suspect that the issue you are seeing due to tightening of ACLs in Server 2003. This article shows how to change the ACLs for a desktop - You also may need to use CreateProcessAsUser.]
  • It seems Vista has a different desktop tree. WinObj on my Vista shows that Session0 doesn't even have any window station. If so why does OpenWindowStation from the service return valid handle? And what actually handle does it return? Is it a handle of an active session window station or what?

    [ Vista actually still has the WinSta0 windowstation and the usual desktops (Default, Disconnect, Winlogon), even in session 0. WinObj should still show the windowstations for session 0 under the root \Windows\Windowstations. ]
  • Thanks for this article, Matthew. Very informative.

    In the article, you say; -


    Size if no registry value configured

    Default registry value

    Windows 2000 *

    20 MB


    I have a W2K SP4 Server. It's running Terminal Services in Remote Administration mode, and has a significant problem with the 0xC0000142 error. As it's a Mail Server, it spawns a lot of smtp32 processes. Too mnay processes, and it dies.

    DHeapMon currently shows: -

    C:\kktools\dheapmon8.1\x86>dheapmon.exe -s

    Desktop Heap Information Monitor Tool (Version 8.1.2925.0)

    Copyright (c) Microsoft Corporation.  All rights reserved.


     Session ID:    0 Total Desktop: (  3968 KB -    5 desktops)

     WinStation\Desktop            Heap Size(KB)    Used Rate(%)


     WinSta0\Default                    3072             20.5

     WinSta0\Winlogon                    128              5.2

     Service-0x0-3e7$\Default            256             59.1

     SAWinSta\SADesktop                  256              1.5

     __X78B95_89_IW\__A8D9S1_42_ID       256              0.9


    Service-0x0-3e7$\Default is the guilty party, and the utilisation shows >99% when errors occur.

    My issue is this: The SessionViewSize and SessionPoolSize keys don't appear in the Registry, only SessionImageSize.

    Can I add the missing DWORD keys, and will this help?

    [Support for the SessionViewSize and SessionPoolSize registry values was added in hotfix 318942 (ntoskrnl from Nov 25, 2003, version 5.0.2195.6797). That fix was then included in Update Rollup 1 for SP4. If you have a kernel that is of version listed above or later, you should have support for the SessionViewSize and SessionPoolSize registry values. If you add SessionViewSize and increase the size, that alone won’t affect the size of the heap for “Service-0x0-3e7$\Default”. I find it interesting that it is set to 256KB, instead of the default 512KB. I suspect someone changed the SharedSection value on this server, maybe because session view space was becoming exhausted. In any case, if you need more space for that particular desktop, you’ll have to increase its size with the SharedSection value, and if that causes session view space to become over-utilized, you can increase SessionViewSize.]
  • Hi all, The other day I had to troubleshoot an issue with a process that a specific Windows service was

Page 5 of 7 (101 items) «34567