How Windows XP Screen Lock Restricted System Access

When a user locked Windows XP, the operating system prevented unauthorized access by isolating the user’s active graphical interface, trapping hardware inputs, and shifting authentication control to secure system processes. Rather than suspending running programs, Windows XP decoupled user software from the physical monitor and input devices, transferring session control to an isolated desktop environment managed by the Winlogon subsystem until valid credentials were provided.

Desktop Isolation via Window Stations

Windows XP utilized an architectural security boundary based on Window Stations and Desktops. User activities took place on the interactive window station (WinSta0) on a desktop named Default. When the screen was locked—either manually via the Windows Key + L shortcut or automatically via a password-protected screensaver—the operating system switched the active display context from the Default desktop to the Winlogon desktop.

Because Windows NT architecture strictly prohibits standard user-mode applications on one desktop from sending messages, setting hooks, or accessing window handles on another desktop, running applications on the Default desktop were immediately shielded from view and physically blocked from receiving keyboard or mouse input.

Input Capture and Winlogon

The winlogon.exe system process held exclusive control over the locked interface. Working alongside the Graphical Identification and Authentication dynamic link library (MSGINA.dll), Winlogon took control of the input queue.

All raw hardware input from the keyboard and mouse was diverted exclusively to the lock dialog or the Welcome Screen. Global keyboard hooks and accessibility utilities created by third-party software were disabled or blocked from capturing keystrokes on the secure desktop, preventing malware from intercepting credentials entered during the unlock phase.

The Secure Attention Sequence (SAS)

In environments configured to require the classic logon interface, unlocking the computer required the Secure Attention Sequence: Ctrl + Alt + Delete. In Windows XP, this specific key combination was intercepted directly by the operating system kernel (ntoskrnl.exe). The kernel reserved this sequence exclusively for winlogon.exe. Because user applications could not intercept or fake this combination, the operating system guaranteed that the prompt requesting the password was authentic and not a spoofed interface running in the background.

Background Execution and API Restrictions

While the locked state severed graphical interaction, background processes continued executing under their existing security tokens. However, the operating system restricted these processes from interacting with the user:

• Display Output: Direct rendering to the screen was obscured or redirected away from the display adapter's front buffer.
• Clipboard Isolation: The clipboard was locked to the active desktop, stopping automated clipboard sniffers from reading data during the locked state.
• Screen Scraping Prevention: Applications lacked the privilege to read the pixel data of the Winlogon desktop, preventing unauthorized screenshots of the unlock interface.

Credential Verification via LSASS

To restore access, the unlock prompt passed entered credentials to the Local Security Authority Subsystem Service (lsass.exe). LSASS validated the password against the local Security Accounts Manager (SAM) database or contacted an Active Directory domain controller. Only upon successful cryptographic validation did Winlogon instruct the graphics subsystem to switch the active context back to the Default desktop, returning interactive control to the authenticated user.