STATUS_RM_DISCONNECTED 0xC0190032 RDP Fix

You're 40 minutes into copying a 12 GB SQL backup from a file share to a client's Server 2019 box over RDP, and the session freezes. No disconnect dialog. Just a spinning progress bar that stops spinning. Event Viewer on the host logs STATUS_RM_DISCONNECTED (0xC0190032) and your Remote Desktop client eventually pops "The connection to the remote computer ended." Had this exact scenario last month at a dental office — their Practice Management backup job kept dying at 78%, every night, and the tech before me had been blaming the network switch. It wasn't the switch.

What STATUS_RM_DISCONNECTED actually means

RM stands for Resource Manager. On an RDP host, the Resource Manager component is the piece of the Remote Desktop Services stack that brokers session resources between the client, the session host, and any role services like RemoteApp or session-based desktops. It runs a heartbeat with the session. When that heartbeat misses enough intervals, the RM declares the session dead and tears it down with 0xC0190032.

Notice I said "declares dead." The session usually isn't dead — the RM just can't prove it's alive anymore. That's why you can often reconnect and find your file copy still churning in the background, or worse, half-written. The disconnect is a false positive from a stale keepalive, not a real network drop.

The three things that cause the heartbeat to miss:

Aggressive idle/keepalive timeouts on the session host or a middlebox (firewall, load balancer, VPN concentrator) sitting between client and host that closes "idle" TCP flows before RDP's own keepalive fires.
MTU black holes — large packets silently dropped because Path MTU Discovery got blocked by an ICMP-filtering firewall. Heartbeats are small, so they pass. Bulk data triggers the failure.
Overloaded session host — CPU pegged, disk queue at 40+, RM thread doesn't get scheduled in time to send its ping.

That last one is what bit the dental office. Their backup server was also running QuickBooks hosting for four clients, and the nightly VSS snapshot was starving the RM thread. Every night at the same time. The tech before me replaced two switches chasing ghosts.

The fix, in order

Check the session host's event log first. Open Event Viewer on the host (not the client) and filter the System log for source Microsoft-Windows-TerminalServices-RemoteConnectionManager and TerminalServices-SessionBroker. If you see 0xC0190032 clustered around a specific time, cross-reference with Task Manager's performance history. You're looking for a CPU or disk spike at that exact minute.
Raise the keepalive intervals on the host. Default RDP keepalive is 1 hour, which is useless against a firewall that idles TCP at 15 minutes. Set it tighter. On the session host:
```
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v KeepAliveEnable /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v KeepAliveInterval /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v KeepAliveProgram /t REG_SZ /v "" /f
```
That sends a keepalive every 60 seconds. Reboot or restart the TermService service after. Also check the client side — on Windows 10/11 set the same keys under HKLM\SOFTWARE\Microsoft\Terminal Server Client if you're connecting through a VPN that idles aggressively.
Verify MTU end to end. From the client, ping the host with a large payload and DF flag set:
```
ping <host> -f -l 1472
```
If that fails but -l 1400 passes, you've got an MTU issue. Either lower the RDP host's NIC MTU or fix the firewall that's eating ICMP Type 3 Code 4. Don't just clamp it and forget it — a black hole will bite you again on the next protocol.
Take RDS out of the equation during bulk transfers. If you're copying multi-gigabyte files, RDP drive redirection is the wrong tool. It runs over the same channel as the session. Use SMB directly, or map a drive, or — my favorite — copy via robocopy from a scheduled task on the host. Every RDP file transfer of a 10 GB backup I've seen has eventually blown up at some point. The session wasn't built for it.
If it's a session host under load, cap concurrent sessions. Set a session limit per user and a maximum connection count in tsconfig.msc. Better to refuse a fifth RDP user than to drop all four who are already working.

Still failing? Check these

If you've done all of the above and 0xC0190032 keeps showing up, the problem is upstream of the host. In rough order of likelihood:

Load balancer session affinity. If you're behind an RDS farm with a hardware LB, a failover event will hand your session to a different host mid-stream. The RM on the original host fires 0xC0190032 because the client vanished from its perspective. Check the LB session table.
VPN re-keying. AnyConnect, GlobalProtect, and FortiClient all re-key tunnels on a schedule. If the re-key window coincides with the disconnect, that's your answer. Test by running an RDP session with no traffic for 30 minutes and see if it drops.
Antivirus network filter drivers. SonicWall's client, older Sophos Endpoint, and some ESET builds install network shims that mangle RDP keepalives. Uninstall or whitelist RDP traffic temporarily to test.
NIC power management. Yes, really. A Realtek or older Intel NIC with "Allow the computer to turn off this device to save power" enabled will occasionally drop link state for a second. That's enough to kill the RM heartbeat. Disable it in Device Manager under the NIC's Power Management tab.

One more thing: don't chase this by rebooting the session host. I've seen three different admins reboot a production terminal server five times in an evening trying to clear 0xC0190032. The reboot resets the RM thread, so the error stops — long enough to look fixed. It comes back the next time the trigger fires. Find the trigger. Then fix it.