For me, it was obvious the v1.2.1.7 disconnect issue is viewer side, as I've been using it for a short while to connect to various clients on many different OS and several different vnc_server versions. As long as the viewer remained on top and had focus, there was usually no disconnect. Minimizing or even alt-tabbing to another app would result in the viewer disconnecting, at intervals anywhere from ~30secs to a couple minutes.

I've only just begun using the 1.2.2 viewer linked above, but so far have not experienced the issue.

P.S. you are aware of the google reCaptcha upgrade? New users signing up are getting a warning that the currently used captcha expires at eom.

I tested the last official release on my two Win10 machines (which disconnected often and generally were very sluggish), I am now testing this LAN version, both on server and client. I am seeing problems when I am sending CTRL+AL-Del to host (results in black screen, as if UNVC disconnects). And sometimes when I am logging in to the other machine I get a black screen in the beginning but I can get it display right when I redraw the screen. Otherwise it works "ok".

I am looking forward to a stable version for Win10, this is really the only VNC viewer I use.

I just did a quick test again, sending Ctrl-Alt-Del, it immediately stops responding when the gray screen on the other machine comes up. The server itself is still running, since I can always re-connect (it asks for password), I just can't do anything as long as the screen is up on the other machine. Will have to manually log-in again.

Win10 1709 viewer -> XP winvnc as app and as service OKWin10 1709 viewer -> Win7 SP1 64bit winvnc as app and as service OKWin10 1709 viewer -> Win8.1 64bit winvnc as app and as service OKWin10 1709 viewer -> Win10 1709 64bit winvnc as app and as service OKWin 7SP1 viewer -> Win1709 64bit winvnc as app and as service OKTigervnc viewer -> Win1709 64bit winvnc as app and as service OK

There is a force close option in the file transfer - it kills the session completely - is it supposed to be?

adriannla wrote:I've only just begun using the 1.2.2 viewer linked above, but so far have not experienced the issue.

P.S. you are aware of the google reCaptcha upgrade? New users signing up are getting a warning that the currently used captcha expires at eom.

And you use the 1.2.2.0 viewer with the same server version?

Haven't changed any of the server's versions yet... most are running 1.0.9.6.2 (at least a couple at 1.0.2, and there might still be a 1.0.8something? though I might have got all those moved up to 1.0.9.6.2 as well)

adriannla wrote:Haven't changed any of the server's versions yet... most are running 1.0.9.6.2 (at least a couple at 1.0.2, and there might still be a 1.0.8something? though I might have got all those moved up to 1.0.9.6.2 as well)

Is ddengine (Desktop Duplication Engine, elsewhere mentioned as a lightweight graphics engine written in C++ and Direct3D)required to use WinVNC (i.e., does WinVNC rely on it), or is it basically included to optionally add (a better) optimization for screen performance and network traffic/bandwidth?

adriannla wrote:Haven't changed any of the server's versions yet... most are running 1.0.9.6.2 (at least a couple at 1.0.2, and there might still be a 1.0.8something? though I might have got all those moved up to 1.0.9.6.2 as well)

Is ddengine (Desktop Duplication Engine, elsewhere mentioned as a lightweight graphics engine written in C++ and Direct3D)required to use WinVNC (i.e., does WinVNC rely on it), or is it basically included to optionally add (a better) optimization for screen performance and network traffic/bandwidth?

ddengine and vnchooks.dll are both optional. Neither one is required for the server to function, but it has better performance when using them.

Anyone have any issues with 1.2.2.0 (happened as well with 1.2.1.7 but not 1.2.1.5) where if there is a background (like the ones built into windows 7) that the viewer will crash. I've tried multiple types of encoding/format/jpeg (tight) - Quality settings that none seem to help. I changed the colored to black and white and it will finally stop dropping. I have VNC on about 3000 devices and only PC's with backgrounds seem to be having this issue. Taking off the background option seems to stop it. Again, this also happened with 1.2.1.7. Using vncviewer 1.2.1.5 with 1.2.1.7/1.2.2.0 client still has the issue. Using any version of viewer but 1.2.1.5 client does not have the issue. Viewer is running off Windows Server 2012 R2.

I have this problem over a slower VPN network at work when connecting to a remote site and when calling in from home through my DSL (when our ISP is throttling me to near dialup).I get the best results using:ZYWRLE 256 color.and sometimes using:TIGHT 256 color.I hope this helps.

I've been testing with 1.2.2.0 since the pre-release build and I have to say that, personally, I have had MUCH better performance with this version and no issues so far (knock on wood). Great work as usual Rudi

I've tested the prerelease-build (dated 2018-04-18) on multiple Win10 1703 PCs and Laptops (server always running as a service) and for me it is much slower than v1.2.1.7; sometimes it is almost unusable. Not sure what's going wrong... Windows often don't show up (e.g. context menu of the start menu) or a don't go away (partial or complete, e.g. properties window of the winvnc.exe) --> only a manual screen refresh updates the viewer-screen to the actual remote screen (for this moment).Normally I check the performance by clicking on the desktop and moving the mouse around (drawing the rectangle which is used to select multiple icons): at the beginning of a v1.2.2.0 session it is super fast but after a few seconds (e.g. after opening a explorer window) the rectangle is not even showing up anymore + the whole screen-updates don't happen anymore or are extremely sluggish.

I've tested with my normal encodings: Tight and u2; Server properties (as recommended): Only DesktopDuplication and LowAccuracy enabled, LegacyCapture=Auto. I've tried to enable "Poll Full Screen (UltraFast)" and that seems to help a little. All tests were done with SecureVNCPlugin64.dsm enabled (disabling doesn't change anything) on a Gigabit LAN.

The Tooltip of the uvnc Icon shows "... - service - schook" - is that correct? I'm almost sure v1.2.1.7 showed "w8hook", too. (Should the tooltip show something like "ddengine"?) My guess is that the desktopduplication does not work as intended but I have no idea what I could do to investigate that any further. (I've renamed ddengine.dll in winvnc.exe folder, restartet the service and couldn't find any difference in the following remote sessions!?)EDIT: removed schook64.dll from the winvnc.exe folder and now the tooltip of the uvnc Icon shows "... - service - vnchook".

I think I found a little flaw: the cursor shapes aren't updated correctly. For example: trying to resize a window is not that easy; the cursor shape is changed only with a big delay, if any. It kind of lags behind because if the cursor shape changed (e.g. to "horizontal resize") it stays that way a very long time (although it should have returned to the normal cursor shape already). I see this behaviour with- viewer & server (service) x64 @ Win10 1703 x64- viewer setting "Track remote cursor locally" ---> "Let remote server deal with my mouse cursor" solves the problem (as a workaround)(- server setting: "System HookDll" disabled or disabled doesn't matter; left it disabled...)(- a screen refresh does not update/correct a wrong cursor shape)(- encoding doesn't seem to matter; tested tight,u2, ZRLE)

If I connect to a v1.2.1.7-x64 server @ Win7-x64 (using v1.2.2.0-x64 viewer @ Win10-x64) the cursor shapes are updated as intended (viewer setting "Track remote cursor locally") and I can't reproduce the flaw. Seems to be on the server side?

I use VNC-Viewer v1.2.2.0 to connect to different UltraVNC-Servers (v1.2.x.x) over a (stable LTE) mobile connection. During a vnc sessions I get sometimes/often disconnected with the following Info Message:Server closed connection-Manual closed-Network disconn

Is this regular behavior when using mobile connections or is it a bug?

Btw: @Skyfighter and @Rudi - Thanks for the ddengine64.dll hint The Screen looks great and feels fast by little data consumption, nice.