Kind of disastrous. Can't understand it... Within shortest time we had return to 1.2.0.9. Reverse connection still unstable (disappears from repeater after some viewer connect/disconnect) from a Vista32 low end test system with rdpmode disabled (!). rdpmode enabled behaves pre-alpha style the more. 1.2.0.9 still rock stable.

I wish I could analyse it more detailed and could say more than "*not working*", you know me. I'm a IT professional and I know what info a programmer needs to find a bug. But I have absolute no time at the moment, really sorry.

2) UVNC_Launch: saved password of last opened connection/session is used for the following connection/session IF the following connection has no saved password. => If the following connection needs another password you get "Authorization failed." (or something like that) and you can see the password of the previous connection has been passed to the viewer (command line of the viewer). Workaround: restart UVNC_Launch

That's something i can work with.minimize-> restore: The viewer send a message to the server...(send_next_update)It looks like the server loose this message and keeps waiting for the viewer to ask for an update, while the viewer waits for an update from the server.

Added:If server detect that it take to long before the viewer ask for an update, just inject one.The drawback is that when you minimize the screen, there will still be some background updates.

Rudi De Vos wrote:That's something i can work with.minimize-> restore: The viewer send a message to the server...(send_next_update)It looks like the server lose this message and keeps waiting for the viewer to ask for an update, while the viewer waits for an update from the server.

Added:If server detect that it take to long before the viewer ask for an update, just inject one.The drawback is that when you minimize the screen, there will still be some background updates.

But there seems to be a side effect: After starting the uvnc-service with this fixed winvnc.exe one of the first three connection attempts brings up the viewer without a remote screen (= viewer shows only a grey area where the remote screen should be). If I close that viewer and try to connect once more it is working but the remote winvnc.exe has a stalled connection (My Client IP is listed twice unter "List all clients"; the stalled connection can't be killed - nothing happens!).This problem is already known, but the cause is unknown. This is the first time I could reproduce this problem multiple times in a row! Please let us investigate it further: are there any viewer logging options which would produce something usable for you?

Still trying to identify the problem "viewer shows nothing = grey area / ghost connection @ server":With the winvnc_cursor64.zip applied at my Win7x64 PC (server) the problem is 100% reproducible: the second incoming viewer connection (after starting the winvnc service) fails (stuck client connection @ win7 server side; viewer at win81 client shows only grey area). The stuck viewer connection on the server side is shown under "List All Clients" until stop service + kill all winvnc.exe processes (until I do that aero stays disabled).(On the other hand: I don't see / can't repeat the problem using winvnc_cursor64.zip @ Win8.1x64.)

I've tried to catch the problem after enable of debug log to file (level = all)...while logging the following happened:

It does seem to help a bit with stability. I do still get some lockups when a device reboots and it tries to reconnect. Viewer is not trying to reconnect and just hanging instead of cycling through the retry loop when connecting to old server (1.0.9.5) but 1.2.1.0 server seems improved on some devices. (not on my windows 10 tablets though, yet)

Thanks Rudi! With both test versions I can't reproduce the lock anymore.

After a lot of connect/disconnects for testing purposes I've only observed one thing with both test versions (not sure if it is even worth mentioning it - doesn't really bother me): On viewer connect sometimes I only see a small square/little part (*1*) of the remote screen...hitting "Refresh Screen" button of the viewer full remote screen is shown immediately (if I don't hit the refresh button it stays the same way for a long time showing only this little part of the remote screen...gave up waiting for magically auto-reload of the remote screen after a few minutes). This seems to happen frequently using u2 encoding (viewer config: QuickOption=8 + preferred_encoding=10 + autoDetect=0) but not (at all?) with tight enconding. Like previous locking problem I can only reproduce this running winvnc server @win7x64.

(*1*) it is always the little part of the remote screen where the cursor is blinking (I've configured winvnc.exe to lock the workstation after viewer disconnect: so on viewer connect theres the windows login screen showing the currently logged in windows user with the cursor sitting in the password field...)