“Not Responding” lockup when using TempWorks Enterprise RemoteApp

Updated for latest information after Windows Version 1803 release

In the months surrounding January 2018 several users of TempWorks Software’s “Apps.TempWorks.com” hosted software model have reported frequent and persistent issues with the software appearing to “lock up”.

An example of this particular condition is shown below, characterized by the appearance of a title bar on top of the window with the “(Not responding)” indication, as well as the pop-up message titled “RemoteApp” containing the “The server isn’t responding” error.
The condition will not resolve unless the Remote Desktop process is manually ended by the user.

This condition has been found to be caused by a specific form of network connectivity failure where the conversation between the client computer and TempWorks’ datacenter is interrupted suddenly and with no notification to either the client or TempWorks. This interruption could potentially be caused by network devices at the client, or by devices on the client’s internet service provider. Technical details of the connectivity failure can be found in appendix below. At this time all confirmed examples of this condition are occurring at locations serviced by Comcast Cable internet.

At this time the condition has only been found to occur on clients running the Windows 10 operating system “Fall creators update” also known as version 1709. While the underlying cause is network connection failure, other versions of the Microsoft Operating system resolve the situation with an automatic reconnection attempt that is usually not noticed by the end user. However, this version of Microsoft software appears to suffer from a defect in the reconnection mechanism.

There is some indication from the Microsoft community that this issue may be resolved in the next release of Windows 10 codenamed “Redstone 4”, it is currently available on an Opt-In basis via the Windows 10 Insider Preview program.


However, use of this is cautioned as these preview versions of windows have historically proven problematic for production environments at times.

At this time it is our recommendation that clients experiencing this issue seek to either

  A.  Improve network connection stability with the assistance of local IT and ISP resources.

  B.  move off of Windows version 1709 either by rolling back updates or upgrading to version 1803

C. apply a manual update to RDP components referenced in

Either should reduce or eliminate the occurrence of this condition.

If you would like further assistance or have additional information on this matter please reach out to TempWorks Support.



The network disconnection presents as a sudden halt of data flow on the underlying primary TCP session between TempWorks’ RDP Gateway server and the RDP client. No TCP RST packets are received by either side of the conversion.
Exhaustive diagnostics on TempWorks’ infrastructure has ruled out this session loss occurring on any of TempWorks’ systems or direct ISP systems.
Further the only ISP in common in the routes to all examples of this condition is Comcast Cable.

The only technical explanation is that some network device between the client computer and the internet that is capable of differentiating traffic on a TCP (layer 4) basis is disposing of the session which allows such traffic for a specific conversation or is discriminating against a specific conversation. This could include NAT gateways, Network Firewalls, or other L4 security or traffic management systems. It could also include such systems operated by the client’s ISP (in all examples, Comcast)

Packet capture/analysis of disconnect event.

Related Articles

  • None