Windows 11 25H2 clients (build 26200.x), both physical and virtual, randomly lose RDP connections to a mix of physical and virtual Windows Servers, including Server 2025. Everything is on the same wired LAN with no VPN or firewall in the affected path, while Windows 10 clients connecting to the same servers remain stable.
The disconnects can happen immediately or after about 30 minutes, including during active use. The client event log reports reason 2308 (0x904), indicating that the multitransport connection disconnected. UDP/RDP multitransport has been disabled through both the client registry and server Group Policy, without changing the behavior. NIC offloads, RSS, ARP/NS protocol offload, AVC/H.264 hardware encoding, and security software have also been ruled out. There are no corresponding NIC reset events.
The issue also occurs with mRemoteNG and FreeRDP, so it is not limited to Microsoft's RDP client. One particularly strange trace showed mstsc.exe making no system calls at all for roughly 435 ms immediately before the disconnect. In another test, three RDP sessions to different servers inside one mRemoteNG process disconnected at exactly the same time. A TCP reset appears to be generated by the Windows 11 client. Packet-loss checks have not shown anything obvious, and a separate remote session into the Windows 11 machine remained connected while an RDP connection initiated from that machine failed.
What else could explain a client-side, simultaneous teardown of multiple RDP sessions on Windows 11 25H2?
5 Answers
The simultaneous failure of several sessions points more toward something affecting the client or its network stack than an individual server. Check switch-port counters, spanning-tree events, and any intermediate device logs, even if the problem is limited to Windows 11. Docking stations and certain USB network adapters have also caused intermittent link problems, although the fact that virtual machines are affected makes a specific NIC model less likely.
Since the issue affects multiple RDP implementations, test the client outside the normal image and management stack. A clean Windows 11 installation or a known-good test VM can help identify whether a build-specific component, endpoint agent, network filter driver, or vendor utility is involved. Also check for utilities such as Lenovo Vantage or docking-station software that may install network or power-management filters, even if security software appears disabled.
The short period where mstsc.exe makes no system calls, combined with several sessions dying at the same instant, suggests a brief client-wide stall or forced transport reset rather than ordinary UDP instability. I would compare affected and unaffected Windows 11 builds, collect a simultaneous network trace plus ETW/RDP diagnostics, and test whether removing third-party network filter drivers or reverting to an earlier build changes the result.
Duplicate machine SIDs are worth ruling out if these systems were cloned from an image. Recent Windows changes have made duplicate-SID authentication problems more visible. Check the machine SID on affected clients and verify that the imaging process properly generalized each installation. This would usually cause Kerberos or NTLM authentication failures rather than randomly killing an established session, so I would treat it as a secondary possibility, not the leading explanation.
I would capture a packet trace from the client and check both client and server event logs around the exact disconnect time. Look for TCP resets, RDP transport errors, Kerberos or NTLM failures, and any extended reason code beyond 2308. A continuous ping or parallel connection to another system during the failure can help separate a general network interruption from an RDP-specific teardown.
A useful comparison is to keep an unrelated remote connection open to the Windows 11 workstation while it connects onward to another server. If the inbound connection stays alive while the outbound RDP session dies, that makes a local client-side RDP or TCP-stack problem more likely than a complete network drop.
The same behavior occurs on virtual machines, and Windows 10 systems on the same switch remain stable. The reset appears to originate from the Windows 11 client, with no obvious packet loss at the time.