I've had several scenarios that all behave consistently and I have a suggestion for debugging. First, the evidence:
Variables and Parameters:
The server initiates a reverse connection to a single listener. Autoreconnect is off. No encryption used. Firewall exception set for server executable. Using 188.8.131.52 x86 and x64 and Win8 variant wherever applicable
Viewer uses the following command line parameters:
/listen 5511 /quickoption 10 /autoscaling /reconnectcounter 0 /autoreconnect 0 /autoacceptnodsm /autoacceptincoming /notoolbar /disablesponsor
Viewer tested on Windows XP and Windows 7 and reports as being version 184.108.40.206 (although it was obtained via the 220.127.116.11 package)
1) Server [Poor internet quality (from ISP), LAN connection, WinXP x86] -> Viewer [LAN, good internet, XP&7 x86]
- Frequent hangs, but no crashes. Screen is often covered in grey blocks and loss of control regularly occurs for up to 10 seconds or so. Following loss of control viewer either resumes connection automatically or hangs indefinitely, in the latter case with no CPU usage and nominal memory usage (=deadlocked). However, in all cases, viewer can be terminated normally and the server detects this break in connection and terminates normally
2) Two servers simultaneously [Poor Wifi, Win8 x64] + [LAN, good internet, Win7 x86] -> Viewer [Good Wifi, Good internet, XP&7 x86]
- Initially a stable connection with both servers, maybe lasting 30 seconds. Viewer then hangs indefinitely, no significant CPU or mem load. Viewer terminated normally, status of servers unknown, although presumed exited normally because both attempt to connect subsequently. However, from this point onwards, whenever the servers connect together (two viewer instances appear in the taskbar) the viewer crashes immediately. This situation persisted, until I asked the second client (LAN, Win7x86) to end their session
3) Server [Poor Wifi, Win8 x64 (as above, but different occasion)] -> Viewer [Good Wifi, Good internet, XP&7 x86]
- The viewer often hangs but the server rarely / never detects that the connection has dropped (once the viewer is forcibly terminated). The server must also be forcibly terminated as it appears to be under the impression that all is well...
- Regardless of good or bad connection, the mouse pointer is never drawn (never more than a small square / dot) - as though the viewer has been instructed to not show the remote cursor. When inspecting the viewer connection options during such a session, it is set to 'Track Remote Cursor locally' (the default)
I have a suggestion to emulate the conditions of poor / inconsistent internet. On most laptops, the wifi adapter's properties page should have a setting (or more) for power usage. If you can set this to a maximise battery life / use minimum power you will recreate a similar scenario, but the device has to be quite far away and it must be a reverse connection!