Silver's Simple Site - Weblog - 2006 - October

Fast User Switching, the Welcome Screen and <Control>+<Alt>+<Delete>

First of all, let's start with a brief explanation of Windows' multi-layered sand-boxing and separation of logins and the user's desktop.

The basic structure is thus:

• Windows kernel and Object Manager
• "Sessions"
• Window Stations
• Desktops
• Your desktop 'n' stuff.

I.e. the kernel can maintain any number of "sessions", all of which can have any number of window stations, all of which can have any number of desktops, all of which can have, well, the windows themselves.

Certain things are sand-boxed at different levels. Named kernel objects (e.g. events, critical sections, etc.) are stored in a session-specific location. Atoms and the clipboard, for example, are part of the Window Station, where as hooks are part of the Desktop. You can only send messages between processes with the same desktop, too.

All the sessions use the same setup:

• WinSta0 (Window Station)
  • Winlogon (Desktop) AKA "secure desktop"
  • Default (Desktop)

The login screen, locked dialog and <Control>+<Alt>+<Delete> dialog all run in WinSta0\Winlogon. All your applications run in WinSta0\Default.

It should be noted that applications can create their own Window Stations and Desktops; indeed, my main system currently has 5 extra Window Stations (created by services, like Task Scheduler).

Windows NT and 2000

With Windows NT and 2000, things were simple. Session 0 was the one and only local "interactive" session (the one attached to the physical display device, physical input devices, etc.). Remote Desktop created other sessions for each remote login, as you might expect.

Windows XP

With Windows XP, two things were done to make life easier for the home user - Fast User Switching, and the Welcome Screen.

As you might have guessed, Fast User Switching utilises the "sessions" layer, allowing completely isolated user sessions. Adding this local disconnect/connection required enough work on the session system for an entire book, but it's not relevant here - what is, though, is that any session may be connected to the local physical devices.

Now that the system can do this magic, a UI is needed. Enter the Welcome Screen. The Welcome Screen (logonui.exe) runs in the secure desktop (WinSta0\Winlogon) when necessary, such as when a user logs off or locks the computer. It is interesting to note that the actual process is started by these events and does not run all the time.

• Initial system
  • Active desktop: \Sessions\0\WinSta0\Winlogon
  • Welcome Screen running. No user's logged in.
• Initial login
  • Active desktop: \Sessions\0\WinSta0\Default
  • No secure desktop processes.

At this point, I will point out that Start > Log off > Switch Users does exactly the same thing as <Win>+L (Lock).

• Locking initial login
  • Active desktop: \Sessions\0\WinSta0\Winlogon
  • Welcome Screen running. One user logged in.
• Second login
  • Active desktop: \Sessions\1\WinSta0\Default
  • Welcome Screen creates new session and connects local system to it. No secure desktop processes afterwards.
• Locking second login
  • Active desktop: \Sessions\1\WinSta0\Winlogon
  • Welcome Screen running. Two users logged in.

This is where things get more interesting. The Welcome Screen can unlock either session, but is currently still connected to the second login. This has a bearing on, for example, sound - which is still connected, so your music will keep playing when you lock the computer (as it always has done). If you unlock the initial login, however, it will be disconnected.

• Unlock initial login
  • Active desktop: \Sessions\0\WinSta0\Default
  • Welcome Screen connects to session 0, and unlocks. No secure desktop processes afterwards.

Just for fun, you can also disconnect the local session (from Task Manager, f.e.), which starts a new session just for the Welcome Screen:

• Disconnect local session
  • Active desktop: \Sessions\2\WinSta0\Winlogon
  • Welcome Screen running. Two users logged in.

There are two UI points that change other than the login screen:

• Security (<Control>+<Alt>+<Delete>) dialog.
• Locked Workstation dialog.

Most people will see that the Locked Workstation dialog is counter-productive when Fast User Switching is enabled, and thus you get the Welcome Screen instead of it.

The Security dialog is a slightly different story. Winlogon uses GINA modules show various login UI. This includes all the classic login dialogs, the locked workstation dialog and the security dialog. The GINA module can be replaced with a 3rd-party one, such as NetWare's login screens and there is no telling what a 3rd-party security dialog might do. This means that the <Control>+<Alt>+<Delete> behaviour must still exist for non-local situations, and it makes sense (for consistency) to keep showing it when you also have the classic login UI.

In other words, although being in a domain or other network environment does mean sacrificing the Welcome Screen, there is no hard and fast reason for not having the <Control>+<Alt>+<Delete> dialog when using the Welcome Screen. It's just nicer not too. ;-)

Windows Vista

With Windows Vista, things change again. GINA modules are gone, presumably replaced with something else. This is what allows it to present the Welcome Screen for domain setups, and a pretty version of the classic security dialog has been added too. Nice one.

Disclaimer: all reasons behind design decisions, why X does Y, etc. are all based on 2nd-hand data, debugging and intelligent guesswork. I make no claims to them being strictly accurate.

I was recently reading a weblog post on Linux and measuring memory used by individual applications, and it reminded me just how complex most OSes' memory management really is. Just when you think you've got it, another spanner hits you on the shin. So, let's have a look at Windows' memory management:

1. Non-paged pool
2. Paged pool
3. Driver code
4. Kernel code
5. System cache
6. Applications
7. "Available"

All physical memory (available to the OS - we're ignoring anything that the BIOS is owning here) is used by one of the 7 categories above. Applications and "available" are the most interesting ones, and there is a reason I'm quoting "available", which I'll come to later.

Items 1-5 are all kernel memory, and the remaining two user memory.

1 Non-paged pool

Drivers are allowed to allocate memory from two pools; this is the lesser-used one, and for good reason - all memory allocated from the non-paged pool is, not surprisingly, never paged out. It is useful for operations that require this, such as DMA transfers, but not a very good thing to use for normal driver allocations.

You can see the size of this pool in Task Manager (Kernel Memory, Nonpaged) or with Performance Monitor (counter \\.\Memory\Pool Nonpaged Bytes).

2 Paged pool

The normal driver memory pool; all this memory can be paged out at the kernel's whim, and is ideal for storing driver structures that aren't used by hardware.

You can see the total allocated size of this pool in Task Manager (Kernel Memory, Paged) or with Performance Monitor (counter \\.\Memory\Pool Paged Bytes). You can see the currently paged-in size with Performance Monitor (counter \\.\Memory\Pool Paged Resident Bytes).

3 Driver code

This is the pageable memory being used to hold drivers, both their code and data pages.

You can see the size of this with Performance Monitor (counters \\.\Memory\System Driver Total Bytes and \\.\Memory\System Driver Resident Bytes).

4 Kernel code

This is the pageable memory being used to hold the kernel's own code (e.g. nsoskrnl.exe, hal.dll, boot drivers and boot file systems).

You can see the size of this with Performance Monitor (counters \\.\Memory\System Code Total Bytes and \\.\Memory\System Code Resident Bytes).

5 System cache

This is the area of kernel memory used for caching, mostly the file cache. This memory is never paged out, it is just freed (paging out a cache would be rather pointless).

You can see the size of this with Performance Monitor (counters \\.\Memory\System Cache Resident Bytes).

6 Applications

This area is defined by one book as "total memory minus the other 6 components", which is hardly surprising - it is a really hard number to track, and for various reasons there is no Performance Monitor counter for this. |\.\Process(_Total)\Working Set will usually come close, but can just as easily be larger than the real applications usage as it can smaller.

The reason it is so hard to calculate this value is simple: shared memory. This is the same reason that ps is "wrong" on Linux, as explained pretty well in the article I mentioned at the start of this post. For exactly the same reasons, Task Manager and Performance Monitor will "lie" about the memory usage.

Shared memory can be an executable (EXE, DLL, etc.) loaded into more than one process space, or specially allocated "shared memory" which is sometimes used for inter-process communications.

Each process has a working set (counter \\Process(*)\Working Set) which reports the total amount of physical memory used by that process. Task Manager calls this column "Mem Usage". Some of this memory is almost certainly shared with other processes, and thus the total of all working sets will be greater than the actual amount used.

Each process also has private bytes (counter \\Process(*)\Private Bytes) which reports the amount of allocated memory specific to this process, e.g. malloc and other direct allocations. Task Manager calls this column, rather confusingly, "VM Size". None of this memory is shared, but you also cannot tell how much of the working set is private bytes, and how much is shared bytes. (Note that a DLL loaded into a single process is still 'shared' memory, and not private bytes, because it can be shared.)

Process Explorer tries to help things by listing "WS Private", "WS Shareable" and "WS Shared", which it does by collecting data from all processes via a kernel driver. In this case, WS Private + WS Shareable = Working Set. WS Shared is just how much of the memory that can be shared is actually being shared.

I should also note that drivers can allocate memory which falls into this group, and is impossible to track as far as I know. Very few can, or do; the most notable example is Virtual PC, which allocates the VMs' memory like this.

7 "Available"

You can see the size of this group in Task Manager (Physical Memory, Available) or with Performance Monitor (counter \\.\Memory\Available Bytes).

It is not, however, as simple as it appears. Not all of the "available" memory is free memory, and therein lines the subtlety.

"Available" memory is made up 3 types:

• Standby List
• Free List
• Zeroed List

In Windows Vista, there are some new Performance Monitor counters to measuring the size of these three types, \\.\Memory\Standby Cache Core Bytes, \\.\Memory\Standby Cache Normal Priority Bytes, \\.\Memory\Standby Cache Reserve Bytes and \\.\Memory\Free & Zero Page List Bytes).

When Windows want to trim a process' working set, the trimmed pages are moved (usually) to the Standby List. From here, they can be brought back to life in the working set with only a soft page fault (much faster than a hard fault, which would have to talk to the disk). If a page stays in the standby List for a long time, it gets freed and moved to the Free List.

In the background, there is a low priority thread (actually, the only thread with priority 0) which takes pages from the Free List and zeros them out. Because of this, there is usually very little in the Free List.

All new allocations always come from the Zeroed List, which is memory pages that have been overwritten with zeros. This is a standard part of the OS' cross-process security, to prevent any process ever seeing data from another. If the Zeroed List is empty, Free List memory is zeroed and used or, if that is empty too, Standby List memory is freed, zeroed, and used. It is because all three can be used with so little effort that they are all counted as "available".

Observed Behaviours

With all that above information, you might now be able to guess what it going on when you minimize an application and see "Mem Usage" in Task Manager drop by a large amount, and why restoring the application soon after doesn't usually involve any disk paging.