Remote Desktop freezing is one of those faults that can send troubleshooting in the wrong direction. The session may stop responding, but it does not always show a clean disconnect. That makes it tempting to blame the Windows server, RDP itself, DNS, firewall rules, or the remote application.
In this case, the fault looked like an RDP issue. The real clue came from the network path between a Dell Precision 5550 laptop, a USB-C dock, Wi-Fi, and a pfSense router.
The Symptom
The user was trying to reach a Windows Server 2019 host behind pfSense. RDP would freeze, but the client did not immediately report that it had disconnected.
That behaviour is consistent with packet loss or a stalled network path. TCP and RDP can sit in an awkward middle state where the screen is frozen but the session has not formally dropped yet.
The original target was thought to be an address on the client subnet, but that turned out to be the wrong destination. The correct Windows Server 2019 host was on a separate server subnet behind the firewall.
<server-ip>
<server-hostname>
pfSense was on:
<gateway-ip>
The test laptop was on:
<client-ip>
The First Clue: Bad Local Network Quality
Before changing the dock connection, tests to pfSense showed unstable results. At one point, the laptop-to-router path had packet loss and latency spikes:
Ping to <gateway-ip>
20 sent, 14 received
30% packet loss
Maximum latency: 317 ms
Average latency: 98 ms
That is poor enough to make RDP feel broken. Interactive remote access does not tolerate this well. Even if bandwidth is technically available, packet loss and jitter can make the session freeze.
The router-to-laptop direction also showed instability:
pfSense to <client-ip>
20 sent, 18 received
10% packet loss
Maximum latency: 341 ms
At this stage, the issue was not the Windows Server. The local client path to the router was already unhealthy.
The USB-C Dock Change
The laptop was a Dell Precision 5550 connected through a USB-C dock. The suspicion was that the physical dock port, or the way the laptop was positioned vertically beside the monitor, was affecting stability.
After moving the dock connection to another USB-C port, the laptop ended up in a 180-degree different orientation. That changed two things at once:
- The USB-C port in use
- The physical position of the laptop relative to the dock, monitor, cables, and wireless environment
After that change, the network quality to pfSense improved dramatically:
Laptop to pfSense <gateway-ip>
20 sent, 20 received
0% packet loss
Minimum latency: 1 ms
Maximum latency: 9 ms
Average latency: 3 ms
And from pfSense back to the laptop:
pfSense to laptop <client-ip>
20 sent, 20 received
0% packet loss
Minimum latency: 1.7 ms
Maximum latency: 42 ms
Average latency: 6.3 ms
That is a meaningful improvement. The RDP problem was no longer being masked by a bad client-to-router path.
Not All USB-C Ports Are Always Equal
The Precision 5550 has three USB-C ports, but Dell’s own specifications describe them differently:
- Two USB 3.2 Gen 2 Type-C ports with Thunderbolt 3 and Power Delivery
- One USB 3.2 Gen 2 Type-C DisplayPort port
That matters when a dock is involved. A port can physically accept the same USB-C connector while still presenting different capabilities to the operating system and dock.
For basic charging, the difference may not be obvious. For a dock carrying power, display, USB devices, and network traffic, the difference can matter.
This does not prove that one specific port on this laptop is faulty. It does mean the port selection is a legitimate troubleshooting variable.
Orientation Can Matter Too
The other variable was laptop orientation. The laptop was vertical and leaning near a monitor. Moving the dock connection put the laptop into a different 180-degree orientation.
That can affect a few practical things:
- Cable strain on the USB-C connector
- Intermittent movement at the port
- Dock cable bend radius
- Proximity to the monitor, dock, and other electronics
- Wi-Fi antenna position and signal pattern
- Heat movement through the chassis
None of those alone should break a network connection. In the real world, small physical differences can turn an intermittent problem into a repeatable one.
The important point is not to jump straight to “bad server” when a laptop dock is in the path.
The Correct Server Was Healthy
Once the correct target was tested, the Windows Server 2019 host on the server subnet looked healthy.
From the laptop:
RDP TCP/3389: open
Ping: 20 sent, 20 received
Packet loss: 0%
Latency: 1 ms minimum, 21 ms maximum, 4 ms average
Route: <client-ip> -> <gateway-ip> -> <server-ip>
From pfSense:
Ping to <server-ip>
20 sent, 20 received
Packet loss: 0%
Latency: 0.168 ms minimum, 48.289 ms maximum, 2.762 ms average
TCP/3389: succeeded
Interface: server VLAN interface
pfSense also had a valid ARP entry:
<server-ip> resolved to a valid layer-2 address on the server VLAN interface
That is the evidence we want to see. The server was present, reachable, and listening for RDP.
What We Learned
This case had two separate issues that could easily be confused:
- The original target IP was wrong. It was an address on the client subnet, not the Windows Server 2019 host.
- The laptop-to-router path was unstable before the dock/position change.
After changing the USB-C dock port and laptop orientation, local packet loss to pfSense disappeared in the test window. The correct RDP target on the server subnet then tested cleanly.
The evidence does not prove whether the improvement came from the different USB-C port, the changed cable angle, the changed laptop orientation, or a wireless condition that improved at the same time.
It does prove that the physical client setup was a valid suspect.
Practical Troubleshooting Checklist
When RDP freezes but does not cleanly disconnect, check the boring path first:
ping -n 20 <gateway-ip>
Test-NetConnection <server-ip> -Port 3389
tracert -d <server-ip>
On pfSense, confirm the router can see the host:
ping -c 20 <server-ip>
arp -an | grep <server-ip>
nc -vz -w 3 <server-ip> 3389
Then test the client hardware variables:
- Try each USB-C port individually
- Avoid sharp bends in the dock cable
- Keep the dock cable under no tension
- Test with the laptop flat and vertical
- Test with Wi-Fi disabled if Ethernet should be active
- Confirm which adapter Windows is actually routing through
- Update dock firmware, BIOS, Thunderbolt firmware, and network drivers
For Windows, these commands are useful:
Get-NetAdapter
route print -4
ipconfig /all
netsh wlan show interfaces
In this case, Windows still showed the dock Ethernet adapter as disconnected, so the improved test path was still using Wi-Fi. That is an important detail: changing a dock port may also change laptop position, cable strain, radio conditions, or power behaviour even when traffic does not move to the dock Ethernet adapter.
Bottom Line
USB-C makes docking look simple, but identical-looking ports are not always identical in capability or behaviour.
For a Dell Precision 5550, the USB-C port used for a dock should be treated as part of the fault domain. If RDP freezes, especially without a clear disconnect, test the network path before blaming the server. A five-minute ping and port test can separate a Windows Server issue from a client-side dock, cable, port, or Wi-Fi problem.
In this case, once the client path stabilised and the correct server IP was tested, RDP to the Windows Server host was reachable and clean.
Reference
Dell Precision 5550 Setup and Specifications, Ports and Connectors: https://www.dell.com/support/manuals/en-us/precision-15-5550-laptop/precision_5550_setupspecs/ports-and-connectors
Leave a Reply