Window stations & desktops

GUI & windowing introduced window stations and desktops as nested containers. This chapter goes one level deeper: what they're securable against, and what actually happens, mechanically, during a desktop switch.

Winsta0: the one window station most people ever see

A logged-on interactive user's session is associated with an interactive window station, conventionally Winsta0 — the "0" is historical, from a time when multiple numbered window stations were a more visible concept. Winsta0 holds:

• The clipboard, shared by every desktop and app within that window station.
• The atom table, a table of interned short strings — historically used heavily for window class name registration, so that "RegisterClass" doesn't have to compare full strings repeatedly.
• One or more desktops.

Non-interactive services, running in Session 0, typically get a non-interactive window station instead — one with no visible display attached, which is exactly why a service that tries to MessageBox the user gets nothing: there's no interactive desktop for that dialog to appear on, by design, not by bug.

The desktops inside Winsta0

Within the interactive window station, Windows creates (and switches between) several desktops:

• Winlogon — where the secure logon UI and secure UAC/consent prompts run.
• Default — where Explorer and ordinary applications live; this is "the desktop" in the everyday sense.
• ScreenSaver — a dedicated desktop the screen saver process runs on, isolated from whatever was on Default when the screen locked.

Each desktop has its own object namespace for windows, menus, and hooks. A window on one desktop is invisible to and cannot be enumerated from another — a hook or automation tool attached to Default genuinely cannot see or interact with anything happening on Winlogon, because they're different securable objects, not just different views of the same one.

Watch the switch happen

This is the entire mechanism behind the "screen dims and a prompt appears alone" experience: Windows doesn't overlay a special dialog on top of your normal desktop — it changes which desktop is the input desktop (the one actually receiving keyboard/mouse input and being displayed), runs the sensitive UI on a desktop nothing else has access to, and switches back once you've responded.

Why this is a real security boundary, not cosmetic

The reason this exists at all: if the elevation or logon prompt just drew as an ordinary window on the Default desktop, any other process already running there — including malware — could in principle enumerate it, send it synthetic input, or overlay a convincing fake on top of it (a "shatter attack" or click-jacking-style UI spoof). By running the prompt on a desktop that ordinary processes have no handle to and cannot enumerate windows on, Windows removes that entire attack surface. This is also why remote-desktop or accessibility software sometimes needs explicit, documented support for "interact with the secure desktop" — reaching it isn't an oversight to route around, it's the point.

A common mistake

It's easy to think of a desktop as just "wallpaper plus icons," a purely visual arrangement. In reality a desktop is a full securable kernel object with its own access control list, its own window and hook namespace, and its own enumeration boundary — the same kind of object security-descriptor-and-ACL model covered in Security descriptors & ACLs applies here too, just applied to GUI containers instead of files or registry keys.

Where this connects

• USER & GDI objects covers what actually gets created inside a desktop once a process is attached to one.
• CSRSS, Win32k, and session UI plumbing explains which component creates these objects and where the user-mode/kernel-mode line falls within the GUI stack.
• Session Manager, Winlogon, and the shell covers how a session — and its first window station and desktop — get created in the first place, at logon.