Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 0x1104

Remote Desktop protocol error 0x1104: session drops soon after connecting

11 min read Updated October 5, 2026 Networking, Sharing & Printing

Fix it now

The session ended because the client and host could no longer agree on the stream between them. Microsoft publishes no meaning for 0x1104, so the diagnosis is the transport and what it carries: the UDP path, the packet size, a redirected device, or the host’s encoder. Read any other code in the dialog first, because several of them are not transport faults.

Run these on the client, in an elevated Command Prompt

ping -f -l 1472 hostname
netsh interface ipv4 show subinterfaces
gpupdate /force
  1. If the first line fails, work down from 1472 until it succeeds, then add 28 to get the working MTU and set it with netsh interface ipv4 set subinterface "<adapter>" mtu=<value> store=persistent.
  2. Retest with the UDP transport disabled on the client. In the Group Policy Editor, go to Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Connection Client, and enable the setting that turns off UDP, then run gpupdate.
  3. Retest with redirection off. In the client, open Show Options, then Local Resources, and clear Printers and Clipboard, then More and clear drives.
  4. On the host, update the display adapter driver from the hardware vendor rather than relying on the generic package.
  5. Clear the client’s bitmap cache: close the client, then delete the contents of %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache.

0x1104 usually appears after a working desktop, but it is also reported at connection time through VPN appliances, RD Gateways and reverse proxies. Where one of those is in the path, blocked or intercepted RDP traffic is a live cause and the tuning below is not.

If the session holds you are done. If it drops again, or the dialog quoted a different code, the next section explains what each one actually points at.

Why it happens

A Remote Desktop session is several logical channels multiplexed over one connection: the graphics stream, an input channel, and a virtual channel for each redirected resource – printers, drives, clipboard, audio, smart cards. A protocol error is the client saying something arrived that it could not parse, or that a channel ended when it should not have. Because the channels share the connection, one badly behaved channel takes the whole session with it.

The transport matters as much as the content. Remote Desktop can use TCP alone or TCP with a UDP side channel for graphics and input, and the UDP path is the one that suffers on links with loss, aggressive NAT timers, or a tunnel that fragments. Turning UDP off costs a little responsiveness on a good link and frequently makes an unstable one usable, which is why it is worth trying early.

Now the part that matters most, because it sends people in the wrong direction more often than anything else here. The other codes quoted in this dialog are errorInfo values from the RDP protocol specification, and four of them have published meanings that have nothing to do with the transport. 0x3 is ERRINFO_IDLE_TIMEOUT: the idle session limit timer on the server has elapsed. 0x4 is ERRINFO_LOGON_TIMEOUT: the active session limit timer on the server has elapsed. Both are policy on the host doing exactly what it was told.

0x103 is ERRINFO_LICENSE_BAD_CLIENT_MSG: the remote computer received an invalid licensing message from the client. That is Remote Desktop licensing, not a virtual channel. 0x112F is ERRINFO_GRAPHICSSUBSYSTEMFAILED: the server-side graphics subsystem is in an error state and unable to continue graphics encoding – the host’s encoder, not its memory or its session count. Its neighbour 0x112E is the related reset failure. Read the number you were given before you change an MTU.

A session time limit is ending the session on purpose

You have this one if 0x3 or 0x4, or disconnections after a consistent period, to the minute, and only after inactivity.

  1. Check Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Session Time Limits on the host.
  2. Run gpresult /h C:\report.html on the host and search for the Remote Desktop Services session limits.
  3. Adjust or scope the policy so it applies where it is wanted, rather than disabling it estate-wide because one administrator finds it inconvenient.

A network fault is rarely punctual. If the session dies after the same round interval every time, look here before you look at the link.

Remote Desktop licensing is refusing the client

You have this one if 0x103, or sessions that connect and end shortly afterwards on a machine that is an RD Session Host.

  1. On the host, confirm RD Licensing is configured and that a licence server is reachable and issuing.
  2. Confirm RDS client access licences are installed and being issued, and check whether the licensing grace period has lapsed.
  3. Where the client’s licence cache is damaged, clear it under HKLM\SOFTWARE\Microsoft\MSLicensing on the client and reconnect so it is reissued.

The host’s graphics subsystem has failed

You have this one if 0x112F, or failures clustered around video, screen sharing or one particular application.

  1. Update the host’s display driver from the hardware vendor, not from a generic package.
  2. Look at the Remote Session Environment policies under Remote Desktop Session Host, including the hardware graphics adapter and H.264 encoding settings, and test with them off.
  3. Reduce the session’s colour depth on the client’s Display tab, and disable font smoothing on the Experience tab, as a diagnostic.

The UDP transport is unusable on this path

You have this one if Sessions drop over VPN or mobile connections and hold steady on the local network, and disabling UDP fixes it immediately.

  1. Disable UDP on the client through the Remote Desktop Connection Client policy folder, then run gpupdate /force.
  2. Retest over the same link that was failing, for longer than the session usually survived.
  3. Where the cause is a VPN that fragments, fixing the tunnel is better than living without UDP everywhere.

A redirected device is breaking a virtual channel

You have this one if The session survives until you print, copy something large, or plug in a device, and clearing redirection stops it happening.

  1. Turn redirection off one item at a time to identify the culprit: printers first, then clipboard, then drives.
  2. For printer redirection, use Remote Desktop Easy Print on the host rather than mapping a client-side manufacturer driver into the session.
  3. Where one device is at fault, leave that redirection off and re-enable the others.

Full reference

The five numbers, and which machine each sends you to

Code Published meaning Where to work
0x1104 Nothing published. Reported by the client when it ends the session on a protocol error Client and path first; the host if the same client works elsewhere
0x3 ERRINFO_IDLE_TIMEOUT: the idle session limit timer on the server has elapsed Session Time Limits on the host
0x103 ERRINFO_LICENSE_BAD_CLIENT_MSG: the remote computer received an invalid licensing message from the client RD Licensing, CAL issuance, and the client’s licence cache
0x112F ERRINFO_GRAPHICSSUBSYSTEMFAILED: the server-side graphics subsystem is in an error state and unable to continue graphics encoding The host’s display driver and encoder settings
0x4 ERRINFO_LOGON_TIMEOUT: the active session limit timer on the server has elapsed Session Time Limits on the host

Three of those five are host-side and two of the three are policy or licensing rather than a fault. That is the single most useful thing on this page: a reader who arrived because sessions keep dropping, and who has 0x3 or 0x4 in the dialog, should close the network tools and open Group Policy.

Finding the working packet size

  1. Run ping -f -l 1472 hostname. The f sets do-not-fragment and the l sets the payload size.
  2. If it fails, reduce the size in steps of 10 until it succeeds, then narrow down by 1.
  3. Add 28 to the largest payload that worked. That is the path MTU.
  4. Record the adapter’s current value from netsh interface ipv4 show subinterfaces before you change anything.
  5. Set it with netsh interface ipv4 set subinterface "<adapter>" mtu=<value> store=persistent, then confirm ordinary browsing and file transfer still behave.

Check the VPN client’s own MTU setting as well. It frequently overrides the adapter, and changing the adapter alone then appears to do nothing.

Where 0x1104 appears at connection time

The usual shape of this fault is a desktop that appeared and then went away. It is not the only shape. Where the connection passes through a VPN appliance, an RD Gateway or a reverse proxy, the same protocol error is reported before a desktop is ever drawn, and the causes there are different: RDP traffic blocked or inspected on the way to the target, connectivity from the appliance to the host, or another process holding the port the gateway needs. If you never saw a desktop, look at the path devices before you touch an MTU.

Licensing, and when it is actually the answer

Most of what is on this page costs nothing to fix. That is not universally true, and 0x103 is the exception. Where the host is an RD Session Host, sessions that end shortly after connecting are a recognised symptom of the licensing grace period expiring or client access licences not being issued. Confirm RD Licensing is configured, that the licence server is reachable, and that CALs are installed and issuing, before you spend a day on the network.

When it is one person and nobody else

  • Clear that client’s bitmap cache and delete the saved connection file, then recreate the connection.
  • Test the same account from another machine, which splits the user from the hardware.
  • Check what is redirected from that desk specifically, since a device unique to one person is a common answer.
  • Check whether that person is on a different path – a home line rather than the office – and test the MTU on it.
  • Check the host’s TerminalServices-LocalSessionManager Operational log to see whether the host recorded a clean logoff or an abrupt disconnect.

Every code this article covers

Code What it points at Source
0x1104 Reported by the client when it ends the session on a protocol error. Microsoft publishes no meaning for this value and it is not in the protocol specification’s error table not published by the vendor
0x3 ERRINFO_IDLE_TIMEOUT: the idle session limit timer on the server has elapsed Microsoft Learn
0x103 ERRINFO_LICENSE_BAD_CLIENT_MSG: the remote computer received an invalid licensing message from the client Microsoft Learn
0x112F ERRINFO_GRAPHICSSUBSYSTEMFAILED: the server-side graphics subsystem is in an error state and unable to continue graphics encoding Microsoft Learn
0x4 ERRINFO_LOGON_TIMEOUT: the active session limit timer on the server has elapsed Microsoft Learn

Confirm the fix worked

  1. Hold a session open for longer than it previously survived, with the same applications running.
  2. Print, copy and paste, and open a redirected drive, to confirm the virtual channels stay up.
  3. Run ping -f -l <working size> hostname again and confirm it still succeeds after any MTU change.
  4. If the code was 0x3 or 0x4, leave a session idle past the old limit and confirm it survives.
  5. Check the host’s TerminalServices-LocalSessionManager Operational log for a clean logoff rather than an abrupt disconnect.

Questions people ask about this

Does anything here need to be bought?

Transport, redirection and graphics faults cost nothing to fix. There is one exception: if the host is an RD Session Host and you are seeing 0x103, confirm RD Licensing is configured and that RDS client access licences are installed and issuing, because a lapsed grace period or missing CALs really does end sessions.

Is disabling UDP a real fix or a workaround?

On a link that genuinely cannot carry it, disabling UDP is the fix. On a good local network it is a workaround hiding a fragmentation or loss problem you would rather find, so test the MTU before you leave it off permanently.

I have 0x3 in the dialog. Is that a network fault?

No. It is ERRINFO_IDLE_TIMEOUT: the idle session limit timer on the server has elapsed. Your session was closed by policy. Look at Session Time Limits on the RD Session Host rather than at the network.

What about 0x112F?

It is ERRINFO_GRAPHICSSUBSYSTEMFAILED: the host’s graphics subsystem is in an error state and cannot continue encoding. Go to the host’s display driver, the hardware graphics adapter policy and the H.264 encoding settings – not to memory or session counts.

Should I look at the host or the client first?

Read the code first. 0x1104 with no other information points at the client and the path. 0x3, 0x4, 0x103 and 0x112F are all host-side and three of them are policy or licensing rather than a fault.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Network adapter Code 10: this device cannot start in Device Manager License Error VPN error 809 and 800: IKE traffic blocked before the tunnel can open License Error 0x80070032 and SMB1 shares: why old NAS boxes stop working in Windows Free Fix Error 0x80070052: the directory or file cannot be created on a share
← Back to Knowledge Base