Windows 11 25H2 clients (build 26200.x), both physical and virtual, are randomly dropping RDP sessions to a mix of physical and virtual Windows Server systems, including Server 2025. Everything is on the same wired LAN, with no VPN or firewall in the path. Windows 10 clients connecting to the same servers never have this problem.
The disconnects can happen immediately or after roughly 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 setting and the server transport policy. NIC features including LSO, checksum offload, RSS, ARP offload, and NS offload were also disabled. Server-side AVC/H.264 hardware encoding was disabled, security software was tested with, and no NIC reset events such as 27 or 10400 appear in the logs. The January 2026 out-of-band RDP certificate fix is already included in the installed build.
The same behavior occurs with mRemoteNG and FreeRDP, so it does not appear limited to the Microsoft RDP client. Process Monitor captured one disconnect where mstsc.exe made no system calls at all for approximately 435 ms immediately beforehand. In another test, three RDP sessions to different servers were open in one mRemoteNG process and all disconnected at exactly the same time.
There is no obvious packet loss, the clients and servers are on the same subnet, and the Windows 11 machine itself remains reachable when its outbound RDP session drops. What else could explain a client-side TCP reset or simultaneous failures across unrelated RDP sessions?
5 Answers
Even though the timing does not strongly suggest it, duplicate machine SIDs from cloning or imaging are worth ruling out. Recent Windows changes can cause Kerberos or NTLM problems when duplicate SIDs are detected. That normally affects authentication rather than randomly terminating an established session, so I would treat this as a low-probability check rather than the leading theory. Compare the machine SID portion from the local Administrator SID on affected systems and verify that the image-generation process properly generalizes each installation.
Check whether the affected systems have vendor management or network utilities installed, especially Lenovo Vantage or similar hardware-control software. These tools can install filter drivers or briefly alter network behavior even when security software is disabled. Compare the installed services, drivers, and network bindings between a working Windows 10 client and an affected Windows 11 client, then test with nonessential vendor utilities removed rather than merely closed.
The simultaneous failure of three sessions is the important clue. That points more toward something shared by the Windows 11 client, its TCP/IP stack, a host-level filter, or a common network event than toward three independent servers or an RDP codec issue. Since the local machine remains reachable and the same failure occurs with FreeRDP, capture traffic from the client and check which side sends the reset. Also correlate client and server logs around the exact timestamp, including extended RDP reason codes, TCP events, and Kerberos or NTLM events.
I would still inspect the network path closely: switch-port errors, spanning-tree events, interface flaps, and packet captures taken during a disconnect. Rebooting or replacing switch infrastructure may also be worth trying during a maintenance window. Docking stations and their Ethernet adapters can cause similar symptoms, although that seems less likely here because virtual machines show the same behavior and Windows 10 clients on the same switch remain stable.
A clean installation or a freshly provisioned test machine would help separate an OS-build issue from something inherited in the image. The fact that multiple Windows 11 machines and different RDP implementations fail makes a shared Windows 11 networking or filter-driver regression plausible. Before wiping production systems, reproduce it on a bare test installation with only required updates and drivers, then add management and endpoint components one at a time.
The troubleshooting changes were based on suggestions for similar incidents, and the issue is occurring on several Windows 11 machines. A clean test installation is probably the next useful way to determine whether the common image or an added driver is involved.
The affected virtual machines make a physical NIC or docking-station problem unlikely. Windows 10 clients on the same switch are unaffected, and the TCP reset appears to originate from the Windows 11 client.