1.2.1.3 ZIP

[Chris]

in the new UltraVNC1.2.1.3.zip there is an old winvnc.exe in the x64\win8_win10 Folder.

[Rudi De Vos]

updated

[Chris]

Thanks!

[Chris]

Ok now i have found Bug:
Running new Viewer & Server as an Application, crash on Copy & Paste Functions.

[Rudi De Vos]

X64 win8_10 and copy paste some text... ?

[Chris]

Testet on Viewer Win10 x86, Server Win7 x86+x64+Win10 x86. Crash on Copy Text (CTR+C)

[RodolfoGiovanninetti]

I have the same issue using the UltraVNC VNCViewer 1.2.1.3 on Windows Server 2003 R2 English 32.


Regards

Rodolfo Giovanninetti

[ddbivens]

I have installed the VNCViewer.exe and winvnc.exe, from the UltraVNC1.2.1.3.zip file, on about 30-40 systems at work. They are installed on a variety of Windows XP 32bit, Windows 7 32bit, Windows 7 64bit, and Windows 10 64bit systems (plus a few Windows Servers). The majority of the systems are Windows 7 64bit. I have several hundred installs of version 1.2.1.2 on a similar variety of systems. (I won't bother repeating this system information on any future posts.) So far the performance seems to be good when connecting on the local area network. I seem to have found one significant issue that seems to be in the 1.2.1.3 VNCViewer. If the system I am connected to goes offline (if I reboot the system or if I push a new install of VNC to the PC with my batch file which closes the winvnc.exe program prior to the install), then the VNCViewer starts reporting "Not Responding" and never comes out of it. I waited an hour or so one time. A few times I have launched another VNCViewer instance and connected to the PC at the same time as the original VNCViewer window is still reporting "Not Responding". Most of the time I will wait a few seconds to minutes, more than enough time for the PC to reboot or the program to install, (30-60 seconds typical), then I will close the VNCViewer window either by right clicking on the task bar icon, then selecting Close, or by clicking on the VNCViewer window and choosing Close the program that is not responding on the general Windows Explorer message that comes up. It seems the viewer can't recover when the remote PC goes offline for whatever reason.
[Edit]
The 1.2.1.4 beta has fixed the "not responding" issue. I can reboot the remote PC... I can push a new install of UltraVNC to the PC... When I do this the viewer tries to reconnect for the timeout value then either reconnects or closes the window. Actually one time it failed, but every other time it has worked flawlessly. Thank you for the fix!!!

[dimagsv]

I can confirm winvnc 1.2.1.3 x64 crash in service mode when setting clipboard on client.

[Rudi De Vos]

*viewer crash win7 with server on windows 10

I was able to repeat it once..in release mode, still trying to crash in debug to see the crash spot.

R.

[Rudi De Vos]

Looks like the new zlib library ( asm optimized) crash, it was stated that the asm code could contain bugs...

Testing with new compiler zlib options seems to work.
This lib is also used by the encoders, so possible it is causing more trouble then just the clipboard.

[Rudi De Vos]

UPdate
http://www.uvnc.eu/download/1214/ultravnc_1214.zip

[Chris]

C&P seems to be fixed, thanks!

[Skyfighter]

Since my update from v1.2.1.2 to v1.2.1.4 (server and client side) I had multiple viewer crashes; crash-details always showed "SecureVNCPlugin64.dsm" as the module where the error occured. My first guess: viewer crash happens when the server closes the conection (e.g. on server-reboot) - not immediately on disconnect but shortly after that; propably on the first reconnect attempt of the viewer (while the server is still not available/reachable).
[viewer x64 @ win8.1 x64 <-> server x64 @ win10 x64 1607 ; encoding: u2]

Viewer Crash-Dumps: https://app.box.com/s/17g2pv5iu4mwvhmxhqcg305q95bfl0sb
Please let me know if there's anything else needed/helpful...

[Skyfighter]

I went back to v1.2.1.2 because remote control "feels" a lot faster (working is much more fluid) - screen updates with v1.2.1.4 were slower (local lan/wlan and over the internet/wan). (And the above mentioned viewer crashes are gone.)

But of course: when there's a new/reworked version available I'm happy to test it...

[Rudi De Vos]

1.2.1.2 is the version before the ipv6 patch.
Looks like this patch had some bugs. and this could explain the reconnect issue's


Does a 1.2.1.4 server behave correct with a 1.2.1.2 viewer, then i could already limit the trace
to the viewer part.

Is there a setup that allow easy testing, Perhaps it's also OS / CPU Video card related.

R.

[Skyfighter]

Hi Rudi! Thanks for your reply! Hope you are doing well!

1.2.1.2 is the version before the ipv6 patch.
Looks like this patch had some bugs. and this could explain the reconnect issue's

hmm...after your hint I've checked the lan/wifi adapter configuration of my server and client (the machines I had the viewer crashes using v1.2.1.4): on both machines IPv6 protocol is disabled (checkbox of the protocol entry is unchecked) on the used network adapters -> I guess IPv6 should not be used in my case. But perhaps the IPv6 patch you mentioned touches/influences the IPv4-Code anywhere?

Does a 1.2.1.4 server behave correct with a 1.2.1.2 viewer, then i could already limit the trace
to the viewer part.

Did a short test: using 1.2.1.2 viewer and 1.2.1.4 server I couldn't reproduce the viewer crash. *** But I still believe the v1.2.1.2 viewer allows more fluid remote control; not sure how to describe that...it kind of feels like the 1.2.1.4 viewer misses screen updates (not all but a few)...?

Is there a setup that allow easy testing, Perhaps it's also OS / CPU Video card related.

Here are my findings (using 1.2.1.4 viewer and server):
- viewer crash can't be produced using winvnc-server context menu -> kill all clients
- viewer crash happens when the server (while connected) goes into standby
- viewer crash can be reliably reproduced using the following batch on the server ***
(side note: I am using SecureVNCPlugin64.dsm with client/server key and passphrase - did not test it unencrypted!)

batch (run as admin):

Code: Select all

@ECHO OFF

ECHO *** stop service
net stop uvnc_service
REM ECHO ...wating few Seconds...
REM ping -n 11 127.0.0.1 >>NUL 2>>&1
ECHO *** kill raimaining winvnc.exe processes
taskkill /IM winvnc.exe /F
REM ECHO ...wating a few seconds...
REM ping -n 6 127.0.0.1 >>NUL 2>>&1
ECHO *** start service
net start uvnc_service

*** while testing if the v1.2.1.2 viewer behaves correctly withe the v1.2.1.4 server I found out that the viewer instantly consumes 25-50% cpu usage from disconnect (the moment where the v1.2.1.4 viewer crashes) to successful reconnect; the v1.2.1.2 viewer does that with the v1.2.1.2 server, too. I guess there is already a bug in the v1.2.1.2 viewer which got worse because of the IPv6 patch...?

[Rudi De Vos]

ok, i did all test unencrypted.
This can explain the differences

[szymon.nowak]

When 1.2.1.4 official ?

[Rudi De Vos]

1.2.1.5 was released yesterday

[szymon.nowak]

Thanks, I did not see. On the home page does not have this information, Rudi, would you like me to make a new page for UltraVNC, based on some new Wordpress template?

[szymon.nowak]

All bins - The package does not include w2k version

[szymon.nowak]

sources are UltraVNC 1.0.9.6 not 1.2.1.5

[Rudi De Vos]

home page:
I know, was waiting a few days for more feedback...like you did.
When on home page several other sites announce it. Just wanted to limit initial updates a little.

w2k:
Still need to make, as the MS compîlers do not longer support w2k.
Lost old compiler after upgrade to win10.
We still need to reinstall some win7 with VS 2010 to be able to build a w2k version

src:
Will check it.
You can also download the src directly from our public svn
https://sourceforge.net/p/ultravnc/code/HEAD/tree/

[Rudi De Vos]

src is correct
UltraVNC_1084_src.zip
1084 == revision on SVN == version 1215

[Rudi De Vos]

w2K uploaded

http://www.uvnc.eu/download/1215/Ultravnc_w2k_1215.zip

Not signed.
w2K doesn't support sha2 and sha1 certificate is not longer supported

[Skyfighter]

Had a look at v1.2.1.5 and I still can reproduce viewer crashes - or now more often: viewer hangs (app hangs and does not repsond anymore). It looks like the viewer doesn't eat the cpu anymore (25-50% cpu usage on disconnect) but now there's something else strange going on... Rudi did you change anything between 1.2.1.4 and 1.2.1.5? Could you reproduce my problems?

[Rudi De Vos]

1.2.1.5
I reverted back to 1212 removed ipv6 changed and verified other.
SO yes, there has a lot changed between 1214 and 1215

*to test i killed winvnc.exe with the taskmgr.

[sfhub]

Had a look at v1.2.1.5 and I still can reproduce viewer crashes - or now more often: viewer hangs (app hangs and does not repsond anymore). It looks like the viewer doesn't eat the cpu anymore (25-50% cpu usage on disconnect) but now there's something else strange going on... Rudi did you change anything between 1.2.1.4 and 1.2.1.5? Could you reproduce my problems?

Rudi,

You'll recall I was mentioning the server side transfers were freezing/slow until I brought up the the uvnc properties menu (on the server) using the taskbar icon. You then put in a fix for that that resolved the transfer problem. I had tested that using a fast LAN and it did fix the file transfer issue.

However, now that I am testing over slow WAN, I am seeing file transfers hang the client maybe 1 minute into the transfer, eventually causing windows to tell me it has crashed. I went back to 1.2.1.2 client and kept 1.2.1.5 server. I can transfer files with no issues again.

I am also seeing similar crashes to what Skyfighter listed earlier with 1.2.1.5 client.

I can reproduce the viewer crashing when the server goes into standby.