Fix: An Internal Remote Desktop Error Has Occurred on Windows

6.2K

In some cases, when connecting to a remote computer or RDS host via Remote Desktop Connection (RDP), users may encounter an “An internal error has occurred” error. This tutorial shows how to fix RDP internal errors caused by DNS, VPN, UDP, TLS, or GPO misconfigurations.

What Causes the “An Internal Error Has Occurred” Message in RDP

This error can occur for a number of reasons related to both the RDP/RDS server and the client settings, and usually shows after user credentials are entered in the mstsc.exe window or immediately after the Connect button is clicked.

As there are several possible causes for this internal RDP error, try the following tips one by one until you find a solution that will help you.

Check RDP and Schannel Event Logs First

Note that before changing RDP, TLS, VPN, or Group Policy settings, you should first inspect the Event Viewer logs on both the RDP client and the Remote Desktop host. Keep in mind that “An internal error has occurred” message is a generic RDP frontend error (it usually does not expose the real root cause). In most scenarios, you can find the actual failure details in the Windows Event Logs.

1. Open Event Viewer:
   eventvwr.msc
2. Check the following logs:
   1. Applications and Services Logs →
   2. Microsoft →
   2.1. Windows →
   TerminalServices-LocalSessionManager
   TerminalServices-RemoteConnectionManager
   RemoteDesktopServices-RdpCoreTS
   Schannel
   2.2. Windows Logs → Security

Common RDP-related Event IDs

Event ID	Source	Description
226	RemoteDesktopServices-RdpCoreTS	RDP transport or disconnect issue
142	RemoteDesktopServices-RdpCoreTS	TCP socket read failure
36871	Schannel	TLS handshake failure
36888	Schannel	Fatal TLS alert
4625	Security	Failed logon attempt
5379	Security	Credential Manager credential usage
1026	TerminalServices-RemoteConnectionManager	Authentication/licensing issues

• In case you are facing Schannel errors, you should focus on TLS/certificate troubleshooting.
• In case RdpCoreTS events appear, you need to investigate UDP transport, VPN fragmentation, or MTU problems.
• If Security log failures appear, you should verify credentials, NLA, Kerberos, and time sync.

RDP Internal Error Troubleshooting Workflow

1. Check Event Viewer logs first
2. Test TCP/3389 connectivity
3. Test without VPN
4. Disable UDP transport
5. Verify credentials/NLA
6. Check TLS and certificates
7. Validate MTU and packet fragmentation
8. Restart Remote Desktop Services

Fix the Internal Error on the Client Side

If the “An internal error has occurred” error is only showing on one computer and other clients are successfully connecting to the Remote Desktop host, you need to check the settings on the current client device.

Reset DNS Cache and Try IP Address Instead of Hostname

Reset the DNS client cache on your computer by running the following command from an elevated command prompt:

ipconfig /flushdns

If you have entered the hostname or FQDN of the remote computer in the RD Client window, try to establish an RD connection using an IP address. If the Remote Desktop IP connection is successful, use the nslookup command to check that the DNS settings on your computer are correct:

nslookup yourRDShost

Hint. If the DNS settings are not configured correctly, the Remote Desktop can’t find your computer error will appear.

Check RDP Port 3389 Accessibility via PowerShell

Then check that the default RDP port (TCP/3389) is available on the remote server and the connection is not blocked by a firewall. Open the PowerShell console and run the command:

Test-NetConnection yourRDShost -port 3389

This command will return TcpTestSucceeded: True if the RDP port is not blocked.

Disable or Reconnect VPN Connections

If you are using a VPN to connect to a remote network, try disabling the VPN connections and try reconnecting to the RDP host. You can find and disable all active native Windows VPN connections using PowerShell:

foreach ($item in Get-VpnConnection | Where-Object { $_.ConnectionStatus -eq "Connected" })
{
Rasdial $item.Name /disconnect
}

Adjust RDC Client Settings (Reconnect & Authentication)

If you are using third-party VPN software, disconnect VPN sessions from its interface.

Open the properties of your RDP connection in Remote Desktop Connection windows (mstsc.exe) and make sure the ‘Reconnect if the connection is dropped‘ option is enabled on the Experience tab.

Also, try to disable the Server Authentication warning in the Advanced tab of the RDC client. Set the If server authentication fails to Connect and don’t warn me. Note that you can temporarily disable server authentication warnings for troubleshooting purposes, but keep in mind that this reduces protection against certificate spoofing and man-in-the-middle attacks (you should avoid using this permanently in production environments).

Remove saved password from Windows Credential Manager

Your RDP client may have tried to use saved RDP credentials to connect. You should try removing the saved password from Windows Credential Manager:

1. Open the Windows Credentials via the Control Panel. Or by running the command:

   rundll32.exe keymgr.dll,KRShowKeyMgr

2. Delete the saved RDP logon credentials for your remote host. Find the entry that starts with TERMSRV\your_rdp_host_name or TERMSRV\your_rdp_IP_address and click the Remove button;
   

Batch script to clear RDP cache

Use the following batch script to clear the RDP cache on the client:

@echo off
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default" /va /f
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers" /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers"
attrib -s -h %userprofile%\documents\Default.rdp
del %userprofile%\documents\Default.rdp
del /f /s /q /a %AppData%\Microsoft\Windows\Recent\AutomaticDestinations
del /f /s /q /a "%userprofile%\AppData\Local\Microsoft\Terminal Server Client\Cache"

Save this code to the reset_mstsc_cache.bat file and run it as an administrator.

Next, check the settings on the RDP host side if none of these tips work.

Check the Remote Desktop Host Settings

If the Remote Desktop connection error occurs on all clients, the simplest way to resolve the problem is to reboot the remote RDP/RDS host.

If you cannot restart the RD host immediately, you should try to restart the Remote Desktop Service (along with the Remote Desktop Services UserMode Port Redirector). You can do this with the following commands running in the elevated cmd.exe:

net stop termservice
net start termservice

Or you can restart Remote Desktop Services from the services.msc console.

If the problem disappeared after a restart, but it reappears after a while, then you need to try to change the settings of the RD Session host.

Use GPO to Fine-tune the RD Host Settings

Try to change some Group Policy settings using the Local GPO editor (gpedit.msc) or domain Group Policy Management Console (gpmc.msc).

1. Disable UDP protocol for RDP connections. Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections, enable the policy Select RDP transport protocols and set Select Transport Type = Use only TCP. This will completely disable the use of UDP for RDP connections;
   

   

2. The error “An internal RD error has occurred” often only occurs on clients that are connected to the network via a VPN tunnel. It seems that the problem is caused by the fragmentation of the UDP packets in the VPN tunnel. These problems are often accompanied by Event ID 226 or Event ID 142 in the RemoteDesktopServices-RdpCoreTS log.
   To disable RDP over UDP on a specific client only, enable the following GPO option on that computer: Off UDP on Client = Enabled under Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn Off UDP on Client = Enabled;
   

   

3. Now check if FIPS mode is required in your environment. Some government, military, and compliance-regulated environments require FIPS-compliant cryptography. In such cases, you can enable the policy by navigating to Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.However, FIPS mode is not a standard fix for RDP internal errors and you should only enable it when it is required by your organization’s security policy. Keep in mind that enabling FIPS may cause compatibility issues with legacy apps, older RDP clients, certain .NET apps, and third-party security agents;

   

4. Disable the hardware encoding and enforced AVC:444 mode on the RDP server side: Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Prioritize H.264/AVC 444 Graphics mode for Remote Desktop Connection = Disabled;
   

   

5. Temporarily test with the RDP Security Layer. In some environments, TLS negotiation failures, certificate problems, or Schannel config issues may prevent Remote Desktop connections from being established successfully. As a troubleshooting step, you can temporarily enable the policy by navigating to Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → Require use of specific security layer for remote (RDP) connections and set the Security Layer to RDP.If the connection succeeds after switching to the RDP security layer, the root cause is likely related to TLS, certificates, or Schannel config rather than Remote Desktop Services themselves.Important. The RDP Security Layer provides weaker protection than SSL (TLS) and you should only use it temporarily for diagnostic purposes. In production environments, we recommend using SSL (TLS) whenever possible.

   
   

   

After changing the local Group Policy settings on a remote server, you need to apply them on the client and server using the gpupdate command.

Warning. Do not leave the RDP Security Layer enabled permanently unless required by a legacy environment. SSL (TLS) provides stronger authentication and encryption and remains the recommended security layer for modern Windows Server deployments.

Check Network Level Authentication

To secure RDP connections, Network Level Authentication (NLA) is enabled by default on the RD host. In some cases, NLA can prevent RD connections from legacy or incompatible devices. You can temporarily disable NLA and see if the insecure remote desktop connection works as one of the troubleshooting steps.

Warning. Keep in mind that disabling Network Level Authentication reduces RDP security and you should use this only temporarily for troubleshooting purposes.

Note that standalone RDP hosts and full RDS deployments may fail for different reasons. In RDS environments, additional components (such as RD Connection Broker, RD Gateway, RD Licensing, SQL databases, and load balancing infrastructure) may also lead to authentication/transport failures.

Check CredSSP Policy Settings

“An internal error has occurred” message can also be triggered when CredSSP policy mismatches between the RDP client and server. This problem is especially common in legacy environments, unpatched systems, or after installing security updates related to CVE-2018-0886. The issue is especially common when modern Windows clients connect to older Windows Server 2008 R2/2012 systems that do not have the latest CredSSP security updates installed.

Incompatible CredSSP versions between the client and server may prevent Network Level Authentication (NLA) from completing successfully.

You should also check the following Event Viewer logs for CredSSP and authentication-related failures:

Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager

Windows Logs → Security

Common related events may include:

• Event ID 4625. Failed logon attempts
• Event ID 1026. Authentication/licensing failures
• Schannel Event IDs 36871/36888. TLS negotiation failures that may also impact CredSSP/NLA authentication.

In order to check the CredSSP policy settings on the client:

1. Open the Local Group Policy Editor:
   

   gpedit.msc

   
   

   

2. Now go to Computer Configuration → Administrative Templates → System → Credentials Delegation
3. Open the policy Encryption Oracle Remediation
4. Temporarily set the Protection Level to Vulnerable
5. Run the command:
   

   gpupdate /force

6. Now reconnect to the RDP host and test the connection again.

Important. The Vulnerable setting reduces CredSSP security protections and should only be used temporarily for troubleshooting or in isolated legacy environments.

If the issue is resolved after changing this setting, make sure both the client and the RDP server are fully patched and running compatible CredSSP versions.

You need to make sure that both the RDP client and server have the latest cumulative Windows security updates installed. Keep in mind that CredSSP authentication failures commonly happens when one side is patched for CVE-2018-0886 and the other side is outdated.

You can also temporarily config the CredSSP policy through the registry:

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /v AllowEncryptionOracle /t REG_DWORD /d 2 /f

Value info:

• 0 = Force Updated Clients
• 1 = Mitigated
• 2 = Vulnerable

After testing, you should return the policy to Mitigated or Force Updated Clients.

Check Kerberos Authentication and SPN Issues (IMPORTANT NLA dependency)

Kerberos authentication problems are a common hidden cause of the “An internal error has occurred” message during the NLA phase of RDP connection. This happens because Network Level Authentication (CredSSP) relies on Kerberos or NTLM before the RDP session is fully established. In case Kerberos fails, RDP may fall back to NTLM/fail completely with a generic internal error. To troubleshoot:

Step 0. Verify whether Kerberos or NTLM is actually used (CRITICAL)

Before you start troubleshooting SPN/DNS problems, you must first confirm which authentication protocol is being used during the RDP login attempt. On this step you will determine whether Kerberos is actually involved/if the system already fell back to NTLM.

To check Kerberos tickets on the client, run the following command:

klist

What to look for:

• A valid TGT (Ticket Granting Ticket) exists
• Service tickets such as TERMSRV/hostname or cifs/hostname

In case no service tickets are present, it means that Kerberos is not being used for RDP authentication.

In order to check logon context (domain vs local fallback), run the following command:

echo %logonserver%

In case it shows DC name, it means that domain authentication is active. If it returns empty or local machine, then it can be because of local account or NTLM fallback

To check environment variables (quick auth context validation), run the command:

set l

What to look for:

• LOGONSERVER=\\DCNAME means domain login active
• In case you are seeing missing or unexpected values, it means that there is an authentication fallback or domain context is broken

Decision point (IMPORTANT)

If after running the above checks, Kerberos tickets exist, then you need to proceed with SPN/DNS/time sync troubleshooting.

In case no Kerberos tickets exist, then the problem is not SPN related. Here you need to immediately check:

• DNS resolution problems
• NTLM restriction policies
• Domain trust/connectivity
• Time sync

In case Kerberos is not active at all, then SPN troubleshooting is irrelevant at this stage.

Step 1. Check if the issue is hostname-related (DNS vs IP test)

First, test whether the issue is related to Kerberos/SPN resolution. You need to try to connect using IP address instead of hostname. In case IP works but hostname fails, then most likely the issue is related to Kerberos/SPN or DNS.

Step 2. Check time sync (Kerberos requirement)

Note that Kerberos is sensitive to time drift. Now check time difference between client and server:

w32tm /query /status

If needed, force resync it:

w32tm /resync

In case the time skew exceeds 5 minutes, Kerberos authentication will fail and RDP may show a generic internal error.

Step 3. Check SPN registration (VERY IMPORTANT)

At this step, you need to verify Service Principal Names (SPN) for the RDP host:

setspn -Q TERMSRV/<hostname>
setspn -Q TERMSRV/<FQDN>

Now check for duplicates in the domain:

setspn -X

Note that duplicate SPN causes Kerberos ambiguity and it may lead to internal error.

Keep in mind that duplicate SPNs can cause Kerberos authentication ambiguity and lead to RDP NLA failures.

Step 4. Check DNS aliases (CNAME issue)

Note that you should avoid using DNS CNAME records for RDP hosts. Kerberos does not properly validate SPN for CNAME aliases unless configured explicitly. In case you are connecting using alias name instead of real hostname, Kerberos authentication may fail.

Step 5. Check Kerberos vs NTLM policy restrictions

In some environments, NTLM may be restricted through Group Policy:

Computer Configuration → Windows Settings → Security Settings → Local Policies →
Security Options → Network security: Restrict NTLM

In case NTLM is blocked and Kerberos fails, during RDP authentication you will face a generic internal error.

Step 6. Check Kerberos-related Event Logs

Now you need to check Event Viewer for Kerberos authentication failures:

Go to Windows Logs → Security. Here look for:

• Event ID 4768 (Kerberos TGT request)
• Event ID 4771 (Kerberos pre-auth failure)
• Event ID 4776 (NTLM authentication fallback)

Note that failures here often correlate with RDP “internal error” during NLA.

Step 7. Cross-correlation note (IMPORTANT)

Keep in mind that Kerberos problems often appear together with:

• CredSSP Encryption Oracle errors
• Schannel TLS handshake failures
• Security Event ID 4625 logon failures

Note that you should always analyze Kerberos logs together with CredSSP and Schannel events (not in isolation).

Network Settings on Remote Desktop Host

If you are using NIC Teaming (bonding) on your Windows Server host, make sure that the receive side scaling is disabled.

1. Open the Device Manager console (devmgmt.msc);
2. Expand the Network adapters and open the properties of the Microsoft Network Adapter Multiplexor Driver;
3. Go to the Advanced tab and set Receive Side Scaling to Disabled.

   

You can try to change the maximum outstanding connections limit on your RDP server via the registry. Set the following registry value via regedit.exe:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

DWORD: MaxOutstandingConnections

VALUE: 10000

Or with PowerShell:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name MaxOutstandingConnections -Value 10000 -PropertyType DWORD -Force

Check the current MTU size in your Windows with the command:

netsh interface ipv4 show subinterfaces

In case the packet needs fragmentation, you need to reduce the packet size until the ping succeeds. VPN tunnels often require lower MTU values (for example 1400–1450):

ping yourRDShost -f -l 1472
netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent

The value 1472 is used because the IPv4 MTU size is typically 1500 bytes:

• 20 bytes IP header
• 8 bytes ICMP header
• 1472 bytes payload

RDS Certificates

When you use a smart card certificate to authenticate on the Remote Desktop server, you may encounter the following events in the RemoteDesktopServices-RdpCoreT log on the Windows Server 2019/2016 RDS host:

Warning Event 226, RemoteDesktopServices-RdpCoreTS

General: RDP_TCP: An error was encountered when transitioning from StateUnknown in response to Event_Disconnect (error code 0x80070040)

Warning Event 142, RemoteDesktopServices-RdpCoreT

General: TCP socket READ operation failed, error 64

Make sure your certificate has not been revoked.

Recreate RDP certificate

Next, try to recreate the RDP certificate:

1. Open the local computer certificates MMC snap-in (run the certlm.msc command);
2. Go to the following certificate section: Remote Desktop > Certificates;
3. Right-click your self-signed certificate RDP cert and delete it (if there are several RDP certs, remove them all);
   

   

4. Restart the Remote Desktop Services as described above.

RDP and TLS Encryption

If you have disabled the legacy Transport Layer Security (TLS) 1.0 and TLS 1.1 protocols on your RD host, this may cause an Internal error when attempting to establish an RD connection to an RDS farm with the Connection Broker. The reason for this problem is that the Windows Internal Database (WID), which is used by default on an RDCB host running Windows Server 2016/2012 R2, only supports TLS 1.0.

To solve the problem, you can:

• Prefered solution. Use an external Microsoft SQL Server with TLS 1.2 support for the RD Connection Broker database.
• Temporary workaround. You can enable the TLS 1.0 protocol on RDCB:
  

  Warning. You should use the workaround shown below only in legacy RDS environments running Windows Server 2012 R2/2016 where the RD Connection Broker relies on Windows Internal Database (WID) and cannot negotiate TLS 1.2 correctly.You should not enable TLS 1.0 on modern Windows Server deployments unless absolutely necessary. TLS 1.0 is deprecated and may violate security compliance requirements (such as PCI DSS, CIS Benchmarks, NIST, and many corporate security standards).

  reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 1 /f

Now check if your RDP client connects to the remote host without errors. TLS negotiation problems usually generate Schannel Event IDs 36871 or 36888.

Important. Keep in mind that TLS 1.0 is deprecated and insecure! You should only use this workaround in isolated legacy RDS environments/temporarily. As a preferred long-term solution, we recommend you migrating the RD Connection Broker database to Microsoft SQL Server with TLS 1.2 support instead of re-enabling TLS 1.0.