Skip to content

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

Your vault is empty.

Free Fix 0x108

Remote Desktop error 0x108: your session ended because of a network error

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

Fix it now

A working session ended: you were logged in, the desktop was live, and the stream stopped. Microsoft publishes no meaning for the code the client prints here, so start with the two things that end healthy sessions on a schedule – a session time limit on the host, and an idle timeout on a VPN or gateway in the path – before you go near the network.

Run the first on the host and the second on the client

gpresult /h C:\report.html
pathping hostname
  1. Search the report for the Remote Desktop Services session time limits. Disconnections after a consistent period, to the minute, and only after inactivity, are policy rather than a fault.
  2. On the host, read what it recorded: Event Viewer, Applications and Services Logs, Microsoft, Windows, TerminalServices-LocalSessionManager, Operational. The entries there tell you whether the host ended the session or the client simply stopped talking.
  3. If a VPN or gateway sits in between, ask for its idle and session timeouts. A tunnel that drops after a fixed idle period explains a session that always dies at the same interval.
  4. On both machines, stop the network adapter being powered down: Device Manager, the adapter, Power Management tab, and clear the option that lets Windows turn the device off.
  5. Leave ping -t hostname running in one window while you work, so you have loss figures for the moment it next happens.

Turn on automatic reconnection in the client for the user’s sake, but keep looking. It hides short outages, which is exactly what makes an intermittent link harder to find later.

If sessions now survive as long as you leave them, you are done. If they do not, the next section covers everything that ends an established session.

Why it happens

Once a session is up, the client and host keep a TCP connection open and, where UDP is in use, a side channel alongside it. Anything on the path that decides that connection is finished ends the session: a NAT device expiring an idle mapping, a firewall reaping a long-lived flow, a VPN tunnel rekeying badly, or a wireless client roaming between access points and losing packets on the way. None of those produces an error on the host, because as far as it is concerned the client simply stopped talking.

Policy is the other half, and it is the half worth checking first because it is the only one that is punctual. Remote Desktop Services has explicit limits for idle sessions, active sessions and disconnected sessions, and an environment that applies them ends sessions on schedule. If yours dies after a consistent, round period of inactivity, look at Session Time Limits before you look at a cable.

On the number itself, be careful. Microsoft publishes no meaning for the code the Remote Desktop client prints in a disconnect message. The same digits do appear in the RDP protocol specification’s errorInfo table, where 0x00000108 is ERRINFO_LICENSE_BAD_CLIENT_ENCRYPTION – a licensing message that was incorrectly encrypted. That is a different numbering space and a different message, but it is worth knowing, because if your sessions are ending on an RD Session Host and nothing on the network looks wrong, Remote Desktop licensing is a candidate that the network story never mentions.

The other values quoted alongside this one are a mixture. 0x0000071A is documented: RPC_S_CALL_CANCELLED, the remote procedure call was cancelled, which is what the client-side plumbing reports when the transport disappears mid-call. The long extended disconnect values are not published at all, and there is no acceptable source that says which layer each identifies, so record them in the ticket and diagnose from the timing instead.

A session time limit is closing the session on purpose

You have this one if Disconnections after a consistent period of inactivity, 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 and anything applying to the user.
  2. Run gpresult /h C:\report.html on the host and search for those limits.
  3. Adjust or scope the policy so it applies where it is wanted, then confirm with gpupdate /force and a session left idle past the old limit.

A NAT device, firewall or VPN is expiring the connection

You have this one if Sessions survive while you type and die during meetings or lunch, and only from outside the office.

  1. Ask for the idle timeout on the VPN concentrator or firewall and compare it with how long your sessions last.
  2. Enable the keep-alive setting for Remote Desktop connections on the host, under Remote Desktop Session Host, Connections, so traffic flows during idle periods.
  3. Turn on automatic reconnection in the client so a brief drop recovers itself.
  4. Where a tunnel rekeys badly, ask the network team to look at the rekey interval rather than working around it at the desktop.

The client’s wireless link is dropping

You have this one if Only wireless clients are affected, and disconnects coincide with moving around the building.

  1. Turn off power saving on the wireless adapter in Device Manager, Power Management.
  2. In the adapter’s advanced properties, review roaming aggressiveness and lower it if the client is jumping between access points unnecessarily.
  3. Update the wireless driver from the laptop vendor.
  4. Test the same session over a wired connection to confirm the diagnosis before changing anything else.

Packet loss on the wide-area link

You have this one if pathping shows loss at a consistent hop, and other traffic to the same site is also unreliable.

  1. Capture the evidence: run pathping hostname during a working period and again during a bad one.
  2. Give the results to whoever owns the circuit. Remote Desktop is the symptom here, not the problem.
  3. In the meantime, disable the UDP transport on the client so the session runs over TCP alone, which recovers from loss more gracefully.

Remote Desktop licensing is ending the sessions

You have this one if The host is an RD Session Host, sessions end shortly after connecting rather than after idling, and the network is demonstrably clean.

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

Full reference

The five values, and what is published

Code What Microsoft publishes
0x108 Nothing for the code the client prints in a disconnect message. In the RDP protocol’s errorInfo table, 0x00000108 is ERRINFO_LICENSE_BAD_CLIENT_ENCRYPTION, a licensing message that was incorrectly encrypted
0x0000071A RPC_S_CALL_CANCELLED: the remote procedure call was cancelled
0x50331656 Nothing. An extended disconnect value recorded when a session ends without a clean logoff
0x50331698 Nothing. Another extended disconnect value from the same range
0x30000000 Nothing

Two useful conclusions come out of that table. The first is that the extended values are for correlating one disconnect with another, not for diagnosis. The second is that the licensing meaning attached to those digits in the protocol specification is worth keeping in mind on an RD Session Host, because it is the one cause of dropped sessions that no amount of network work will fix.

Telling a policy disconnect from a network one

Evidence Policy Network
Timing A fixed interval, to the minute Irregular
When Only when idle While you are working
Who else Everybody with the same policy Whoever is on that path
Host event log Records the session ending Records the client stopping
Reproducible Yes, by leaving a session idle Not reliably

The neighbouring codes worth knowing

Two errorInfo values from the same protocol specification are the most punctual causes of this symptom, and they are covered in the article on 0x1104. 0x00000003 is ERRINFO_IDLE_TIMEOUT, the idle session limit timer on the server has elapsed. 0x00000004 is ERRINFO_LOGON_TIMEOUT, the active session limit timer on the server has elapsed. If either appears anywhere in your evidence, the session limits are your answer and the network is not.

Reading the host’s own record

The host keeps its account of sessions in Event Viewer, under Applications and Services Logs, Microsoft, Windows, TerminalServices-LocalSessionManager, Operational. Entries there record connections, disconnections and reconnections with timestamps. Compare their timing against the client’s experience: a host that recorded the session ending is a host that decided something, and a host that recorded nothing until the reconnection is a host whose client stopped talking.

When the link is the problem and you cannot fix it today

  • Turn on automatic reconnection so short outages do not force a new logon.
  • Disable the UDP transport on the client, so the session runs over TCP alone and recovers from loss more gracefully.
  • Enable the keep-alive setting on the host so idle sessions still generate traffic and NAT mappings do not expire.
  • Keep pathping output from a good period and a bad one. Whoever owns the circuit will ask for exactly that.
  • Set expectations with the user: their applications keep running in the disconnected session and they will come back to them, until a policy logs the disconnected session off.

Do not raise or remove session time limits estate-wide to stop one administrator being disconnected. Those limits exist to reclaim sessions nobody is using, and removing them leaves logged-on sessions holding resources indefinitely on a machine several people share.

Every code this article covers

Code What it points at Source
0x108 Printed by the client when an established session ends. Microsoft publishes no meaning for it. Note that in the RDP protocol’s errorInfo table 0x00000108 is ERRINFO_LICENSE_BAD_CLIENT_ENCRYPTION, a licensing message that was incorrectly encrypted not published by the vendor
0x0000071A RPC_S_CALL_CANCELLED: the remote procedure call was cancelled Microsoft Learn
0x50331656 An extended disconnect value recorded by the client when a session ends without a clean logoff. No published meaning; use it to correlate disconnects rather than to diagnose one not published by the vendor
0x50331698 Another extended disconnect value from the same range. No published meaning not published by the vendor
0x30000000 Reported alongside the values above when a session ends without a protocol-level explanation. No published meaning not published by the vendor

Confirm the fix worked

  1. Leave a session idle for longer than it previously survived and confirm it is still live.
  2. Check the host’s TerminalServices-LocalSessionManager Operational log and confirm no new disconnect entries were written during the test.
  3. Run pathping hostname and confirm no loss at the intermediate hops.
  4. Reconnect after a deliberate disconnect and confirm you return to the same session rather than a new one.
  5. If the host is an RD Session Host, confirm licensing is configured and CALs are being issued before you close the ticket.

Questions people ask about this

Is there anything to buy to stop this?

Usually not: session limits, keep-alive settings, automatic reconnection and adapter power settings are built into Windows, and a flaky circuit is a matter for whoever supplies it. The exception is an RD Session Host, where sessions really do end if Remote Desktop licensing is not configured or client access licences are not being issued.

What does 0x108 mean?

Microsoft does not publish a meaning for the code the client prints here. The same value in the RDP protocol’s errorInfo table is a licensing code, which is a different numbering space, so treat it as a prompt to check licensing on an RD Session Host rather than as a definition.

Does my work survive the disconnect?

Usually. The session stays on the host in a disconnected state and your applications keep running, so reconnecting returns you to where you were. That holds until a policy logs the disconnected session off, which is exactly what the session limit settings control.

How do I tell a policy disconnect from a network one?

Timing. A policy disconnect happens after a fixed interval and only when idle. A network disconnect is irregular and happens while you are working. A network fault is almost never punctual.

Will automatic reconnection hide a real problem?

It can, which is why it belongs alongside the diagnosis rather than instead of it. Turn it on for the user’s sake and keep reading the event log and the pathping output until you know why the link is dropping.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Remote Desktop protocol error 0x1104: session drops soon after connecting Free Fix Error 0x80070035: the network path was not found when opening a share License Error Wi-Fi adapter Code 43 or Code 45: the device stopped or is not present License Error Error 0x80070047: no more connections can be made to this remote computer
← Back to Knowledge Base