thanks for the feedback, i forgot to update the w2k build.With the signing ( that change the date) i don't know if the w2K version is correct with wrong version info or not.Gonna update all zip/installer that contain the w2k server.

w8hook; use the new duplication engine on win8. I's 10x faster then without . I always would install this one.schook/vnchook: both hint the system about possible screen changes ( using a different method), vnc detect faster the with pure pollingWhen both are installed only schook is used.

You can use pure polling without any hookdll. It use more cpu but if you only need to connect a few minutesto verify something it doesn't gonna make a big difference.

Short: You can run without, but the dll's make vnc faster. The speed gain depend on the systemand on the application. You need to try what works the best for you.

Having noticed that schook does not feature as frequently in your releases, are you in favour of vnchooks?

I ask because from a debugging point of view, would it not be better if we all tested using exact same set-up, or does it not make any difference to core function (i.e.: cannot influence crashing or screen update issues)

FYI: previous to this latest release (1193), the schook(64).dlls I had dated back to 10/09/2012 (the last version I have used was 1191) - I always download all your releases (zipped binaries, setup exes and now the msi's) in the hope I get all the latest code, as I understand it must be complicated to keep a handle all all these releases, especially at the frequency you're producing!

Again, thanks in advance, and apologies if you'd read my previous version of this post; I've obtained the latest schook.dlls from the Addons packages, both dated 14/08/2013 @ 15:27

Be aware: The addon setup installs dlls dependent from you OS. Not only differencing between 32- and 64-bit. 2000, XP-7 and Win8 also. If you plan to pick out the schook.dll for repackaging, be shure to have the universal one (build for w2k and above). A fault I made myself.

Be aware: The addon setup installs dlls dependent from you OS. Not only differencing between 32- and 64-bit. 2000, XP-7 and Win8 also. If you plan to pick out the schook.dll for repackaging, be shure to have the universal one (build for w2k and above). A fault I made myself.

Thanks for the reminder. I always repackage to simplify / customise deployment, so I'm well aware of that behaviour (it's a bit annoying, frankly speaking!)T

With regard to 1.1.9.3 - it's by far the most stable version of the recent builds. No unusual behaviour, no crashes or lock-ups for both LAN and WAN. The viewer switches to the u2 encoding more often than not, which is useful under most conditions

However, I have similar / identical problems to report regarding stability under the reverse connection scenario, whereby if either the initiator or listener computers have a weak or inconsistent internet flow, the listening vnc viewer regularly produces CPU-spikes, the process becomes deadlocked, and crashes. It's not unusual for those three events to follow in sequence, but they don't always occur in that order (not reproducible mainly because of the unpredictability of internet fluctuation)

I'll provide more detail / conclusions following some other live sessions

Hi Rudi,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 1.1.9.3 x86 and x64 and Win8 variant wherever applicableViewer uses the following command line parameters:/listen 5511 /quickoption 10 /autoscaling /reconnectcounter 0 /autoreconnect 0 /autoacceptnodsm /autoacceptincoming /notoolbar /disablesponsorViewer tested on Windows XP and Windows 7 and reports as being version 1.1.9.1 (although it was obtained via the 1.1.9.3 package)

Cases: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!

On connection with a slow network ( GPRS) the viewer stay black and after a while the cursor change in a dot, even if youhover over the buttons.

Cause:Om slow connections, zrle is used by the auto settings.

The zrle encoder lock the screenbuffer while updating, but unlike other encoders it download data in the encoder.As a result the screenbuffer stay locked for minutes. But in some other part of the code the screenbuffer is usedto show mouse updates. In normal cases you only have a update lock for a few ms, but now the lock is minutesand the full viewer start locking all his threads as all are waiting for the unlock. Viewer become unresponsive and die.

The difference with the other encoders is that they only lockscreen before changing the screen buffer en unlock after.The download part isn't in the lock.

Solution:Zrle lock mechanism changed to exclude the network part.For the initial screen, we now show each individual rect, instead of a black screen for minutes you now see the screen being build.It take the same time, but you have a feeling it's faster because you see what is happening.

Still testing, the network tool realy is a nice addon for testing uvnc. It also has other settings that even can simulate network losses/disconnects/packets reorders etc...I hope to upload some test viewer this weekend

May I be the first to express my excitement about these new developments!! Woo hoo!Erm... where was I?

I'm back from (very fricken windy) holiday now and I have a remote session in the morning... I will use the test viewerI presume from what you've said, that I allow it to choose its own encoding? The client will be connected wirelessly and I would say their signal strength is typically 50-75%

As posted, I've used the test version viewer with excellent results on XP and Win7 x86. Stability retained over a period of over six hoursThe only major anomaly to report was a file-transfer hang that resulted in a viewer crash. The server detected a loss of connection and resumed normally on reconnectPartial file-transfer resumed without problems.Many many thanks! I guess I'll get on with 1194... seeing as you appear to be blitzing the bugsT

My builds are essentially identical, however, I can install UVNC 1.1.9.3 X64 on one Machine, set it in a remote location, and install the same program on another identical machine, and set it in a different location and have the ability to control one machine and no ability to control the other machine. One I can fully control, and the other is like Read Only ability. It is a bizzare behavior that is totally random.