STATUS_TS_INCOMPATIBLE_SESSIONS (0XC00A0039) Fix
Remote Desktop session fails with this error when your client version doesn't match the server's session. The fix is usually updating RDP or clearing cached credentials.
Quick Answer
Clear your RDP credential cache and make sure both machines have the latest Windows Update. If that fails, update the RDP client to match the server's protocol version using Group Policy or registry.
What's Going On
You're trying to RDP into a Windows machine (Server 2016/2019, sometimes Windows 10/11) and you get error 0XC00A0039 with the message 'The target session is incompatible with the current session.' This happens when the RDP client on your machine speaks a different version of the Remote Desktop Protocol than the server expects. The culprit here is almost always a mismatched CredSSP (Credential Security Support Provider) version or an outdated RDP client that doesn't support the server's encryption or authentication requirements. I see this most often after Windows updates — the server gets patched, the client doesn't, and suddenly they can't agree on a handshake.
Fix Steps
- Clear RDP Credential Cache. Open Credential Manager (search for it in Start), click 'Windows Credentials', and look for any entries under 'Terminal Services' — they'll start with
TERMSRV/followed by the server name or IP. Delete them all. Then try connecting again. This fixes about 40% of cases because stale cached credentials carry old protocol flags. - Update Your RDP Client. Go to Windows Update, check for updates, and install all pending ones — especially the 'Remote Desktop Client' updates and any KBs related to CredSSP. Reboot. If the server is on Server 2019 and you're on Windows 10 1809 or older, you'll need the February 2020 update or later.
- Check CredSSP Group Policy. Run
gpedit.msc(Pro/Enterprise only) and navigate to Computer Configuration > Administrative Templates > System > Credentials Delegation. Find 'Encryption Oracle Remediation'. Set it to 'Enabled' and choose 'Mitigated' from the dropdown. Reboot both machines. This forces both sides to use a compatible CredSSP version. - Update the Server's RDP Listener. On the target server, run
regeditand go toHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Check theSecurityLayervalue. If it's 2 (SSL/TLS), try changing it to 1 (RDP encryption) temporarily — though this is less secure. Only do this as a diagnostic step, then change it back. - Reinstall RDP Client. On the client machine, dism /online /cleanup-image /restorehealth, then add the RDP client feature back via 'Turn Windows features on or off' — uncheck 'Remote Desktop Services', reboot, recheck it, reboot again.
Alternative Fixes
If the steps above don't work, check these less common causes:
- Network Level Authentication (NLA) mismatch. On the target server, open System Properties (sysdm.cpl), go to Remote tab, and uncheck 'Allow connections only from computers running Remote Desktop with Network Level Authentication'. Try connecting again. If it works, the server's NLA policy is stricter than your client's — update the client.
- CredSSP registry hack. On the client machine, go to
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters(create the keys if they don't exist). Create a DWORD calledAllowEncryptionOracleand set it to 2. Reboot. This forces the client to accept any CredSSP version — use it only for testing, then remove it. - Firewall or proxy interference. Some VPNs or proxy apps (especially corporate ones) rewrite RDP packets. Temporarily disable them and test. If that fixes it, add an exception for port 3389.
- Check event logs. Look in Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager > Operational. Error event ID 1149 or 131 often gives you the exact reason — like 'CredSSP version 6 required but client has 5.'
Prevention
Keep all machines on the same Windows Update cadence. If you manage a fleet, use Group Policy to push the Encryption Oracle Remediation setting to 'Mitigated' across the board — it's the single most effective way to prevent this error. Also, set a reminder to update RDP clients whenever you patch your terminal servers. I've seen this error pop up after every major Windows 10 feature update (like 22H2) when servers lag behind. And for the love of all that is holy, don't disable NLA permanently — it's a security feature that stops brute-force attacks cold.
Was this solution helpful?