Session Manager, Winlogon, and the shell

Startup & shutdown named this as the stage where Windows "turns a running kernel into a usable logged-in environment." This chapter is that stage in detail — the earliest user-mode processes, and the handoff into the sign-in experience covered fully back in Winlogon, LogonUI, and session sign-in.

SMSS: the first process that isn't the kernel

Once kernel and Executive initialization completes, the very first user-mode process Windows creates is SMSS (Session Manager Subsystem). Its job is foundational, one-time infrastructure work: creating the earliest session objects, and — critically — starting the processes that form the foundation of each session's environment, including CSRSS (the user-mode half of the Win32 environment, covered in CSRSS, Win32k, and session UI plumbing) for each session that needs it.

Session 0: services, isolated from any human

One of SMSS's earliest and most architecturally significant acts is establishing Session 0 — a non-interactive session, with no signed-in user attached, that hosts every Windows service. This isolation, present since Windows Vista, exists specifically as a security boundary: it prevents a compromised or malicious service from drawing UI on, or capturing input from, whatever interactive session a real human is actually using — the same principle GUI & windowing and Services & background infrastructure both reference from their own angles.

Winlogon and the transition to a usable desktop

After Session 0 and foundational session infrastructure are established, an interactive session gets created for the first (or next) human user, and Winlogon takes over — coordinating the secure attention sequence, sign-in UI, and authentication pipeline covered in full in Winlogon, LogonUI, and session sign-in. Once authentication succeeds, Winlogon hands off to launching the configured shell — ordinarily Explorer.exe — which is what actually renders the taskbar, desktop icons, and Start menu people recognize as "Windows."

Why a successful login is not the same as a working desktop

This is the single most practically important point this chapter can make: authentication succeeding and the desktop environment fully initializing are two separate achievements, and the second can fail even when the first succeeds perfectly. A user can authenticate correctly — the credential was valid, the token was created, Winlogon's job is done — and still end up staring at a black screen, if the shell process itself fails to start, crashes immediately, or hangs during its own initialization. Diagnosing "I can't get to my desktop" correctly starts by asking which of these two genuinely separate stages actually failed.

A worked example: a black screen after apparently successful login

A black screen appearing immediately after what looked like a normal, successful sign-in is a classic, specific symptom pointing at this exact seam: the kernel is running fine, session infrastructure came up correctly, authentication succeeded — and the problem is isolated to shell startup specifically (a corrupted Explorer configuration, a failing shell extension, a profile-loading problem). Recognizing this narrows troubleshooting dramatically, away from boot-level or authentication-level causes and toward the much smaller, later-stage set of things that could interfere with Explorer actually launching and rendering successfully.

A common mistake

Treating "I can log in" and "my desktop works" as evidence of the same underlying health check conflates two genuinely independent stages of the startup sequence. A machine can have a perfectly healthy kernel, perfectly functioning authentication, and still have a broken user experience entirely confined to shell startup — a distinction worth keeping in mind before assuming a "login" problem must originate somewhere in authentication itself.

Where this connects

• Winlogon, LogonUI, and session sign-in covers the authentication portion of this sequence in complete detail.
• CSRSS, Win32k, and session UI plumbing covers exactly what SMSS is creating when it stands up CSRSS for a new session.