UltraVNC 1.2.2.1 - Download links

[Rudi De Vos]

Latest online version is svn1146

Virtualbox... i'm gonna test that one, this will allow to detect if the ddengine can work or not.
Didn't found any testing pc for it.

Hyper-v with windows 10 is working.

[Rudi De Vos]

virtualbox windows 10 with ddengine ON
I get an inital black screen, but after moving the mouse after a few seconds the viewer works and ddengine is ON

Installing debugger to see what happen

After installing the virtualbox addons screen stay black...

[Chrispy]

Rudi, I tried the desk. dup. example from MS and it stays black too, looks like it will not work, so VirtualBox without Desk. dup. needs to be tested instead.

[Chrispy]

test results for win 7 w/wo mirror, same graphic card.
2 monitors
- Secondary Monitor on all sides works
- 4k Monitor stops mirror Driver from being loaded
- Monitor switching updates and mouse correct

Win 10 w/wo DDEngine, same graphic card
2 Monitors:
- Secondary works on all sides
- 4k Monitor works, must stop and start server or a crash will occur
- Monitor switching correct updates and mouse
3 Monitors
- Secondary works on all sides
- Third works on all sides
- Monitor switching updates and mouse correct

Win 10 VirtualBox wo DDEngine
1 and 2 mon
- Second Monitor on all sides works

[SkyBeam]

Sorry for late reply. I was using this one, so it's svn1146.

I see there are some potential issues with the D3D driver in virtualbox. It's also causing come display corruption at least in Windows 10 1803. So it might be partially broken. However the driver is required for desktop composition effects.
I am happy you could also confirm the black-screen issues with installed VirtualBox addons and ddengine. My remark was just that perhaps such behavior (which might also appear with broken graphics drivers for real/physical hardware) we might fall back to schook to capture screen contents. Capturing anything is better than being left with black screen, even if it's less efficient.

[Rudi De Vos]

SkyBeam ,

Indeed using the virtualbox is a good test to try to detect "broken" video cards

[Rudi De Vos]

Virtualbox.

ddengine doesn't give any error.
All function answer OK, only the driver doesn copy any data in the buffer.
Looks like the implemented some "fake" functions that answer OK, but doesn't do anything.
This makes it hard to detect...

[SkyBeam]

Virtualbox.

ddengine doesn't give any error.
All function answer OK, only the driver doesn copy any data in the buffer.
Looks like the implemented some "fake" functions that answer OK, but doesn't do anything.

Well, isn't the fact that there is no data in the buffer sufficient to detect this?
I suspect that initially the complete screen is requested from ddengine. If the buffer is empty (or filled with all zeroes) this can be detected and ddengine could return an error like "unsupported" in order to force fallback to schook.

I agree that we should not spend too much time on this small issue since it seems to be related to a broken implementation. However it might be sufficiently easy to detect so a work-around could be implemented. I think there might be the same hack implemented in other graphics drivers out there and just the fact virtualbox does it this way shows that others might do it as well. The problem here I see is that if it's not detected by UVNC you're left with a black screen and you can't even remotely go to settings to disable ddengine. So you're kind of blocked.


Anyway other issues like the re-initialization after screen configuration change or optimizing the main loop to allow faster re-connect might be more useful when fixed.

[Rudi De Vos]

No, a screensaver can also have a black screen.

This wil work
if video driver name contain "VirtualBox ..." DDengine return not supported

When ddengine fail, i now activate polling so the screen is at least responsive.
Update ddengine and winvnc online

[SkyBeam]

Of course, very valid remark about screensaver. However I didn't see any black-screen screensaver recently. Unless ddengine also returns black screen when connecting to a machine where the screen is off, but this is done via DPMS usually, not sending black screen. Moreover this detection would only be required on initial full-screen "dump" and not on every frame. So if the screen goes black it should not trigger, only if the screen is entirely black on initial request.

Perhaps you could check for "black screen" or empty buffer only on virtualbox driver. Just checking for virtualbox drivers and then sort of blacklisting it seems to be a bad idea to me. There might be already a bug report on virtualbox and this might be fixed in the future. Hard-coding a blacklist would then disallow to use ddengine on any future virtualbox driver which might work just fine. Moreover you would perhaps have to maintain a list of blacklisted drivers and versions and you certainly don't want to do this.

So I recommend to investigate a bit more if it's possible to detect "black screen" on new connections only. Perhaps a mouse move needs to be sent first which would disable the screensaver. Or check if any screensaver is currently running during connection. Nowadays nobody uses screensavers any more anyway and I haven't see any black-screen screensavers since years. Therefore I recommend if you want to blacklist the virtualbox drivers, try to detect if virtualbox driver is running and if it returns black screen it should not use ddengine. So worst case is VirtualBox fixes the issue and somebody configures a black-screen screensaver which would fall back to schook unintentionally, but in most cases it wouldn't, without touching the code.


Not sure if there would be any way to detect via ddengine that the driver does not return a correct screen dump (even if it's black) by checking the color depth or querying other screen attributes from the driver.

[Chrispy]

All my installations, I know what the hardware is and can do at the time of installation and testing, and the UlraVNC gets set accordingly. So, for VirtualBox I turn it off. I think most of the people will use this method of installation, then configuration. Therefore, there is really no need to spend much time on this issue.

There is only the fact that you might, on your web site, let the people know that the currect VirtualBox does not support DDEngine, so they don't go hunting around thinking they did something wrong.

It could be that you ask VirtualBox (Oracle) to support or if they support Desktop Duplication (just in case it is currently a bug), or will in the future.

[SkyBeam]

There is only the fact that you might, on your web site, let the people know that the currect VirtualBox does not support DDEngine, so they don't go hunting around thinking they did something wrong.

It could be that you ask VirtualBox (Oracle) to support or if they support Desktop Duplication (just in case it is currently a bug), or will in the future.

I agree. I would rather not blacklist VirtualBox and just document that it is broken. If there is any possibility to detect broken drivers in a generic way it should be implemented. But blacklisting individual drivers is not a solution we want to maintain.

Personally I do rollout UVNC in unattended mode using WPKG, so I don't usually do manual configuration. So by default I do enable ddengine on all deployments.

[Chrispy]

ok, the unattended rollout. But, you could in your installer, check if it is VirtualBox? I have actually added to my version a inipath Parameter, so that I can start winvnc with different ini files.

[SkyBeam]

ok, the unattended rollout. But, you could in your installer, check if it is VirtualBox? I have actually added to my version a inipath Parameter, so that I can start winvnc with different ini files.

That's a cool feature too. My installer already makes some decisions currently and then using sed to change some parameters according to the system it runs on. But of course I would like to do as few adjustments as possible and would still prefer UVNC not just to show black screen on any system. Also not on a system where desktop duplication used to work and then all of a sudden (e.g. after graphics driver upgrade) I cannot see the screen any more without any possibility to recover without physical access to the machine. That's why I would prefer to detect such a situation and provide a fallback.

The screensaver argument is valid but I think it's not really relevant. On very first connection if (and only if) the user would have a custom screensaver which just displays a black picture, UVNC would fallback to disable ddengine. However I would for sure move the mouse on the black screen and therefore disable ddengine. My session would continue of course with schook but if I want to switch to ddengine again, I could simply disconnect and re-connect before the screensaver kicks in again. So I would see little risk to check if the very first initial screen captured is all black and if it is, then disable ddengine for this session. Up to discussion however.

Another issue I am facing but this is actually perhaps just me. If I got multiple winvnc.exe (UVNC server) instances running they seem to block each other. Not only they don't respond to connection requests but they also cannot be shut down properly except hard-killing the processes. I am not sure if this is a bug or by design multiple desktop catching applicationd will not work. I rather suspect it's an UVNC issue.
Sure, you might ask why I do run multiple UVNC on a single machine. The reason is that I have one service configured to use repeater connections (which works via NAT too) and one service configured to listen on port 5900 for LAN connections. The service with repeater connection is disabled by default but is allowed to be run by users without admin privileges. Unfortunately if the LAN instance is running and then the repeater instance gets run both of them will lock up. If the LAN instance is shut down properly then the repeater instance works fine.

[Chrispy]

Sure, you might ask why I do run multiple UVNC on a single machine.

I do this too, listening at different ports and settings, with different ini files.

It shouldn't be a Problem with ddengine, unless your graphic card can handle not enough desktop duplications. I will test this, because I need it too.

Just tested, win 10 same graphic Card, 2 winvnc one at 5900 and the other 5700 with 2 diff. ini files, no repeaters. Works great.

[SkyBeam]

Just tested, win 10 same graphic Card, 2 winvnc one at 5900 and the other 5700 with 2 diff. ini files, no repeaters. Works great.

OK. I will test this soon again. I actually tested it in version 1.2.2.1 where ddengine was not working so perhaps the issue only appears if ddengine is not used.

EDIT: I just tested multiple instances and it did not work. As soon as the second instance is running both instances freeze. A difference in our setup might be that you just used a different INI while I am using two completely independent copies of UVNC installations (two binaries, both on same version however). The inipath arguments seems not to be available in SVN builds from Rudi.

Another thing I noticed just now:
I connected on LAN to the latest version (1.2.2.2, svn 1148) and I see the winvnc.exe process taking really a lot of memory. In fact the service process seems to take around 1.2MB but the user process seems to grow ~15MB per second according to task manager until it reaches 1.5GB memory usage. Then immediately it drops to ~40MB, then growing again to ~1.5GB and dropping. Looks to me like some buffers are not properly cleared. On low-end systems 1.5GB just for UVNC is quite a lot. Any ideas?

[Chrispy]

hmm, the Memory Problem I do not have, mine are 2 x winvnc.exe at 53 - 69 Mb per winvnc.

-inipath, I have only added to my code, I am trying to get the OK from Rudi to add it to the master.

[SkyBeam]

-inipath, I have only added to my code, I am trying to get the OK from Rudi to add it to the master.

I tried differently...
Running winvnc as service from %ProgramFiles%\UltraVNC, then replacing the ini file and launching the second service using reverse connection ini from the same folder. The results for me are the same. My connection is dropped and the service locks up. And yes, it's using the mirror driver. I also have enable auto port selection and also tried with different manual port assignments at no avail. Both services run "winvnc.exe -service".

I am not sure what is different in our setup.

Just for reference I am adding my ini files:

Service 1, for normal LAN listener

Code: Select all

[admin]
UseRegistry=0
MSLogonRequired=1
NewMSLogon=1
DebugMode=0
Avilog=0
DebugLevel=8
DisableTrayIcon=1
LoopbackOnly=0
UseDSMPlugin=1
AllowLoopback=1
AuthRequired=1
ConnectPriority=0
DSMPlugin=SecureVNCPlugin64.dsm
AuthHosts=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=1
DefaultScale=1
CaptureAlphaBlending=1
BlackAlphaBlending=0
primary=1
secundary=0
SocketConnect=1
HTTPConnect=0
XDMCPConnect=0
AutoPortSelect=0
PortNumber=5900
HTTPPortNumber=0
IdleTimeout=20
RemoveWallpaper=1
RemoveAero=1
QuerySetting=2
QueryTimeout=10
QueryAccept=1
QueryIfNoLogon=0
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
kickrdp=1
service_commandline=
FileTransferTimeout=30
BlankInputsOnly=0
secondary=1
path=C:\Program Files\UltraVNC
accept_reject_mesg=
DSMPluginConfig=
clearconsole=0
IdleInputTimeout=0
KeepAliveInterval=5
rdpmode=1
[admin_auth]
group1=vncusers
group2=
group3=
locdom1=1
locdom2=0
locdom3=0
[ultravnc]
passwd=190576766E68881C84
passwd2=190576766E68881C84
[poll]
TurboMode=0
PollUnderCursor=1
PollForeground=1
PollFullScreen=0
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu=0
EnableDriver=1
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=

Service 2 for repeater connection via NAT

Code: Select all

[admin]
UseRegistry=0
MSLogonRequired=1
NewMSLogon=1
DebugMode=0
Avilog=0
DebugLevel=8
DisableTrayIcon=1
LoopbackOnly=0
UseDSMPlugin=1
AllowLoopback=0
AuthRequired=1
ConnectPriority=0
DSMPlugin=SecureVNCPlugin64.dsm
AuthHosts=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=1
DefaultScale=1
CaptureAlphaBlending=1
BlackAlphaBlending=0
primary=1
secundary=0
SocketConnect=1
HTTPConnect=0
XDMCPConnect=0
AutoPortSelect=1
PortNumber=55900
HTTPPortNumber=0
IdleTimeout=20
RemoveWallpaper=1
RemoveAero=1
QuerySetting=2
QueryTimeout=10
QueryAccept=1
QueryIfNoLogon=0
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
kickrdp=1
service_commandline=-id:12345 -autoreconnect -connect host.domain.tld:5500
FileTransferTimeout=30
BlankInputsOnly=0
secondary=1
path=C:\Program Files\Service-Install-Path\
accept_reject_mesg=
DSMPluginConfig=
clearconsole=0
IdleInputTimeout=0
KeepAliveInterval=5
rdpmode=1
[admin_auth]
group1=vncusers
group2=
group3=
locdom1=1
locdom2=0
locdom3=0
[ultravnc]
passwd=190576766E68881C84
passwd2=190576766E68881C84
[poll]
TurboMode=0
PollUnderCursor=1
PollForeground=1
PollFullScreen=0
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu=0
EnableDriver=1
EnableHook=1
EnableVirtual=0
SingleWindow=0
SingleWindowName=

[Chrispy]

The difference is, I am not running Services, Rudi just explained that Services clone the same console. That could be where they are locking up.

[SkyBeam]

The difference is, I am not running Services, Rudi just explained that Services clone the same console. That could be where they are locking up.

OK, this might be it. Not sure if there would be a work-around for this. I need both instances to be running as service since I am in need of switching users remotely.

[SkyBeam]

hmm, the Memory Problem I do not have, mine are 2 x winvnc.exe at 53 - 69 Mb per winvnc.

This indeed is interesting. Are you using the release compiled by Rudi located here?

Indeed I can reproduce this on eavery connect (ddengine). It immediately disappears if I disable the driver. With schook the memory consumption is ~30MB for the second winvnc.exe.

I found that the memory grow rate is influenced by screen changes. So the more dirty rects I produce by moving things around and changing screen content the faster the memory grows.
See graph here:


Or consumption:


I can't reproduce this grow on VirtualBox, even not when usind ddengine (with black screen). So I might have to try another physical machine with different graphics driver.

EDIT: Also tested this now on an older Dell E6400 Laptop with Intel 4-Series graphics chip running WDDM 1.1 driver. No memory leak here. The machine showing this issue runs an ATI Radeon HD 3200 graphics. What is puzzling me a bit is that the memory consumption seems to grow always to 1.5GB and then the complete memory seems to be released just to grow again. Perhaps this could be influenced with some buffer flushes.

EDIT2: Tried another machine with AMD Radeon R9 270X + Intel HD Graphics 4600 (both active but only 2 screens connected to Radeon Card). It showed a memory usage of ~75MB with no obvious memory growth.

EDIT3: Tried different encodings too with no success. All of them seem to show the same memory leak on this machine with Radeon HD 3200 graphics. Interestingly I never lose the connection, not even when the memory consumption is "flushed". I also switched this machine quickly to the "Microsoft Basic Display Adapter" Driver which surprisingly supports desktop duplication as well obviously. The memory leak is gone then too. I even switched back to the AMD Driver (version 8.970.100.9001 dated 2015-01-13) remotely via VNC without any issues (auto-reconnects, no viewer crash) and bang, the memory leak is back. So it's for sure something with the driver. The question however remains whether there is anything UVNC could do about this.

EDIT4: I tried also to install the latest driver for Radeon HD 3200 from AMD driver download pages with the same result. The memory leak is there too. But likely the drivers are almost identical. However it's officially only for Windows 7 but can be installed on my Windows 10 without any issues. The driver I tried is tagged with version 8.970.100.1100 dated 2013-04-29. So actually both drivers work, but show this terrible memory leak issue.


Another (cosmetic) issue that bothers me a bit:
Would it be possible to rename the "Edit Settings" Short cut to "UltraVNC Settings"?
I know the icons are grouped in a folder called "UltraVNC" but Windows 10 prefers a flat structure and also when searching for "UltraVNC" only "UltraVNC Server" shows up in start menu search. If I look for UltraVNC server settings it's hard to find this way.


PS. Sorry for spamming the forum here. I certainly don't want to waste yours and my time on broken graphics drivers. But it seems we are using a technology here which is still not perfectly adapted by driver implementers and we might face some issues here. Unfortunately there is likely no way to remotely select the driver type you want to use (like it is via the encoding). Unless we are going to implement "dummy" encoding types like "ultra with forced schook" so the encoding selected also could force to use another screen capturing method via remote/viewer selection for special cases like broken remote host drivers. I personally think ddengine is the right way to capture the screen but if I would have to support an unknown variety of hardware I am currently better off disabling ddengine and usind more compatible schook method as I might be left without any remote screen if the remote machine decides not to play well with desktop duplication after an update/driver-upgrade etc.

[Chrispy]

I think personally, that changing capture method from a remote (admin panel), is a very good idea. Like SkyBeam says, change anything about the machine graphics and you can't get in, that would be really bad.

P.S. the -inifile Parameter is now in as of r1150.

Code: Select all

Usage: winvnc -multi -inifile D:\ultraVNC\ultraVNC_5900.ini -run

[Rudi De Vos]

I guess the following can happen.
-During capture, the screen is locked
-The ddengine API don't want to block the screen, so all data is moved to memory for being processed
-On fast moving screens, this happen faster then directx can handle and captured getting cached

The caching can use a lot of memory 1920x1200x4 +- 9Mb for a single frame

[SkyBeam]

I guess the following can happen.
-During capture, the screen is locked
-The ddengine API don't want to block the screen, so all data is moved to memory for being processed
-On fast moving screens, this happen faster then directx can handle and captured getting cached

This still does not fully explain why this happens to me on one machine with AMD/ATi display driver only. It also happens when the screen is blank and there is nothing moving. So it must be something internal. As written it completely disappears when the genric display driver is used (which usually is pretty slow).

Currently on this machine there is only 1 screen connected with 1680x1050x32bps settings. So it shouldn't use more than ~6.5MB per capture. I am not sure how I could debug this further and I doubt the engine should cache more than the frame it's currently processing (and probably the previous one to diff). So it's not clear to me why I sometimes get something about 15-20MB/s memory increase without anything moving on screen (except updating task manager).

But as said, this is simply one of the potential glitches with desktop duplication. We have to expect even more issues with all the various drivers out there in the wild. So yes, it would perhaps be great to have the option to force a specific capture method from client-side when connecting. On the other hand this brings server functionality to client side which is not ideal either. Also I am not sure if the RFB protocol would allow such UVNC-specific parameters to request "blacklisting" of ddengine for one session. Basically we would look for a switch so UVNC viewer could ask the server to use "slow but safe" screen capturing rather than more efficient methods.

For now I think the issue with ddengine are clear and usually it works if the graphics driver is working properly. I recommend to have a more close look at potential issues reported earlier when screen configuration changes (viewer does not show second screen unless toggling between them) or viewer crashing when re-arranging screens or viewer showing "garbage" when re-arranging screens which indicates incorrect updates (it might need a full re-initialization of the encoding buffer whenever screen orientation or geometry changes).
Perhaps those changes and further testing can be left for an upcoming version and the current implementation is good enough for a release. Certainly better than the current 1.2.2.1 version with broken ddengine.

[Chrispy]

Fixed Initial screen updates and mouse when the 2nd Viewer connects, in r1151

[SkyBeam]

Just talking about cosmetic changes/fixes like the shortcut name to edit settings...

The included Readme.txt file needs a rework too. Some examples:

• DSM Encryption plugin link to documentation does not work any more
• List of inlcuded files seems not to match the current release, some files do not exist any more, others not listed but included (e.g. no mentioning about ddengine.dll)

As said, this is cosmetical and should be handled with low priority (but you asked for feedback ).

Again, I seriously hope you're not regarding this as whining and moaning around. It's meant as constructive feedback and unless I find time and passion to provide code updates I try to report any real-world issue I discover. Thanks for all your efforts.

[Chrispy]

No problem, its great to have constructive criticism.

If Rudi asks me to add any functionality, i will.

The problem with the menu, or for that matter any text, is that it needs to be translated to all the diff. Languages

[SkyBeam]

The problem with the menu, or for that matter any text, is that it needs to be translated to all the diff. Languages

Are you referring to the "Edit Settings" shortcut? Here I would just prefix the menu entry with "UltraVNC" like the viewer. So searching for UltraVNC in start menu will show all matches:

• UltraVNC Viewer
• UltraVNC Edit Settings
• UltraVNC Server
• UltraVNC Launcher

[Rudi De Vos]

I realy appriciate the comment, this can only make it better.
Telling all works...isn't the way to improve things

We need to release 1.2.2.2 there are to many bugs in 1.2.2.1.

End users doesn't see what happen insite, they only use the ui.
A good ui with a bad program sell better then invers...cosmetics are important

After 1.2.xxx time to move to 1.3
A lot of little and big changes can be added

[AnotherUVNCuser]

After 1.2.xxx time to move to 1.3
A lot of little and big changes can be added

There's always room for improvement, but as long as you are the only person who makes the final changes/touches to the project, development will be slower and possibly less efficient (i could be wrong though, as i haven't looked at the project's current maintainers).

All that i hope for in the end is a better Filetransfer UI/manager with better navigation (i.e. being able to 'jump' to a specified location by typing it in the address bar) and better (more consistent working) file/folder sorting.

I also think of a thumbnail view but perhaps that's too much asked because you could also do this outside the FT window