Back to Engineering Journal
Windows Internals // Architecture 12 min read March 2026

How to Access Windows Session 0 & Lock Screens Remotely Without Black Screens

An engineering deep-dive into Windows desktop isolation, Winlogon secure desktops, token duplication, and why most remote desktop tools fail on lock screens.

If you have ever used a standard remote access tool or VNC client to connect to an unattended Windows machine, you have likely encountered the frustrating “Black Screen” symptom: as soon as the user logs off, the workstation locks via Win + L, or a User Account Control (UAC) elevation prompt appears, the remote video feed turns pitch black and keyboard inputs are dropped.

This article explains the low-level Windows security architecture responsible for this behavior and details how modern platforms like SDAgent resolve it using a dual-process Session 0 service model with token duplication.

The Root Cause: Windows Session Isolation

Starting in Windows Vista and maintained in Windows 10 and 11, Microsoft isolated services into Session 0 to prevent Shatter attacks. Active user desktops run in Session 1+. Furthermore, within a user session, Windows maintains multiple desktops: Default, Winlogon (the lock screen), and Screen-saver.

Why Standard Remote Desktop Tools Fail on Lock Screens

Most lightweight remote desktop utilities run as a single executable in the context of the logged-in user (Session 1). When the user locks their machine or a UAC prompt opens:

  1. The Windows operating system switches the active desktop from Default to Winlogon (Secure Desktop).
  2. User-space applications are denied access to the Winlogon desktop handle (OpenDesktop returns ERROR_ACCESS_DENIED).
  3. DirectX DXGI Output Duplication or GDI screen capture calls fail immediately, resulting in a black frame buffer.
  4. Keyboard and mouse simulation via SendInput are discarded by the kernel security boundary.

The Solution: Dual-Process Architecture (WinHostSvc + Worker)

To achieve reliable, 24/7 unattended access across all desktop states, SDAgent divides its host implementation into two cooperating binaries:

1. WinHostSvc.exe (The Session 0 Service)

Installs as an auto-start Windows Service running under NT AUTHORITY\SYSTEM. Because it holds SYSTEM privileges, it can query terminal services APIs (WTSGetActiveConsoleSessionId) and duplicate primary access tokens.

2. WinHostWorker.exe (The Session 1+ Capture Engine)

Spawned dynamically by the service into the active interactive console session using CreateProcessAsUser with a duplicated system token. When a desktop transition occurs (monitored via SetWinEventHook or WTSRegisterSessionNotification), the worker re-acquires the active desktop handle (OpenInputDesktop) and binds the DirectX DXGI capture pipeline immediately.

Injecting Software SAS (Ctrl + Alt + Del)

Standard Windows APIs forbid sending Ctrl + Alt + Del through normal SendInput or keybd_event to prevent malicious credential harvesting.

Because SDAgent's service runs under NT AUTHORITY\SYSTEM, it can invoke the Windows Software Secure Attention Sequence (SAS) API directly via SendSAS(FALSE). When a technician clicks the “Ctrl+Alt+Del” button in the SDAgent in-browser floating toolbar, the web viewer sends an authenticated command over WebSockets, and the service reliably dispatches the hardware SAS sequence to the Winlogon desktop.

Unattended Access Done Right

Test SDAgent Unattended Fleet Access

Never get locked out by a remote Windows lock screen again. Deploy the lightweight SDAgent host daemon and connect directly from your browser.

Learn More About SDAgentCompare vs AnyDesk