A Remote Desktop user on Windows Server 2019 may occasionally connect successfully but see only a completely black screen. In other cases, the user works normally for several hours, the RDP connection suddenly stops responding, and every subsequent reconnection returns to the same black screen.

This problem is especially important on a Remote Desktop Services (RDS) server because simply rebooting the server or resetting the affected session can interrupt other users and may destroy unsaved work.

This article explains how to diagnose the issue systematically, distinguish a network disconnect from a damaged Windows session, recover the desktop where possible, and determine the underlying cause.

For privacy, all computer names, usernames, session IDs, IP addresses, and process IDs in this article are fictional examples.

Example Scenario

Consider a Windows Server 2019 RDS server:

Server: ACCT-RDS01
Domain: CORP
Affected user: ACCUSER11
Session ID: 27

The user reports:

Remote Desktop suddenly went black and stopped working. After reconnecting, RDP accepts the connection but displays only a black screen.

Other users connected to the same server continue working normally.

This distinction is important.

If 20 users are connected and only one user's session is black, rebooting the entire server should generally not be the first troubleshooting step.

Understanding an RDP Black Screen

A black RDP screen does not necessarily mean the server is down.

RDP consists of several components working together:

• Network connection
• RDP transport
• User authentication
• Windows session
• User profile
• Windows shell
• Desktop Window Manager
• RDP graphics channels
• Clipboard and device-redirection channels
• Printer redirection
• Applications running inside the session

The server can therefore be completely healthy while one user's desktop is unusable.

Similarly, the RDP connection itself can drop while all applications in the Windows session continue running.

Step 1: Check the User's RDP Session

From an elevated Command Prompt or PowerShell on the server, run:

quser ACCUSER11

Example:

USERNAME     SESSIONNAME     ID     STATE     IDLE TIME     LOGON TIME
accuser11                    27     Disc      1             25-Jul-26 10:24 AM

The important field is:

STATE = Disc

Disc means Disconnected.

It does not mean that the user has logged off.

The Windows session may still contain Excel, accounting software, browsers, documents, and other applications.

This is why immediately resetting a disconnected session can be dangerous.

Step 2: Examine All RDS Sessions

Run:

qwinsta

Example:

SESSIONNAME       USERNAME          ID     STATE
services                             0     Disc
console                              1     Conn
rdp-tcp#101       Administrator      2     Active
rdp-tcp#82        accuser08         21     Active
rdp-tcp#94        accuser09         23     Active
                   accuser11        27     Disc
rdp-tcp#103       accounts01        28     Active
rdp-tcp#104       accounts02        29     Active

If many users remain Active and only one user is Disc, this is strong evidence against a complete RDS server failure.

Investigate the affected session before considering a server reboot.

Step 3: Check Processes Running in the Affected Session

Suppose the affected Session ID is 27.

Run:

Get-Process -ErrorAction SilentlyContinue |
Where-Object {$_.SessionId -eq 27} |
Sort-Object WorkingSet64 -Descending |
Select-Object ProcessName,Id,SessionId,
@{N="RAM_MB";E={[math]::Round($_.WorkingSet64/1MB,1)}},
CPU |
Format-Table -AutoSize

You might find:

ProcessName             Id      SessionId   RAM_MB
-----------             --      ---------   ------
EXCEL                   54120   27          325.0
dwm                     22840   27           95.2
ShellExperienceHost     44328   27           82.7
ctfmon                  17352   27           54.8
sihost                  71340   27           25.4
RuntimeBroker           36620   27           21.8
rdpclip                 60280   27           11.7
csrss                   93840   27           11.0
winlogon                88712   27           10.1

But one process is conspicuously absent:

explorer.exe

That is an extremely important finding.

Why Missing Explorer.exe Can Cause a Black RDP Desktop

explorer.exe is the normal Windows graphical shell.

It is responsible for major parts of the interactive desktop, including:

• Desktop
• Taskbar
• Start menu integration
• Notification area
• File Explorer
• Normal shell environment

A session can therefore remain alive while the normal desktop shell is missing.

You may still see processes such as:

winlogon.exe
dwm.exe
csrss.exe
sihost.exe
ShellExperienceHost.exe
rdpclip.exe
EXCEL.EXE

but the user may see only a black desktop.

This is fundamentally different from the entire RDS session crashing.

Step 4: Don't Immediately Reset the Session

Administrators frequently respond to a stuck RDP user with:

reset session 27

This can restore access because the next login starts a fresh Windows session.

However, it also terminates the existing session.

If the user has an active process such as:

EXCEL.EXE

there may be unsaved work.

Therefore, first determine what is still running.

A disconnected desktop does not mean its applications have stopped.

Step 5: Attempt to Recover Explorer Without Logging Off

If the user can reconnect to the black desktop, press:

Ctrl + Alt + End

This is the RDP equivalent of sending the Windows security sequence to the remote session.

If the Windows Security screen appears, open Task Manager.

Alternatively try:

Ctrl + Shift + Esc

In Task Manager select:

File → Run new task

Enter:

explorer.exe

and press OK.

If the taskbar and desktop immediately return, the immediate black-screen condition was associated with the missing Windows shell.

The user should save important work before any further troubleshooting or logoff.

Starting Explorer in a Specific RDP Session

An administrator should be careful when starting:

explorer.exe

from their own administrative session.

The goal is to start Explorer in the affected user's interactive session, not the administrator's session.

If Microsoft Sysinternals PsExec is already available and appropriate for your environment, a session-specific launch can be performed using the affected session ID, for example:

psexec -i 27 -d C:\Windows\explorer.exe

The critical argument is:

-i 27

because it specifies the interactive session.

Whenever possible, however, launching explorer.exe from Task Manager inside the affected RDP session is simpler.

Step 6: Determine Whether RDP Is Actually Disconnecting

A black screen can also follow an underlying network/RDP transport failure.

Windows Server 2019 provides useful RDS event logs.

Check:

Event Viewer
→ Applications and Services Logs
→ Microsoft
→ Windows
→ TerminalServices-LocalSessionManager
→ Operational

Or use PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" -MaxEvents 200 |
Where-Object {$_.Message -match "accuser11|27"} |
Select-Object TimeCreated,Id,Message |
Format-List

You may discover a pattern such as:

14:29:14  Session 27 disconnected
14:29:25  Session 27 reconnection succeeded
14:30:55  Session 27 disconnected
14:30:59  Session 27 reconnection succeeded
14:34:15  Session 27 disconnected
14:35:40  Session 27 reconnection succeeded

This proves that the RDP connection is repeatedly disconnecting and reconnecting.

It does not, by itself, prove why.

Understanding Important RDS Event IDs

Several events are useful when diagnosing RDP session problems.

Event ID 21 – Session Logon Succeeded

The user successfully logged on.

Event ID 22 – Shell Start Notification

Windows received notification that the user's shell started.

If Event 22 appears at login but explorer.exe is missing later, Explorer may have subsequently terminated, crashed, or been replaced/affected by another shell-related condition.

Event ID 23 – Session Logoff

The Windows session actually logged off.

Event ID 24 – Session Disconnected

The RDP connection was disconnected, but the user session may remain alive.

Event ID 25 – Session Reconnection Succeeded

A client successfully reconnected to an existing session.

These distinctions are critical when investigating black-screen complaints.

Step 7: Examine RdpCoreTS Events

For deeper RDP transport diagnostics, examine:

Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational

Example PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" -MaxEvents 300 |
Where-Object {
    $_.TimeCreated -ge (Get-Date "2026-07-25 14:25:00") -and
    $_.TimeCreated -le (Get-Date "2026-07-25 14:45:00")
} |
Select-Object TimeCreated,Id,LevelDisplayName,Message |
Format-List

In an actual connection problem, administrators may find messages such as:

TCP socket READ operation failed
TCP socket WRITE operation failed
The server has terminated main RDP connection with the client

This changes the investigation significantly.

It means the black-screen incident may involve both:

1. An RDP transport/network interruption
2. A damaged or incomplete desktop after reconnecting

These should be investigated separately.

Step 8: TCP vs UDP in Remote Desktop

Modern RDP can use multiple transport mechanisms.

If logs show messages such as:

No UDP Packets Received

RDP may be operating over TCP instead.

This does not automatically indicate a fault. RDP can work over TCP.

However, unstable networks can cause symptoms such as:

• Frozen RDP screen
• Sudden black screen
• Reconnecting message
• Session disconnect
• Input stops responding
• Frequent automatic reconnect
• Connection terminated

Potential causes include:

• Packet loss
• Wi-Fi instability
• ISP problems
• Firewall behavior
• Router/NAT problems
• VPN instability
• WAN failover
• Network adapter problems
• Security software filtering
• RDP transport problems

Step 9: Test the Client Network

On the affected user's local computer, continuously ping both the RDP server and a stable Internet endpoint.

For example:

ping -t SERVER_IP

and separately:

ping -t 8.8.8.8

When RDP fails, examine both.

If both fail simultaneously, investigate the client's LAN, Wi-Fi, router, or Internet connection.

If Internet ping continues but the server becomes unreachable, investigate the path to the RDS server.

If both remain stable while RDP fails, investigate the RDP client, transport, graphics, device redirection, security software, and server-side RDP components.

Ping is only one diagnostic signal; a successful ICMP response does not prove that the RDP TCP connection itself is healthy.

Step 10: Test from Another Computer or Network

This is one of the most effective isolation tests.

Try combinations such as:

A mobile hotspot can be particularly useful as a temporary alternate network for testing.

Step 11: Test RDP Device Redirection

RDP can redirect local resources into the server session, including:

• Printers
• Clipboard
• Drives
• Audio
• Smart cards
• USB/device resources
• Plug-and-Play devices

If RdpCoreTS contains repeated virtual-channel creation failures, test the connection with unnecessary redirection disabled.

Open:

mstsc

Select:

Show Options → Local Resources

Temporarily disable nonessential redirections, especially:

• Printers
• Clipboard
• Drives
• Smart cards
• Other supported devices

Then reconnect and monitor stability.

This is a troubleshooting test, not necessarily a permanent configuration.

Universal Printing Components

RDS environments often contain third-party printing software.

For example, an affected session might contain:

universalprinter.exe

The existence of such a process does not prove that printing software caused the black screen.

However, if the RDP logs show repeated failures involving device-redirection channels and the issue occurs only for certain users, printer/device redirection should be tested.

Avoid uninstalling production printing software merely because it appears in the process list.

Prove or disprove its involvement through controlled testing.

Step 12: Investigate RDP Graphics

A black screen naturally raises questions about the graphics pipeline.

Relevant components include:

dwm.exe
RDPUDD
RDP graphics channels
AVC/H.264 capabilities
DisplayControl
Frame Buffer

The RDP event log may show graphics channels opening and closing as clients connect and disconnect.

A graphics-channel closure occurring at the same moment as the entire TCP connection closes does not necessarily mean graphics caused the disconnect—it may simply be a consequence of the connection terminating.

Therefore, correlate events rather than diagnosing from one graphics event.

Step 13: Check Explorer and Application Crash Events

Search today's Application log:

Get-WinEvent -FilterHashtable @{
    LogName='Application'
    StartTime=(Get-Date).Date
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Message -match 'explorer.exe|dwm.exe|ShellExperienceHost.exe|EXCEL.EXE'
} |
Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message |
Format-List

Also inspect common application error/hang events:

Get-WinEvent -FilterHashtable @{
    LogName='Application'
    StartTime=(Get-Date).Date
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.LevelDisplayName -in @('Error','Critical') -or
    $_.Id -in @(1000,1001,1002)
} |
Select-Object TimeCreated,Id,ProviderName,Message |
Format-List

Look for references to:

explorer.exe
dwm.exe
ShellExperienceHost.exe
userinit.exe
EXCEL.EXE

Step 14: Check Resource Exhaustion

Although a single-user problem is less suggestive of server-wide resource exhaustion, CPU and RAM should still be checked.

Get-CimInstance Win32_OperatingSystem |
Select-Object `
@{N="TotalRAM_GB";E={[math]::Round($_.TotalVisibleMemorySize/1MB,2)}},
@{N="FreeRAM_GB";E={[math]::Round($_.FreePhysicalMemory/1MB,2)}}

Check top resource-consuming processes:

Get-Process |
Sort-Object WorkingSet64 -Descending |
Select-Object -First 20 ProcessName,Id,
@{N="RAM_MB";E={[math]::Round($_.WorkingSet64/1MB,1)}},
CPU |
Format-Table -AutoSize

And:

Get-Counter '\Processor(_Total)\% Processor Time',
'\Memory\Available MBytes',
'\Memory\Pages/sec'

Resource exhaustion becomes more likely when multiple RDS users experience freezes or black screens simultaneously.

Step 15: Check Resource Exhaustion Events

Search System logs for resource-related events:

Get-WinEvent -FilterHashtable @{
    LogName='System'
    StartTime=(Get-Date).Date
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Id -eq 2004 -or
    $_.Message -match 'resource|memory|display|TermDD'
} |
Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message |
Format-List

This can reveal memory pressure or other system-level conditions around the incident.

Step 16: When Should the Session Be Reset?

If recovery attempts fail and the user confirms that no unsaved work needs to be preserved, the affected session can be reset.

First confirm:

quser ACCUSER11

Then:

reset session 27

The user can reconnect afterward and Windows should create a new session.

Warning

reset session is destructive to applications running in that session.

Do not use it casually on a production RDS server.

Why Rebooting the Server Is Usually the Wrong First Response

Suppose an RDS server has:

18 Active users
1 affected user
1 unrelated disconnected user

Rebooting Windows Server to fix one black-screen session would unnecessarily interrupt everyone.

Use this escalation order instead:

Inspect → diagnose → recover shell → save work → reset affected session → investigate recurrence → reboot server only when justified.

When a Server Reboot May Be Appropriate

A server reboot becomes more reasonable if:

• Multiple RDP users develop black screens
• DWM/RDP components fail server-wide
• RDS services are malfunctioning
• Server resources are critically exhausted
• Updates require restart
• A driver problem affects multiple sessions
• RDS stops accepting connections
• The operating system itself becomes unstable

A single damaged user session generally does not meet those conditions.

Temporary Session vs Session Arbitration

Administrators may occasionally see a temporary session ID during reconnect.

For example:

Existing session: 27
Temporary session: 41

RDS may perform session arbitration while determining whether the new connection should reconnect to an existing session.

The temporary session can disappear immediately after the existing session is selected.

Therefore, a short-lived session ID should not automatically be interpreted as:

• Duplicate login
• Unauthorized login
• Stuck user
• Second permanent Windows session

Correlate it with Terminal Services events first.

Black Screen vs Network Disconnect

It is important to separate two conditions.

Condition A: RDP connection drops

Evidence:

Session disconnected
TCP read/write failure
RDP connection terminated

Potential causes include client network, WAN, firewall, router, RDP client, transport, or server-side networking.

Condition B: RDP reconnects but displays black

Evidence:

Session reconnection succeeded
Session becomes Active
RDP window stays connected
Desktop is black
explorer.exe missing

Potential causes include shell failure, user-session corruption, profile problems, DWM/graphics problems, or application/session interactions.

Both conditions can occur during the same incident.

Recommended Diagnostic Workflow

For a production Windows Server 2019 RDS environment:

1. Identify the affected user's Session ID.
2. Determine whether the session is Active or Disc.
3. Check whether other users are affected.
4. Examine processes in the affected session.
5. Look specifically for explorer.exe.
6. Preserve important applications and unsaved work.
7. Attempt Ctrl + Alt + End or Task Manager.
8. Start explorer.exe inside the affected session if appropriate.
9. Examine LocalSessionManager events.
10. Examine RdpCoreTS events.
11. Correlate disconnect times with network failures.
12. Test from another PC/network.
13. Temporarily disable RDP device/printer redirection.
14. Investigate graphics/DWM if the connection stays established but remains black.
15. Reset only the affected session if recovery fails.
16. Reboot the server only if evidence indicates a server-wide problem.

Preventing Recurring RDP Black Screens

For RDS servers, administrators should periodically monitor:

• CPU utilization
• Available memory
• Paging
• Disk latency
• Network stability
• RDP disconnect frequency
• Application crashes
• Explorer crashes
• DWM errors
• User profile errors
• Printer-redirection errors
• Third-party RDS utilities
• Windows updates
• Display and virtualization drivers

Recurring black screens should not be treated as normal RDP behavior.

If the same user repeatedly experiences the issue while others remain unaffected, investigate that user's:

• Windows profile
• Startup applications
• Login scripts
• Printer configuration
• Redirected devices
• RDP client configuration
• Local computer
• Network connection
• Applications running in the session

If multiple users experience the problem simultaneously, broaden the investigation to server resources, RDS components, networking, virtualization, storage, and drivers.

Frequently Asked Questions

1. Why does RDP connect but show only a black screen?

The RDP transport may be working while the Windows desktop inside the user session is not. Missing explorer.exe, DWM/graphics problems, profile issues, or a damaged existing session are possible causes.

2. Does a black RDP screen mean Windows Server has crashed?

No. Other users may continue working normally while one user's session is affected.

3. What does Disc mean in quser?

It means the RDP client is disconnected from the Windows session. The session and applications may still be running.

4. Is Disc the same as logged off?

No. Logging off terminates the user's session. A disconnected session normally remains on the server.

5. Why is explorer.exe important?

Explorer is the normal Windows shell and provides key desktop functionality including the desktop and taskbar.

6. Can Excel continue running while RDP displays a black screen?

Yes. A black or disconnected desktop does not necessarily terminate applications.

7. Will reset session close Excel?

Yes. Resetting the session terminates applications in that session and may cause unsaved data loss.

8. Should I reboot Windows Server to fix one black-screen user?

Usually not as the first action. Investigate and, if necessary, reset only the affected session.

9. How can I see all RDP users?

Run:

qwinsta

or:

quser

10. How do I inspect a particular user's processes?

Find their Session ID and filter processes by SessionId using PowerShell.

11. Can I restart Explorer without logging off?

Often yes. If Task Manager can be opened inside the session, use File → Run new task → explorer.exe.

12. Why use Ctrl+Alt+End instead of Ctrl+Alt+Delete?

In a normal RDP session, Ctrl+Alt+End sends the equivalent security sequence to the remote Windows session.

13. What is dwm.exe?

Desktop Window Manager manages desktop composition and graphical presentation. DWM or RDP graphics problems can contribute to black-screen symptoms.

14. Can poor Internet cause an RDP black screen?

Yes. Network instability can disconnect or freeze RDP, although a persistent black desktop after successful reconnection can indicate an additional session-side problem.

15. Does successful ping prove the RDP connection is healthy?

No. Ping tests ICMP reachability. RDP uses its own TCP/UDP communication, so successful ping does not rule out an RDP transport problem.

16. Can printer redirection cause RDP problems?

Printer/device redirection can sometimes contribute to connection or logon issues. If virtual-channel errors appear, temporarily disabling redirection is a useful diagnostic test.

17. Should I permanently disable printer redirection?

Not solely because a black screen occurred. First demonstrate that redirection is involved.

18. What does "No UDP Packets Received" mean?

It indicates that the expected UDP transport was not being received for that RDP transport attempt and RDP may operate over TCP instead. It does not by itself prove the root cause.

19. Why does a temporary new session appear during reconnect?

RDS can create/use a temporary session context during session arbitration before reconnecting the user to their existing session.

20. When should I suspect the user's profile?

If the same account repeatedly gets black screens from multiple client computers/networks while other users work normally, the user profile becomes a stronger suspect.

21. When should I suspect the client PC?

If other accounts also have RDP problems from the same computer but work normally elsewhere, investigate that client.

22. When should I suspect the RDS server?

If several users experience freezes, black screens, disconnects, or login problems simultaneously, investigate server resources, networking, RDS services, drivers, storage, and system logs.

23. Can high CPU or RAM cause RDP problems?

Yes. Severe resource pressure can make sessions slow, frozen, or unresponsive, particularly on multi-user RDS servers.

24. Should I delete the affected Windows profile immediately?

No. Profile recreation should come after logs and controlled testing indicate that the profile is likely responsible.

25. What information should be captured before resetting a problematic session?

Capture the username, Session ID, state, process list, important running applications, failure time, LocalSessionManager events, RdpCoreTS events, and relevant Application/System events.

Conclusion

A Windows Server 2019 RDP black screen should not automatically lead to a server reboot.

When the affected user has an existing disconnected session containing applications but explorer.exe is missing, the administrator should first attempt to recover the Windows shell while preserving the user's work.

At the same time, repeated RDP disconnect/reconnect events and TCP transport errors should be investigated independently. A network interruption may initiate the incident, while the surviving Windows session may subsequently remain in an unhealthy black-screen state.

The safest production approach is:

Diagnose the individual session → preserve applications/data → recover the shell → investigate RDP/network logs → isolate client/network/server causes → reset only when necessary.

This minimizes downtime and helps identify the actual cause instead of repeatedly treating the symptom.

#WindowsServer #WindowsServer2019 #RDP #RemoteDesktop #RemoteDesktopServices #RDS #RDPBlackScreen #BlackScreen #RDPTroubleshooting #WindowsTroubleshooting #ServerTroubleshooting #WindowsAdmin #SystemAdministrator #SysAdmin #ITSupport #TechnicalSupport #WindowsSupport #ServerSupport #RDPFix #RemoteDesktopFix #ExplorerEXE #WindowsExplorer #DesktopWindowManager #DWM #RdpCoreTS #EventViewer #PowerShell #WindowsPowerShell #QUSER #QWINSTA #SessionManagement #RDSSession #RDPDisconnect #RDPReconnect #NetworkTroubleshooting #TCP #UDP #PacketLoss #WindowsNetworking #PrinterRedirection #DeviceRedirection #UserProfile #WindowsProfile #ServerPerformance #ResourceMonitoring #WindowsShell #RemoteSupport #ITInfrastructure #ServerAdministration #WindowsTips