Share via

RDP drops every day

JC 0 Reputation points
2026-02-27T20:37:50.0333333+00:00

Remote Desktop or access of any kind drops in windows server 2019 Even local login black screen.

Windows for business | Windows Server | Networking | Other
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Daphne Huynh (WICLOUD CORPORATION) 585 Reputation points Microsoft External Staff Moderator
    2026-03-02T07:59:52.8133333+00:00

    Welcome to the Microsoft Q&A Platform!

    Thank you for sharing your concern with us.

    Based on your description, if RDP sessions drop regularly and local/console logon also results in a black screen on Windows Server 2019, this strongly indicates a server-side OS stability or performance issue, rather than an RDP client or configuration problem.

    When both RDP and console access are affected, the issue is commonly related to one or more of the following:

    • OS resource exhaustion

    This can include TCP ephemeral port exhaustion, handle/memory/GDI leaks, or long server uptime. In these cases, a reboot temporarily restores access, but the issue recurs. Check Event Viewer → System around the failure time for:

    Event ID 4227 / 4231 (Tcpip) – ephemeral port exhaustion

    Event ID 1129 (GroupPolicy)

    Event ID 5719 (NETLOGON)

    These conditions can block authentication and cause black screens during logon.

    • Winlogon / Explorer / DWM failure

    Logon may succeed, but the desktop never renders, leaving a black screen both locally and via RDP. This is often associated with:

    Application Event ID 4005 (Winlogon terminated) and Application Event ID 1000 (explorer.exe crash)

    • Windows updates and security software interaction

    Black screen, console unresponsiveness, and high CPU or disk usage has been observed on Windows Server 2019, especially when Microsoft Defender runs alongside third-party AV/EDR software. In such cases, Microsoft typically treats this as an OS defect or known issue, rather than a misconfiguration.

    Reference: KB5041578 causing Windows Server 2019 to be unresponsive | Microsoft Community Hub

    Recommendation

    • Confirm system-wide impact using hypervisor or hardware console.
    • Collect logs before reboot and check the logs, especially focusing on:

    System and Application event logs, RemoteDesktopServices-RdpCoreTS (Operational) and look for Event IDs 4227/4231 (Tcpip), 4005 (Winlogon), 1000 (explorer.exe).

    • Monitor resource usage over uptime (CPU, memory, handle count, TCP connections).
    • If the issue occurs daily, capture a hang/NMI memory dump and open a support case with the Windows OS / Performance team for deeper analysis.

    Hope this helps, and I wish you a great day!

    0 comments No comments

  2. Q&A Assist
    2026-02-27T20:38:09.7066667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Daily RDP drops and even a black screen on local logon usually indicate an underlying OS, networking, or resource issue on the server rather than a pure RDP client problem. Use the following checks and isolation steps on Windows Server 2019.

    1. Check if the server is actually responsive
    • Use Azure/virtualization console (if VM) or hardware console (if physical) to see whether the OS is frozen or only RDP is failing.
    • If the console also shows a black screen or is unresponsive, treat this as a system performance or driver/hardware issue (CPU, RAM, disk, GPU/remote display driver) rather than an RDP-only issue.
    1. Check for TCP port exhaustion and related RDP/domain issues Daily drops that recover after reboot can be caused by TCP port exhaustion.
    2. Open Event ViewerWindows LogsSystem.
    3. Look for these Event IDs around the time of the drop:
      • 4227 (Tcpip) – TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used.
      • 4231 (Tcpip) – A request to allocate an ephemeral port number failed because all such ports are in use.
      • 1129 (GroupPolicy) – Group Policy processing failed due to lack of network connectivity to a domain controller.
      • 5719 (NETLOGON) – Computer couldn’t set up a secure session with a domain controller.
    4. If these appear, a process or service is exhausting TCP ports. Follow the guidance in Troubleshoot port exhaustion issues (linked from the article) to identify the misbehaving process, then stop or reconfigure it. After stopping it, test RDP again.

    If the misbehaving process is a Microsoft component or the issue persists after addressing port exhaustion, collect logs (for example, with TSS for user experience) and contact Microsoft Support.

    1. Verify Remote Desktop Services and RDP configuration
    • Ensure the Remote Desktop Services service is running:
      • Run services.msc → check Remote Desktop Services status; start it if stopped.
    • If using RD Session Host in a farm, verify the service on each host.
    • On older OS versions there are known issues querying domain controllers; for Server 2019 this is less common, but if you see domain-related errors, review DC connectivity and Group Policy processing.
    1. Check RDP protocol status and registry If RDP intermittently becomes unavailable:
    2. If remote registry access is possible from another machine:
      • Run regedt32FileConnect Network Registry → select the server.
      • Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server.
      • Confirm fDenyTSConnections is 0 (RDP enabled). If it flips to 1 due to policy, RDP will be blocked.
    3. If Group Policy is enforcing RDP settings, review GPOs that might disable RDP or affect Terminal Services.
    4. Check for licensing/“security error” disconnects If the disconnects are accompanied by messages like “Because of a security error, the client could not connect to the remote computer” or repeated denials:
    • On the RD Session Host, review:
      • Event ViewerApplications and Services LogsMicrosoftWindows
        • RemoteApp and Desktop Connections
        • TerminalServices-LocalSessionManager
        • TerminalServices-RemoteSessionManager
    • On the RD Licensing server, review:
      • Event ViewerApplications and Services LogsMicrosoftWindowsTerminalServices-Licensing
    • Look for:
      • Event ID 50 (TermDD) – RDP protocol component X.224 detected an error and disconnected the client.
      • Event ID 1088 (TermService) – Licensing grace period expired and no license server registered. If licensing is the cause, configure and activate an RD Licensing server and ensure the Session Host is pointed to it.
    1. Check for Secure Web Gateway/VPN tunnel interference (if Cloud PC/remote network) If the server is a Cloud PC or accessed through a VPN/Secure Web Gateway (SWG):
    • User-based VPN/SWG tunnels can cause disconnects during or after logon when RDP traffic is forced through the tunnel.
    • Implement forced-tunnel exceptions (bypass) for RDP traffic so that RDP goes directly instead of hairpinning through SWG/VPN. This reduces latency and removes dependency on tunnel state.
    1. Check Group Policy and SAM access restrictions If users intermittently see “access denied” or can’t connect while others can:
    • In gpedit.msc or central GPO:
      • Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.
      • Review Network access: Restrict clients allowed to make remote calls to SAM.
      • If enabled, it may block some users from connecting; use audit-only mode or adjust membership as documented.
    1. If RDP is stuck on “Securing remote connection” If part of the daily issue is long hangs on “Securing remote connection…” before it drops:
    • When using self-signed certificates on the RD Session Host, the client may try to retrieve trusted CA lists and revocation status from the internet, causing delays.
    • Workarounds include:
      • Importing the RD Session Host’s self-signed certificate into the client’s Trusted Root Certification Authorities store.
      • Or, via Group Policy, enabling Turn off Automatic Root Certificates Update under:
        • Computer ConfigurationAdministrative TemplatesSystemInternet Communication ManagementInternet Communication settings.
      • Note: Disabling Automatic Root Certificates Update means root certs must be updated manually on clients.
    1. Next steps if the whole system goes black/unresponsive If even local console logon shows a black screen and the system is effectively hung:
    • Check hardware/virtualization logs for resets, CPU/RAM pressure, or storage latency.
    • Review System and Application logs around the time of the daily drop for driver crashes, disk errors, or bugchecks.
    • If the pattern is daily at the same time, look for scheduled tasks (backups, antivirus scans, heavy batch jobs) that may be exhausting resources or causing port exhaustion.
    • If the issue persists after addressing the above and appears OS-related, collect logs and contact Microsoft Support.

    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.