RDP: An Internal Error Has Occurred on Windows Server (Causes and Fixes)

This error is unusual among RDP failures because the network is almost always fine. The client reaches the server, the handshake starts, and then it collapses with An internal error has occurred, sometimes before the credentials prompt and sometimes after. That pattern is the clue. Something that should happen during the secure session setup is going wrong on the server, and the usual candidates are the server's RDP certificate and the security protocol negotiation. Working through it in the right order avoids the mistake of changing six settings at once and not knowing which one mattered.

First decide whether it is the network or the server

Before touching any settings, find out whether the fault is on the path or on the machine. Open the server through a console that does not use the network, such as the hypervisor console or your provider's web console, then run mstsc and connect to localhost. If a local connection works, the server is healthy and the problem lies in the network path or in something between the client and the server. If the local connection fails with the same message, the server itself is the problem, and everything below applies. Microsoft documents this method in its own troubleshooting article for this error, which is the reference we check against.

A delay before the error is a different problem

If the connection hangs for roughly a minute before failing and then works on the next attempt, you are probably looking at a different cause. Microsoft attributes that pattern to a blocking call while the session retrieves audio settings. Disabling the Windows Audio service on the server, and on the client if needed, is the documented remedy for that specific delay. If your symptom is an immediate failure, carry on.

Confirm the services behind the certificate are running

RDP depends on a chain of Windows services to create and renew its self-signed certificate. If any of them has stopped or failed to start, certificate renewal silently fails and the first connection after expiry breaks. Check these are running: Certificate Propagation, CNG Key Isolation, Cryptographic Services and Remote Desktop Configuration.

Get-Service CertPropSvc, KeyIso, CryptSvc, SessionEnv, TermService | Format-Table Name, Status, StartType

Anything stopped should be started, and a service that refuses to start needs its dependencies and the System event log checked, with the Service Control Manager source as the place to look.

Regenerate the RDP self-signed certificate

Deleting the existing certificate and letting Windows create a new one is the cleanest single test, and it is safe on a server that uses the default self-signed certificate. Open the Certificates snap-in for the local computer, expand the Remote Desktop store, and delete the RDP certificate. Then restart the Remote Desktop Services service:

Restart-Service TermService -Force

Refresh the snap-in. If a new certificate appears and you can connect, the old one had expired or become corrupt. If no new certificate is created, the cause is in certificate generation, which points at permissions on the machine keys.

Check MachineKeys permissions

When certificate creation fails, wrong permissions on the machine key folder are the most common reason. Look at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Per Microsoft's guidance, the folder should grant Administrators full control and Everyone read and write, and nothing more exotic than that. A security hardening script or a well-meaning cleanup that removed those entries is the usual way this breaks.

There is also a specific machine key, a file whose name begins with f686aace6942fb7f7ceb231212eef4a4, that belongs to RDP. Its ownership should be an administrator, and its permissions should be System with full control and Network Service with read access. After correcting either, restart the Remote Desktop Services service and check that the certificate is recreated.

Look for a bad certificate binding

The server can also be pointed at the wrong certificate. In the registry under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, look at the SSLCertificateSHA1Hash value. If it names a thumbprint that does not match the certificate actually present in the Remote Desktop store, removing that value and restarting is a recognised fix. Do not do this on a server that holds the Remote Desktop Connection Broker role, because that role manages the binding itself.

Rule out security protocol negotiation

If a certificate refresh does not help, the failure may be in how client and server agree on security settings. To test this, Microsoft's method is to temporarily relax two values and see whether the connection then succeeds, then restore them straight away:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SecurityLayer /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication /t REG_DWORD /d 0 /f

Treat that purely as a diagnostic. If it works, the issue lies in negotiation, and you must put the recommended values back when you finish, otherwise the server is left accepting weaker connections:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v SecurityLayer /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication /t REG_DWORD /d 1 /f

Beyond that, check for a Group Policy that sets an SSL cipher suite order, since a restrictive list can leave client and server with no cipher in common. Setting it to Not configured, and removing the matching policy registry value, is the documented step. Back up the registry before every change of this kind.

Related RDP errors that look similar

Two neighbouring errors cause confusion. A CredSSP encryption oracle remediation message means the client and server are patched to different levels, and the proper fix is updating both, not weakening the policy on the client. And a message about no Remote Desktop licence servers is a licensing problem that has nothing to do with certificates. Reading the exact wording matters, and so does the System and TerminalServices event logs, which usually name the real failure.

Keep a way in that does not rely on RDP

The lesson from every one of these incidents is to keep a second route to the server. A provider console, a management network or an out-of-band tool means a broken RDP certificate costs you minutes, not a call to the data centre. If you are managing Windows servers alongside Linux, the same discipline of structured monitoring applies, as set out in our guide on monitoring your server for better performance, and a fixed triage sequence like the one in our 3 AM server-down checklist keeps a lockout from turning into a long outage.

If a Windows server is unreachable and your team needs it back, our Windows server management engineers can work through the certificate, permissions and policy layers with you and leave the server with remote access you can rely on.