Winlogon, LogonUI, and session sign-in

Authentication & logon described the logon pipeline in the abstract. This chapter is the concrete walk-through: which processes actually run, in what order, between a secure attention sequence and a usable desktop.

Secure attention: why Ctrl+Alt+Del still exists

The classic Ctrl+Alt+Del ("secure attention sequence," or SAS) exists to answer a specific threat: how do you know the login prompt on your screen is really Windows', and not a fake window drawn by malware to steal your password? The trick is that Ctrl+Alt+Del is trapped by the kernel and cannot be intercepted or simulated by an ordinary user-mode application — no untrusted process can generate that key combination or catch it before Windows does. Pressing it forces a switch to the secure desktop (see Window stations & desktops), which only trusted, signed system components can draw on. Modern Windows relaxes the requirement to press it in common configurations, but the secure-desktop mechanism it triggers is exactly the same one still protecting UAC prompts today.

The cast of processes, in order

1. Wininit.exe / Winlogon.exe — created early by the Session Manager as part of standing up a new session (see Session Manager, Winlogon, and the shell). Winlogon is the coordinator for the whole sign-in sequence, but it deliberately doesn't gather credentials itself.
2. LogonUI.exe — a separate process Winlogon launches specifically to render the sign-in interface: account tiles, password fields, PIN entry, whatever the configured credential providers offer. Keeping this UI in its own process, rather than folding it into Winlogon, means a crash in the sign-in UI doesn't take down the coordinator responsible for the rest of the sequence.
3. Credential providers — pluggable COM components LogonUI hosts, each responsible for one authentication method's UI and for packaging what the user entered into a form the authentication pipeline can consume.
4. LSASS — receives the packaged credential and runs the actual authentication pipeline, consulting whichever authentication package applies.

On success, control returns to Winlogon, which is responsible for the transition off the secure desktop and into the user's own session: attaching the newly authenticated identity's token to the initial shell process, switching the visible desktop from Winlogon back to Default, and starting the configured shell (ordinarily explorer.exe).

Why Winlogon delegates instead of doing it all itself

Splitting "coordinate the sequence" (Winlogon), "render the prompt" (LogonUI), "package credentials" (credential providers), and "validate them" (LSASS) into separate components is the same layering principle running through the rest of this course: each piece can be replaced or extended independently. This is precisely how Windows Hello, smart-card logon, and third-party credential providers were added over the years without rewriting Winlogon itself — they're new credential providers plugged into an existing coordination point, not forks of the sign-in system.

A worked example: what a locked screen actually is

Locking a session (Win+L, or an idle timeout) doesn't log you out — it switches the active desktop back to a Winlogon-controlled secure desktop and presents LogonUI again, while your original session, its token, its running processes, and the Default desktop's window state all remain exactly as they were, simply not the visible or input-receiving desktop. Unlocking is the same handoff described above, run again, without needing to tear down and recreate the session.

A common mistake

It's easy to think of Winlogon as "the login window" itself. In the actual architecture, Winlogon never draws a password box — that's LogonUI's job, running as its own process specifically so the always-privileged, always-running coordinator isn't also the thing most likely to be rendering complex, potentially crashable UI. Winlogon's real role is closer to a state machine: deciding when to show the secure desktop, when a logon attempt succeeded, and when to hand off to the user's shell.

Where this connects

• Session Manager, Winlogon, and the shell covers how Winlogon itself gets created, as part of the wider boot-to-desktop sequence.
• LSASS, SAM, and local security policy picks up exactly where this chapter's step 4 leaves off.
• Access tokens covers what Winlogon actually attaches to the new shell process once sign-in succeeds.