Today we are going to briefly go over the basics of some concepts that can be pretty confusing even at the best of times - Sessions, Desktops and Windows Stations.  So let's dive right in ...

A session consists of all of the processes and other system objects that represent a single user’s logon session.  These objects include all windows, desktops and windows stations.  A desktop is a session-specific paged pool area and loads in the kernel memory space.  This area is where session-private GUI objects are allocated from.  A windows station is basically a security boundary to contain desktops and processes.  So, a session may contain more than one Windows Station and each windows station can have multiple desktops.

Only one windows station is permitted to interact with the user at the console; this is called Winsta0. Under Winsta0 there are three desktops loaded: Winlogon (the logon screen), Default (the user desktop) and Disconnect.  All three of these have separate logical displays, which is why your main desktop disappears if you lock the workstation.  When you lock the workstation, the display switches from Default to Winlogon and there is no user interaction between the two.  In Windows Vista this is even a bit more extreme.  When you get a UAC prompt for instance, it takes a screenshot of your Default desktop and then displays it dimmed out behind the UAC window in the foreground.  The UAC window is part of the Secure Desktop (new for Vista and similar to the logon desktop) and will not allow you to interact with the Default desktop until you provide input.

Other windows stations exist that do not interact with the user.  For example, services load under the ‘Service-0x0-3e7$’ non-interactive windows station. The exceptions to this are services that need to interact with the console user, so these load into Winsta0 instead.

All pages mapped to a specific user use the same memory pages, but each user has their own session space mapped in virtual memory. Session space is divided into four different areas:

  • Session Structure – Memory management control structures including session Working Set List.
  • Session Image Space – holds a private copy of Win32k.sys modified data, a single copy of Win32k.sys code and unmodified data and various session drivers.
  • Session View Space – session mapped views including desktop heap
  • Session Paged Pool – paged pool memory used for this session

As mentioned above, a desktop is an object under which a logical display surface loads.  This contains windows, menus and hooks. Session 0 is the base session where services run and is typically also the console session.  In Windows Vista this has been changed to exclusively run services, and the console session is typically Session 1.  The diagrams below show the relationships between sessions, windows stations, desktops and services in Windows Vista as compared to earlier operating systems (this is from our earlier post on Session 0 Application Compatibility Issues)

image
Session 0 in Windows XP / Windows Server 2003

image
Session 0 / Session 1 in Windows Vista

So now let's dig a little deeper using an example.  In the diagram below, we are looking at Session 0 with a user logged in named Bob.  As you can see, Winsta0 contains both processes from the user console session as well as any service that is marked as Interactive.  In this case, that includes Winlogon.exe, Explorer.exe and others that need to interact with the user.  The Service-0x0-3e7$ windows station owns any service that loads under Local System and is non-interactive.  In this case I have shown Services.exe.  As you can see by the connecting bars, it is possible for processes from different virtual sessions to load into a single windows station.  The SQL process loads under its own windows station and credentials, so it is not included in either of the other windows stations.

image

So, to reiterate what is going on in the diagram above:

  1. The whole diagram is Session 0.
  2. Processes that start under the Bob account all load in Winsta0.
  3. Interactive processes that start under Local System load in Winsta0
  4. Non-interactive processes that start under Local System load in the Service-0x0-3e7% windows station
  5. Processes that start under their own credentials start in their own windows station (like SQL)

A single desktop object will have a single desktop heap set aside for it.  This heap stores various user interface objects, such as the windows, menus and hooks.  When an application needs to draw a user interface object, it calls User32.dll to allocate this object. As I am sure you can guess, each of these interface elements requires resources out of desktop heap.  If the desktop heap becomes depleted, you will get symptoms such as a corrupt display or other anomalies.  Also, if the Session View Space becomes depleted, it will not be able to create more desktop heaps. Either of these of course is very bad. This is partially why you can still get Out Of Memory errors even on a machine with a lot of free RAM.

When this occurs, you may get initialization errors in addition to visual corruption.  A typical error you may see is 0xc0000142, which means STATUS_DLL_INIT_FAILED.  You can tell if the problem is with a single desktop heap or the entire session based on the symptom; if the desktop heap is depleted, you will only see the problem with processes that are out of heap.  If the Session View Space is depleted, you will have a problem with that entire session.

Win32k.sys has a fixed kernel address space of 48MB set aside for desktop heaps.  With Terminal Services, this space is shared with per-session storage, so that leaves 20MB for desktop heaps.  So, as you can see, it is possible to run out of desktop heap resources easier on a terminal server than a standard machine.  This is true for pre-Vista operating systems.  In Windows Vista and Windows Server 2008 desktop heap is allocated dynamically and the 48MB constraint is not there.

There is a registry setting that allows limited modification of how this memory is handled: In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems key, look for the

Windows value.  There's a long string for this value that will look similar to this: %SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,3072,512 Windows …

The portion of interest is "SharedSection=1024,3072,512".  The three values under Shared Section determines how much memory in kilobytes (KB) is allocated to each component of the desktop heap.  At this point, there is a major caveat here: Please do not modify these values on a whim. Changing the second or third value too high can put you in a no-boot situation due to the kernel not being able to allocate memory properly to even get Session 0 set up.  Values up to about 8mb are generally safe, but may be pushing it, and frankly settings that high are not usually needed unless an installed program is misbehaving in the first place.  We recommend raising these values in 512kb increments and only enough to alleviate whatever problem you are experiencing.

The first value is the shared heap size, common to all desktops. It's used to store the global handle table and shared system settings. By default, it's set to 1024KB. You generally do not need to modify this value.  The second value is the desktop heap size for each desktop associated with the "interactive" window station.  It is used to store user objects like hooks, menus, strings and windows.  By default, it's set to 3072KB.  The more users that log into the system, the more desktops are created.  Consequently, the total "interactive" desktop heap size will increase to reflect the number of desktops created.  However, each desktop will only have an "interactive" desktop heap of 3072KB.  The third value is the desktop heap size for each desktop associated with the "non-interactive" window station.  By default, it's set to 512KB. But if this value is not present, the size of the "non-interactive" window station will be the same as that of the "interactive" window station.

Every service process created under a user account will be given a new desktop in a "non-interactive" window station created by the Service Control Manager (SCM).  Therefore, each of these services will consume the amount of desktop heap, as specified in the third SharedSection value.  The total desktop heap used in both interactive and non-interactive window stations must fit into the 48MB system-wide buffer.  Consequently, decreasing the second or third SharedSection values will increase the number of desktops that can be created. However, it will reduce the number of hooks, menus, strings and windows that can be created within each desktop.  Conversely, increasing the second of third SharedSection values will reduce the number of desktops that can be created and increases the number of hooks, menus, strings and windows that can be created within each desktop.  Also, increasing the third SharedSection value will reduce the number of user account services that can run successfully on the system.

So, hopefully this has shed at least a little light on how Sessions, Windows Stations and Desktops interact with each other.  The following MS articles all talk about various aspects of this subject.  There's also an in-depth blog post on the NT Debugging blog on Desktop Heap.

Additional Resources: