UltraVNC 1.2.2.1 - Download links

[Chaka]

Trying to answer your questions:
Winvnc is running as service.
Had sent you pm with ultravnc.ini already.
I'm using buildin video card (Intel HD 630).
I'm using fixed network.
I have the the issue with and without ddengine selected, e.g. using schook.
When I select hextile or u2 it does not make a difference, sorry.
Blue screen because I'm using fixed ZRLE with 256 colors, you are right using full screen it's black. .

[Rudi De Vos]

In lab we also use the intel HD 630, that card is fast enough.

Using a fix encoder is faster then automode. In automode first fullscreen is always sended as hextile, this take several seconds on
slow network. But you are already using a fix encoder.

The i3 is a dual core and 4ghz is fast enough.
I reverted our tests old athlon 1,3 Ghs as server ( running a server 2008 R2 == win7). This still works, only zrle use a lot of cpu and
i needed to set max cpu usage to 100 in the ultravnc.ini to allow higher peaks.

The viewer cache all updates and show it at once. The full screen is first transmitted and decompressed before the viewer show it.
During this period yoiu have the blue/black/gray screen.

The only thing you can try is to set the maxcpu from 40 to 100 in the ini file.

Using the mirror driver, the cpu used to capture the screen is considered as OS(driver) cpu and not part of the vnc (max 40) cpu
Using the ddengine, the cpu to capture is part of vnc and possible the 40 is not longer a suitable value.

[Chaka]

Strange, the problem is gone, solved, nevermind.
It seams an update has solved the problem with windows 10 (Build: 1803 17134.137)?! I'm sorry, but I can not simulate the problem by myself anymore. I think we have to test with a old untouched Windows build without online updates, maybe pur build 1803?!?


My obsolet findings before then were:

I reverted our tests old athlon 1,3 Ghs as server ( running a server 2008 R2 == win7). This still works, only zrle use a lot of cpu and i needed to set max cpu usage to 100 in the ultravnc.ini to allow higher peaks.

Just to clearify: With Server 2008 R2 and/or win7 there is no intial delay, but with Windows 10 there is!
The blue/black screen is no problem at all. I mentioned it only to have a hint for tracking down the problem. The initial screen color is unreleated to our "initial delay problem", so I suppose.

Using the mirror driver, the cpu used to capture the screen is considered as OS(driver) cpu and not part of the vnc (max 40) cpu
Using the ddengine, the cpu to capture is part of vnc and possible the 40 is not longer a suitable value.
http://www.pchelpware.com

Interesting, thanks for sharing this information.

Conclusion: I suppose the problem is situated somewhere within the Windows 8, 8.1, 10 system. Because whatever I was choosing (ddengine, schook) Windows 10 showed the initial delay. On the other hand Windows 7 has no problem at all with initial delay. At first I hoped ddengine is the problem, but it seams thats not the case. What do you think?

Please try and test with Windows 10. Windows 8 or 8.1 I havn't tried, but I suppose they have initial delay, too.
It would be best you could simulate the problem by yourself. Otherwise it would be hard to narrow down the problem.

[Rudi De Vos]

All test are done with windows 10, real or using a vrtual server.
The only reason i used the server 2008 was that ir run on old hardware, but it is my nasserver... can't easy change OS for testing.

Still have a e350 and ion amd... only don't know if windows 10 even gonne install on it
But it would be a good test pc as all happens a little slower you realy see if something is done 2 times.

If it's windows 10 version depended...we can test forever

[ahzs]

Hello,
can You please add czech language support. Through remote control it is not possible to write letters (ěščřžýáíďň).
Otherwise thanks a lot for amazing software.

[Skyfighter]

Tested svn1130:

MirrorDriver works as expected (tested x64 @ Win7 x64 running as service) - thank you very much!

InitialDelay: Retested with three Laptops (Win7x64-mirrordriver, Win8.1x64-ddengine, Win10-1703-x64-ddengine, Encoding:Auto/Tight/u2, winvnc running as service) and can't reproduce the intial delay with Win7 & Win10 (not sure why it doesn't happen with Win10, I was confident it was there). But: With win8.1 I definately have the 5 sec delay if the desktop is not locked! If the desktop is locked (WinKey+L, Screen shows "Lockscreen Picture" or Login-Screen with username/password field) there is no delay. (choosen encoding auto/tight/u2 does not matter; maxcpu raised to 100 didn't change anything) Thought this observation might be helpful tracking down the cause...

[moe]

initial black screen on win7 server is gone with svn1130.
initial delay on win10 server is still there, just tried it on win10 version 1803 build 17134.165..
max cpu is set to 100, cpu is i5-7500T @2.7 GHz
If the server is locked/not logged in, I also get no delay!

edit: I get the same delay for server in my local 1Gbit network, not only for server over WAN with slow network..

[moe]

okay, I think I got it:
as soon as I rename the uvnckeyboardhelper.exe to uvnckeyboardhelper.exe.bak, and restart the uvnc service,
the initial delay is gone! What exactly does this file do on win10?

Also, a question regarding win8/10 and the new ddengine:
is it still recommended to enable "Poll Full Screen", "System HookDll" and "Low Accuracy" when "Desktop Duplication" is enabled?

[Chaka]

moe - 19. Juli 2018, 14:48: Also, a question regarding win8/10 and the new ddengine:
is it still recommended to enable "Poll Full Screen", "System HookDll" and "Low Accuracy" when "Desktop Duplication" is enabled?

Your question Rudi has answered still here.
In short: disable "Poll Full Screen" and "System HookDll" but enable "Low Accuracy" when using "Desktop Duplication". You can try higher CPU settings, too. Look here for Rudis suggestions, too.

Rudi De Vos - 16. Juli 2018, 10:06: Using the mirror driver, the cpu used to capture the screen is considered as OS(driver) cpu and not part of the vnc (max 40) cpu. Using the ddengine, the cpu to capture is part of vnc and possible the 40 is not longer a suitable value.

[Rudi De Vos]

Thanks for the uvnckeyboardhelper.exe tip, i don't have this exe in all my folders.

This is used to be able to inject special key combinations. was added in win8... don't know if it's still needed

[moe]

okay weird.. I tried reinstalling uvnc from scratch (uninstall, delete all folders, reinstall from win64 exe),
and the uvnckeyboardhelper.exe was installed, too..

[moe]

just tried "send ctrl+alt+del to host", "Send 'Start'", and "Send Custom Key" on a win10 server without the keyboardhelper exe, and they all worked..

[Chaka]

@moe: Thanks for the hard findings.

[moe]

you're welcome

[Skyfighter]

After renaming of uvnckeyboardhelper.exe there is no initialdelay on my win8.1 machine anymore, too!
Great finding moe!

hmm, testing keyboard shortcuts (after renaming the exe) I found out that ALT+TAB does not work on my win8.1 machine (while Scroll-Lock on viewer side is enabled) - that does work on two win10 machine. BUT: it doesn't seem to matter if there's a uvnckeyboardhelper.exe or not; ALT+TAB simply does not work on Win8.1

[Rudi De Vos]

Rebuilding update... svn_1131

The start of the keyboardhelper on win8 is moved to a seperated thread, so vnc is not longer waiting until it's ready.
The alt-tab and some winkey combinations become active after a few seconds, but that's better then keeping the whole server waiting.


I tought that the initial update was to slow because of the initail ful screen update.
Just finished some code that first send a low qulaity jpeg before update the intial screen.
It's still in the code... perhaps give it a try
I tested it by setting my ethernet card in the driver to 10MB half duplex and select hextile

the multi is also moved as requested by Thomas Levering

https://www.uvnc.eu/download/1222/winvnc_svn1131.zip

[Thomas Levering]

This Version Crash after connect.

Windows7 x64 Application or Service

DebugLog

Code: Select all

Fri Jul 20 08:20:40 2018
winvnc.cpp : PostAddNewClient IIIII
vncserver.cpp : AddClient() started
vncclient.cpp : client connected : 192.168.100.164 (1)
vncclient.cpp : Send protocolMsg
vncclient.cpp : Send_OK
Fri Jul 20 08:21:08 2018
vncclient.cpp : Leaving InitAuthenticate
vncdesktopthread.cpp : Hook changed 1
vncdesktopthread.cpp : Hook changed 2
vncdesktop.cpp : No driver used 
 --Das System kann die angegebene Datei nicht finden.
vncdesktop.cpp : no palette data for truecolour display
vncdesktopsink.cpp : InitWindow called
vncdesktopsink.cpp : InitWindow:OpenInputdesktop OK
vncdesktopsink.cpp : InitWindow:SelectHDESK to Default (284) from 24
Fri Jul 20 08:21:09 2018
vncdesktopsink.cpp : wmcreate  
vncdesktopsink.cpp : OOOOOOOOOOOO load hookdll's
vncdesktopsink.cpp : OOOOOOOOOOOO start dispatch
 --Die angegebene Prozedur wurde nicht gefunden.
vncdesktop.cpp : Sethook_restart_wanted hook=1 driver=0 
vncdesktop.cpp : Hookdll status changed


 
Fri Jul 20 08:23:11 2018
winvnc.cpp : PostAddNewClient IIIII
vncserver.cpp : AddClient() started
vncclient.cpp : client connected : 127.0.0.1 (1)
vncclient.cpp : Send protocolMsg
vncclient.cpp : Send_OK
Fri Jul 20 08:23:30 2018
vncclient.cpp : loopback connection attempted - client accepted
Fri Jul 20 08:23:31 2018
vncclient.cpp : Leaving InitAuthenticate
vncdesktopthread.cpp : Hook changed 1
vncdesktopthread.cpp : Hook changed 2
vncdesktop.cpp : No driver used 
 --Das System kann die angegebene Datei nicht finden.
vncdesktop.cpp : no palette data for truecolour display
vncdesktopsink.cpp : InitWindow called
vncdesktopsink.cpp : InitWindow:OpenInputdesktop OK
vncdesktopsink.cpp : InitWindow:SelectHDESK to Default (2a4) from 24
vncdesktopsink.cpp : wmcreate  
vncdesktopsink.cpp : OOOOOOOOOOOO load hookdll's
vncdesktopsink.cpp : OOOOOOOOOOOO start dispatch
 --Die angegebene Prozedur wurde nicht gefunden.
vncdesktop.cpp : Sethook_restart_wanted hook=0 driver=0 
vncdesktop.cpp : Hookdll status changed 

[Thomas Levering]

a small Bug in vncviewer.exe

options.vnc
[options]
selectedscreen=0
fullscreen=0

Server and Client Multimonitor
if I change to FullScreen and then back to Window Mode. The Second Monitor is Black -> selectedscreen=1
I can click SwichMonitor until selectedscreen=0 -> OK

[Skyfighter]

Thanks for the Update, Rudi!

short test svn_1131 @ Win8.1 with uvnckeyboardhelper.exe existing in winvnc.exe-folder...
- ALT+TAB works flawless with that version [**3**]
- no initialdelay anymore

but:
1) At the beginning I made some short viewer connections to test the InitialDelay (connect, saw remote screen, wait 3-4secs moving cursor around, close viewer, connect again, ....). Every second connect attempt failed -> instead I got "VncViewer Messaage Box - Server closed connection, -Manual closed, -Network disconn" [**1**]. At least one time the connection has been established, but after a few seconds (while moving remote cursor around) the viewer got disconnected according to the window title of the viewer (still saw the last screen of the remote-desktop) [**2**]...after a few seconds the viewer successfully reconnected.
2) After ~10 connection attempts I recognized multiple VNC Icons in the taskbar (next to date/time) on the server side: moving the cursor over them all disappeared except one. Looks like the sever crashed multiple times.
3) Connecting the viewer (while remote machine is on Desktop, not locked) I can see how the first low res screen get's replaced by the high res version (from top to bottom) with tight encoding (viewer encoding setting: manual, tight) - that's OK. But sometimes (even after the highres refresh finished) the screen updates are very sluggish (e.g. selecting Desktop Icons: hold left mouse button, move around the cursor -> most of the time the blue select-rectangle is not visible).
=> There seems to be some kind of instability on the server side!?

after further testing:
[**1**] While viewer shows the message box on server side one of two winvnc.exe process goes away and comes back after few seconds (creating a new/additional vnc icon in the taskbar).
[**2**] On server side it looks like: a uvnckeyboardhelper.exe process is created, then it goes away, second winvnc.exe-process goes away (viewer gets disconnected), second winvnc.exe come back...uvnckeyboardhelper.exe process is started. Then the viewer-connection looks stable.
[**3**] ALT+TAB does not work always...sometimes the uvnckeyboardhelper.exe goes aways and doesn't come back leaving ALT+TAB without function.

[s]I like the idea of the initial lowres screen but perhaps that feature should be removed from source code until the InitalDelay has been solved successfully?[/s] From my point of view svn1130 looked much more mature.
After further testing I re-applied moe's workaround (renaming uvnckeyboardhelper.exe = disable it)...that looks totally different: can't get the server/viewer to crash anymore; only one single vnc icon in taskbar - no matter how often I connect / how fast I reconnect after closing the session. uvnckeyboardhelper.exe is definately the culprit, but your change (comparing to svn1130) converted the InitialDelay into a instability on the server side. Might your thread heandling of uvnckeyboardhelper.exe yould be "optimized"? Or Perhaps uvnckeyboardhelper.exe has a fundamental bug? Perhaps there are better ways to do what uvnckeyboardhelper.exe should do?

the multi is also moved as requested by Thomas Levering

What is "the multi"?

Argh, sorry! Never meant to write so much bullsh**

[Thomas Levering]

@Skyfighter
Commandline -multi
PostToThisWinVNC and not to other instance
https://forum.ultravnc.net/viewtopic.php?f=72&t=33999

I have Compiled 1131 from Source -> no crash
can´t repeat it in debugger
1131 from Forum Crash

Visual Studio 2017 Pro (15.7.4)

[Rudi De Vos]

You are correct...first it need to be stable before adding something new.
As developer i Always want to add new stuff

I gonna revert back, having the svn in sync with te test it just a mouse click,
and just add the small Multi and keyboardhelper change.

The preview screen looks for me like a nice addon... for a next update in a few months.

[Skyfighter]

@ Thomas Levering
Thanks for the link!

@Rudi
I like the idea with the preview screen, too! Especially on mobile devices with slow connections this should be very useful. But may I suggest a server-ini-setting to optionally disable it? (On PCs in the same lan I personally don't really need the feature because gbit lan is more than fast enough.)

I've searched a littel bit regarding ALT+TAB @ Win8.1 and found an old topic with posts from you, Rudi:
https://social.msdn.microsoft.com/Forum ... simulation
Looks like uvnckeyboardhelper.exe should make at least two shortcuts functional: ALT+TAB (toggle between windows) and WIN+X (context menu of the start-button). Without uvnckeyboardhelper.exe these two shortcuts don't work under Win8.1, but on Win10-1703 they do work!
-> The whole uvnckeyboardhelper.exe is only needed on Win8 / Win8.1!? If that's true I would start/load the uvnckeyboardhelper.exe only on Win8 & Win8.1. => Is it possible to check the os pre loading the uvnckeyboardhelper.exe (or alternatively add an server-ini-parameter which enables uvnckeyboardhelper.exe and is off by default)?

Another shot in the blue: could the problem be related to the old signature of the uvnckeyboardhelper.exe?

[Rudi De Vos]

The keyboardhelper is only used when WIN8 is detected. All other OS's skip it.
This was always implemented like this and also the reason it was so hard to detect.

Start keyboardhelper.
winvnc running as service-> start a winvnc instance high security level as app-> this app start the keyboardhelper
The keyboardhelper has a special manifest setting and can only be started from an app, that setting block that it is started from a service. After the start vnc and the keyboardhelper setup shared memory... The whole chain just take time.
Change
The shared memory setup now run in a seperated thread, independed of the vnc startup.
We gain several seconds with it.

[Rudi De Vos]

Damm windows 10 also answer he is 6.2 so the switch isn't working...looks like MS answer 6.2 for all OS >= windows 8

[Rudi De Vos]

Update svn_1132
This is 1130, with only some minor changes.

*OSdetection changed, Getosversion() was absoluted for win10... all higher then 8 was detected as 8
*keyboardhelper is only used for windows 8 and when used it's started in a seperated thread
*multi patch

I hope this wil be stable and faster for all OS's. so final can release something stable.

removed test

[Skyfighter]

Did a short test with server running as service on win8.1 x64: can't tell if there's a difference to svn1131
- keyboardhelper works only temporarily **1
- multiple server crashes (viewer doesn't get any screen updates, on the server side one of two winvnc.exe processes dies and comes back, then viewer reconnects and afterwards there are two vnc icons in the taskbar until you hover them with the cursor)
((- viewer crashed two times (running at win10x64); multiple times viewer process stayed active although the windows has been closed))

**1: on the server side looking at the taskmanager you can see the following when a viewer connects
1) uvnckeyboardhelper.exe process is started for ~1 second then it goes away
2) 3-5 seconds: nothing (I'm not sure, but I believe in this time-frame the viewer can control the server but the viewer doesn't get any screen updates or at least the screen updates are very sluggish)
3) uvnckeyboardhelper.exe process is started...ALT+TAB & WIN+X work...
4) (not always but often) a short time later (round about 10-30 seconds): uvnckeyboardhelper.exe dies again...ALT+TAB & WIN+X don't work anymore...(if that happens it doesn't come back anymore)

Step (1) and (2) seem to be very fragile, it seems like something is out of sync? (Not sure, but a viewer input - e.g. clicking on something - in this time frame possibly raises the risk of crashing the server.)
Is there a reason, that the first uvnckeyboardhelper.exe session in (1) always quits after ~1 second?

[Rudi De Vos]

Installing a win8 on a VM for testing.
I was testing on a windows 10 with enabled keyboardhelper , perhaps ther was a good reason for the initial timeout
( prevent a crash)

[Rudi De Vos]

Gonna take more time.
The problem manifest himself on windows 8, but the cause is some destructor not working 100%.
Making a thread of of sync.
That's code, digging...

[Thomas Levering]

Compare SVN1132 <-> SVN1130

Without this Lines (DebugCode?) no Crash Windows7x64
Crash only if not Compiled as Debug

// if (encoding == m_encoding)
// return TRUE;

vncencodemgr.h

Code: Select all

inline BOOL
vncEncodeMgr::SetEncoding(CARD32 encoding,BOOL reinitialize)
{
	if (m_scrinfo.format.bitsPerPixel!=32 && encoding==rfbEncodingUltra2)
	{
		//This is not supported, jpeg require 32bit buffers
		//to avoif a server crash we switch to zrle encoding
		//hextile is better as u2 replacement
		encoding = rfbEncodingHextile;
	}

//	if (encoding == m_encoding)
//		return TRUE;
	if (reinitialize)
	{
		encoding=m_encoding;
		if (!m_buffer->CheckBuffer())
            return FALSE;
	}
	else m_encoding=encoding;

[Rudi De Vos]

crash only in relaese and not debug -> bad initialization.

The check isn't that bad but indeed the inital encoder need to be init to unkown or so.

During tests i noticed that sometimes encoder is switched to himself, and with the erase of the backbuffer this cause a full screen
to be send... this give a "hick" on slower networks.

Current running tests on win8 and win10, 8 behave different... wil add a release run before puching but on the other hand
pushing also let other people debug.

I still have a daytime job and limited to a few hours in the evening, any help is appriciated.