“UltraVNC Server Property Page” instead of reverse connect

[CPC]

User Gets “UltraVNC Server Property Page” instead of reverse connection.
(Update 5/18/2020... (With no SecureVNCPlugin, I have the issue less, but still have it)

Users seeking help from me run a small exe script that includes winvnc.exe (32 bit) and establishes a reverse connection with my viewer. With hundreds of different computers and connections per month connecting without any issue. This one 32 bit exe is ran on all versions of windows XP through 10 32 and 64 bit.

Once in a great while I come across a user that gets the “UltraVNC Server Property Page” instead of it establishing reverse connection. The user can’t close this screen, if they click OK they get the a small screen warning…

“Warning: Running WinVNC without setting a password is a dangerous security risk! Until you set a password WinVNC will not accept incoming connections.

Clicking OK.. brings them back to the same “UltraVNC Server Property Page” where they cannot change anything or make it go away, other than go to task manager to close it… and still no remote connection to me.

No matter how many times they try, they get the same result. Yet, hundreds of others have no issue establishing the remote connection without the “UltraVNC Server Property Page” ever coming up.

If the same user with the problem PC runs my older scripted exe which includes.. winvnc.exe version 1.2.1.7 they connect without an issue. If they use 1.2.2.4 or newer including 1.2.3.0 dpitest fix just released Jan 2020… they get the “UltraVNC Server Property Page” instead of the remote connection to me.

I am trying to figure out how to overcome this issue that has come up between 1.2.17 and 1.2.2.4 and continues with current version.. I did also change my scripted exe slightly between 1.2.1.7 and 1.2.2.4 to handle the code injection and other requirements of the newer versions. This newer script is the same one that is being ran hundreds of times per month by others without this issue.

Again, this same single 32 bit exe is successfully ran to make hundreds of connections per month from a wide array of very old and new Windows PCs without this issue. Just every once in a while I come across a machine that gets this “UltraVNC Server Property Page” instead.

I currently have a user's PC that I have access to via another remote option and I am testing trying to resolve.
Any suggestions or others with this same issue?

Here are some of the specs that may or may not help.
The Problem winvnc server that can’t make the connection has the following specs. Dell Win 10 64 bit home, i7-10510U cpu, 16GB ram, it shows the intel UHD graphics and Nvidia GeForce MX250 in the device manager. The user is and admin running the program as admin, english language and us keyboard…like my other successful users. The computer is virus and malware free.

The users run the program and winvnc runs from extracted temp that includes all the same identical files as everyone else. This includes, winvnc.exe, ultravnc.ini, SecureVNCPlugin.dsm, Server_SecureVNC.pkey, 8KB bmp logo, vnchooks.dll. Nothing is different from the hundreds of others who connect successfully. I have also tried it with ddengine.dll getting the same result.

Here is the Ultravnc.ini (The same as all the others without this issue)
[admin]
FileTransferEnabled=1
FTUserImpersonation=1
BlankMonitorEnabled=0
BlankInputsOnly=0
DefaultScale=1
UseDSMPlugin=1
DSMPlugin=SecureVNCPlugin.dsm
DSMPluginConfig=SecureVNC;**removed for post
primary=1
secondary=0
SocketConnect=0
HTTPConnect=0
AutoPortSelect=1
PortNumber=5500
HTTPPortNumber=5800
InputsEnabled=1
LocalInputsDisabled=0
IdleTimeout=0
EnableJapInput=0
EnableWin8Helper=0
QuerySetting=2
QueryTimeout=10
QueryDisableTime=0
QueryAccept=0
LockSetting=0
RemoveWallpaper=1
RemoveEffects=1
RemoveFontSmoothing=0
RemoveAero=1
DebugMode=0
Avilog=0
path=
DebugLevel=0
AllowLoopback=1
LoopbackOnly=0
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferTimeout=30
KeepAliveInterval=5
IdleInputTimeout=0
DisableTrayIcon=1
rdpmode=0
Secure=1 ***Update*** Feb/22/2020 This may be the issue per Rudi try Secure=0
MSLogonRequired=0
NewMSLogon=0
ConnectPriority=0
AllowInjection=1
;service_commandline=

[Permissions]

[UltraVNC]
passwd=2F**yes, not displayed for this post
passwd2=0** yes, not displayed for this post

[poll]
TurboMode=0
PollUnderCursor=0
PollForeground=1
PollFullScreen=1
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu=40
EnableDriver=1
EnableHook=1
EnableVirtual=0
autocapt=1

Please… Let me know if you can think of something to try.
Maybe turn on some sort of higher log function to test ..?

Again.. I have only come across this on a few machines ..out of hundreds. I have access for a while to one with the issue and so it’s a good time to try and resolve while I can. The error message implies a password issue..but its the same ini and password/key situation for all the hundreds of successful connections.

Thanks in advance for your thoughts.
CPC

[Rudi De Vos]

Cause

Code: Select all

myIniFile.ReadPassword(passwd,MAXPWLEN);
vncPasswd::ToText plain(passwd, m_pref_Secure);
if (strlen(plain) == 0)
    ShowAdmin(TRUE, TRUE);

If the decryption of the passwd fail or passwd is empty, the properties is shown to set a password

[UltraVNC]
passwd=2F**removed for post

On the failed pc, using the property page popup set a password.
If you set the same password this should generate the same encryption string in ultravnc.ini
Save this ultravnc.ini and now try again to see if it's proper decrypted.
In other words: Is the encryption of the same passwd in the ini file the same on this pc then on all other

We had some issue with license key in another software, failing on 2 systems from the 5000.
Cause was the Beta: unicode settings
control panel, Region->administration tab -> change system locale
You never know if the systems has some different regional encoding settings that cause the decryptor to fail.

TEST---TEST--BEFORE USING
As you are using an outgoing connection and block incoming and Set the encryption pass phrase
Then you can skip the vnc passwd empty check
AuthRequired=0
When i'm correct this wasn't used when you set a bigger pass phase. The decryrption is done in another code part. Setting AuthRequired=0 should still ask for the pass phase...
PLEASE test if the AuthRequired=0 doen't set the pass phase to ""

[CPC]

Hello Rudi

Regarding: "In other words: Is the encryption of the same passwd in the ini file the same on this pc then on all other"?

Yes... With every user, everything including the password is identical. They have no interaction with any setting.. all they do is run my single click exe to make a reverse connect ( My version of a single click solution) The password and encryption key is already in the self extracting exe.. The self extracting exe puts the following identical files in the users temp folder... SecureVNCPlugin.dsm, Server_SecureVNC.pkey, ultravnc.ini, VNCHooks.dll, winvnc.exe
**The ultravnc.ini file already contains the identical password and encryption string in ultravnc.ini for everyone. The user does not interact with the passwords or ini file in any way.

Regarding: "On the failed pc, using the property page popup set a password." The users with the problem cannot seem to change anything including the password. Many of the users are senior citizens and extremely "PC challenged" and this is why they use me and absolutely need my single click solution to receive help. (I clean up malware and viruses and provide assistance to seniors) It can take an hour just to get some of these users to click a "next" button even when its the only thing on the screen. Asking them to actually type something.... eeeks..... life is too short.

I have changed the winvnc.exe ultravnc.ini that is bundled in the self extracting exe to include your suggestion of AuthRequired=0 as shown below under ConnectPriority. I hope this is what you meant.
rdpmode=0
Secure=1
MSLogonRequired=0
NewMSLogon=0
ConnectPriority=0
AuthRequired=0
AllowInjection=1
;service_commandline=

The ini file..(full one already posted) is only used for this one purpose of a single click reverse connection. Of course I am open to any suggestions that optimize this for universal stability and simplicity.

I have recompiled the single click exe with the addition of AuthRequired=0 in the ini and will test it today (hopefully) on the PC known to have this issue. I will update this thread with the results.
I will also double check the region/locale settings.

Thank you very much
CPC

[CPC]

*** A quick update to this ...and more testing today ***

I don't know the cause of the issue yet and why a small percentage of computers have this problem when they try to run the reverse connection.

I did check the region / locale settings on the problem computer used for testing... It is set the same as the other computers without this issue and the computer that created the passwords and encryption keys as English United States

However, I noticed in Settings > Update & Security > Device encryption I see that this problem machine has encryption turned "ON". <-- ***Update: this is not the issue... We turned off drive encryption, restarted the PC and it made no difference with the problem PC.

Now... Separately and without making any change to the problem PC used in the test.
TESTED with SUCCESS: I have changed the winvnc.exe ultravnc.ini that is bundled in the self extracting exe to include Rudi's suggestion of AuthRequired=0
On this test problem machine .... using AuthRequired=0 in the ini ... has eliminated the "UltraVNC Server Property Page from coming up and it completes the reverse connection successfully.

So, for my application and use, this is a workaround that I may deploy in my next release after further testing.... Thank you.

For others and for helping to make winvnc.exe more universally stable/robust... Pinpointing the cause may be of interest and benefit for future versions.

Rudi... Thank you again for all your hard work and contributions.

Let me know if you want me to test anything further in helping to pinpoint the cause

CPC

Update 1/2/2020 later the same day...
***Update: We turned off drive encryption, restarted the PC and it made no difference with the problem PC.
*** AuthRequired=0 in the ultravnc.ini for winvnc.exe is a functional workaround for my particular scenario to eliminate this error. (*Update: upon the initial reverse connection)
It would still be interesting to pinpoint the cause of this.

[CPC]

A continued issue and update after a month of real world testing.
By adding “AuthRequired=0” to the ultravnc.ini for winvnc.exe per Rudi’s suggestion. The initial reverse connection issue with the “UltraVNC Server Property Page” and not connecting has gone away. I make this initial reverse connection with excellent reliability. However, I have come across two more examples where I come across this issue on a small percentage of computers almost daily.

Example #1… Occasionally while remote controlling via a reverse connection, I will tell the winvnc server to restart (for an update or for other multiple reasons). As the computer begins its restart the “UltraVNC Server Property Page” comes up just like mentioned above and restart or shutdown hangs. The user can’t close the property page without some sort of interaction such as a force shutdown or closing winvnc via taskmanager. As a check/test, upon restarting the computer the ultravnc.ini is still there with the “AuthRequired=0” in it… so I don’t know why this is happening. Again this is on a small percentage of computers. I can't seem to repeat this issue in-house on my test computers. Most computers I can restart without any issues at all.

Example #2… Occasionally while updating drivers on a winvnc server via the reverse remote connection. The winvnc server will disconnect and reconnect to the viewer several times… as it should. For example it may have just done an ethernet driver update or graphics driver update… and it disconnects and reconnects to the viewer as it should a few seconds later. However, occasionally with a small number of computers, the “UltraVNC Server Property Page” comes up on the winvnc server end… the user at the winvnc server needs to force winvnc to close via taskmanager as initially described above. Example #2b Furthermore…. On the viewer end, there is sometimes an even worse issue... With the “UltraVNC Server Property Page” showing on the winvnc server, at the viewer end, connections rapidly and repeatedly keep coming into the viewer with a message about the server not being configured with a password and a connection error. This happens fast and repeatedly until the viewer locks up with 100% CPU usage. Using taskmanager to stop VNCviewer closes the problem. If the VNCviewer is opened again the fast and repeating connection attempts start happening again….until it locks up again. If there is not anyone available at the winvnc server end to force close winvnc, then the viewer computer is unusable until someone can get to the winvnc server to force it off.… This prevents the viewer PC from being used with other computers as it’s almost like being attacked by the one bad winvnc with the issue. This attack from the one bad winvnc has put me out of work … As a temp work around in order to get back to work on other computers, I create a firewall rule to block the ipaddress of the one bad winvnc server… Sort of like blocking a denial of service attack from an ipaddress. Then once someone can get to the server and the winvnc server stops attacking the viewer, I can then remove the firewall rule. ...and again this is on a small percentage of computers. I can't seem to repeat this issue in-house on my test computers. With most of the computers I work on, I can do these updates and restarts without this issue.

Currently using winvnc.exe 1.2.3.0 with the dpi fix posted by Rudi 1/9/2020 (I have not tested winvnc 1.2.4.0 widely in the real world but believe it to be the same)

Although I come across this issue in the real world, I haven’t been able to repeat it in-house on my test computers. The locale/region on all of the computers seems to be the same (USA). The ultravnc.ini is still there on the problem PC’s with the “AuthRequired=0”. I don’t know why this is happening on a small number of computers and I continue to seek a pattern and way resolve this. Again.. the initial reverse connection is reliable using the “AuthRequired=0” in the ini. The 2 examples above are problematic and taking up a lot of time.

Anyone with thoughts on a solution?
Thank you in advance
CPC

[DaichiTech]

I am having the same problem with auto-reconnect on a reverse connection

Multiple computers, but not all computers.
admin rights on windows 10
winvnc (1.2.4.0 32 bit) running as a service
winvnc.exe -autoreconnect -connect all to the same viewer ipaddress
No incoming connections, only reverse connections.
using “AuthRequired=0” in the ultravnc.ini and all with the same password and pre-shared key with SecureVNCPlugin.dsm

The initial reverse connection works very well. However, auto reconnects sometimes are unreliable with the "UltraVNC Property Page" showing on the server.
I have also experienced the same issue on the viewer side with rapid repeated connections and then locking up while the winvnc server is showing this property page and wanting a password.

If I restart the winvnc service and start the reverse connection again, it seems OK, but this is just a temporary workaround, not a fix.

[Rudi De Vos]

Just wondering if this was also in 1.2.3.0.

In 1.2.4.0 a change was added to coöp with dpi changes, this reconnect the viewer when the dpi change.

Then the trigger could be having a high dpi and the reconnect somehow fail as this is initiated by winvnc and not the service. Only in reverse mode ?

Need to make some time to test...

Does a dpi change in reverse mode trigger it ?

[CPC]

Hi Rudi

For me - I noticed it with winvnc 1.2.2.4 for initial reverse connection on some computers. When I added “AuthRequired=0” to the ultravnc.ini the initial reverse connection became reliable.

Shortly after adding “AuthRequired=0” I upgraded to 1.2.3.0 with the dpi fix. I then noticed the "UltraVNC Server page" error upon the -autoreconnect of a reverse connection on some computers. Note: Even on the computers that have this -autoreconnect issue, the problem does not happen all the time, only some of the time.

I do not have enough accurate info to give you regarding the period after adding “AuthRequired=0” with 1.2.2.4 to when I upgraded to 1.2.3.0 with dpi fix.

*Update... RE: "Does a dpi change in reverse mode trigger it ?" I am able to change dpi on most computers in reverse mode without triggering this error. Testing just now, a dpi change did not trigger it... but I can't be 100% certain that it doesn't trigger it some of the time

**Update 2... The problem tends to happen more on slower computers and/or slow computers with high disk usage. This may be coincidental as the reason I am asked to work on the computers in the first pace is because they are slow / ill.

Thanks for looking at this
CPC

Rudi: I will PM you a link to a zip file that contains my ini and a bat I am using for testing.

[DaichiTech]

Updated directly from 1.2.1.7 to 1.2.4.0. This issue started after update.
Running reverse connections only using self extracting zip. Same file on all computers.

This error seems to come up from various -autoreconnect needs. Yesterday, while uninstalling various programs from several computers, the server property page error came up and I lost control on several but not all computers. The programs being uninstalled were unrelated to video drivers, resolution or dpi.

It has always been normal for the connection to drop and come back while doing certain upgrades, installs and uninstalls and -autoreconnect has normally brought the connection back within a few seconds. With this version the -autoreconnect has been unreliable.

This error behaves as if the settings from ultravnc.ini are being ignored at times when the reconnect is needed? Not checking or not waiting long enough? Not seeing the “AuthRequired=0” on reconnect??

Other than this 1.2.4.0 is working well.

Thank You

[CPC]

The additional info in this thread has me back to wondering why we need the AuthRequired=0 as a workaround? We should not need it since we have a password in the utlravnc.ini and we are using SecureDSMplugin with the .pkey ??? Although AuthRequired=0 helps with the initial reverse connection, it seems to be used to overcome another issue with the password.

It's also odd how inconsistent it is. On some computers with autoreconnect not workng.... then after restarting the very same computer, autoreconnect sometimes starts to work without issues.

***Edit/Update .. Try Secure=0 per a suggestion from Rudi
"Secure=1 When you use a secure password, some system depended numbers cpu/mac/disk are used to encrypt the password. If you use the ini on another system, the passwd is invalid."

**I will test ultravnc.ini with...

[admin]
SocketConnect=0 (no incoming winvnc connections allowed, reverse connections only)
Secure=0
AuthRequired=0

Thanks again for your help and thoughts
CPC

[CPC]

An update and more info to this ongoing "UltraVNC Server Property Page" issue
Updated 5/18/2020 With no SecureVNCPlugin, I have the issue less often but still have it

Using in the ultravnc.ini
[admin]
SocketConnect=0
Secure=0
AuthRequired=0
[UltraVNC]
passwd=2F981DC548E09EC321
passwd2=00000000DE6BEB0617
as well as having
UseDSMPlugin=1
DSMPlugin=SecureVNCPlugin.dsm
and DSMPluginConfig=SecureVNC;0;0x00104001;U2VjdXJlVk5DZHNxxx

As well as with SecureVNCPlugin.dsm and a shared SecureVNC.pkey on the computers doing the reverse connections.

Most reverse sessions work perfectly fine...a loss of internet access or accidentally closing auto-reconnects perfectly... no issues... hundreds of sessions per month.

However... here is were I noticed a much higher probability of the "UltraVNC Server Property Page" issue.

Example #1 As I am working on someone's PC via remote and i go into device manager and update the video driver... Often times I lose the connection it doesn't auto-reconnect, call the person at the server end... and find out they have the "UltraVNC Server Property Page" on the screen and cant easily get out of it...without going to taskmanager or rebooting the computer.

Example#2... As I am working on someone's computer. If I go into windows updates and check for updates, and apply them. If the windows updates offers as "restart now" option on the screen and I click on it, I lose connection (perfect I should) ... However, at the server end the user ends up with the "UltraVNC Server Property Page" and cant get out of it easily and the computer isn't restarting. However, IF I don't click the "restart now" option given by windows update and instead go to the start menu and choose...power... restart... the computer restarts as it should without the "UltraVNC Server Property Page" issue coming up. So there is a difference on how its end the reverse connection that is throwing this error in this example?
I have tested this issue on dozens of sessions and many different windows computers to confirm.

As a test that I have been running for several weeks.. (Completely eliminating SecureVNCPlugin seems to have reduced the issue. However, it still happens.. so SecureVNC plugin is not the cause)

(The above test were done using winvnc.exe version 1.2.4.0 from 2/6/2020)

Thanks in advance for any thoughts on this.
CPC

*Moderator... feel free to move this thread elsewhere if more appropriate since its not only 1.2.3.0 or 1.2.4.0

*updated 5/18/2020 (Completely eliminating SecureVNCPlugin seems to have reduced the issue. However, it still happens.. So SecureVNC plugin is not the cause) It seems more like vnc server ignores the ini file entries at times... maybe during some disconnects and/or re-conencts?)

[Rudi De Vos]

I'm getting the idea that the problem is caused by vnc service trying to start vnc after being stopped
by the shutdown command.

vnc app stops, but service restart vnc before pc is down.
The timeout used to be a lot longer but was changed for the connect to RDP sessions as it took to long.

Possible update stop first all apps and then the service while reboot just send it to all at once.

Let see if i find some info on service stop and update windows on the net...

[stefanorossetti]

I too have encountered very similar problems.
I also add this:
when winvnc is connected to my repeater in "application mode" or "service mode" if where I run winvnc I change the gateway to move to another provider for example the connection justly drops but then never returns
(autoreconnect doesn't work ...)
This also happens with the latest ver 1.2.5.1

[Rudi De Vos]

stefanorossetti, so you also get the property page ?

[Rudi De Vos]

test version

Changes:
Service:
handle preshutdown message to stop restarting winvnc
winvnc property popup:
pressing cancel close winvc when no password is set ( to avoid the ever returning popup)


exe online
https://uvnc.eu/download/1250/shutdown_test.zip

[stefanorossetti]

I did a test. in service mode if I change the gateway it now correctly returns to the repeater.
I also tried again with the old version and the problem occurred immediately.

So it seems to me that the changes work.
as soon as I can I will do other tests.

[CPC]

Rudi... update 5/18/2020 as noted/edited above.. version 1.2.4.0
Completely eliminating SecureVNCPlugin seems to have reduced the issue. However, it still happens.. so SecureVNC plugin is not the cause. Had a rough time with a client today with no SecureVNC plugin at all. It was almost impossible to get him out of the server properties page even after a restart

It seems more like vnc server ignores the ini file entries at times... maybe during some disconnects and/or re-conencts... or really slow PCs???
***(The above test were done using winvnc.exe version 1.2.4.0 from 2/6/2020)***

Next... I will test your beta 5/17/20 version 1250 <-- thank you.
It may be a while before I get it into the real world and get enough hours in action to give you decent feedback.

CPC

[CPC]

Hello Rudi

Is this shutdown test change in code below also in the 1.3.0 test builds 05-23-2020 this week?

Post by Rudi De Vos » 05-17-2020 10:39
test version : handle preshutdown message to stop restarting winvnc
winvnc property popup: pressing cancel close winvc when no password is set ( to avoid the ever returning popup)
exe online: https://uvnc.eu/download/1250/shutdown_test.zip

If yes, I will move straight to testing 1.3.0 for this "UltraVNC Server Property Page" issue and skip testing 1250/shutdown_test.zip

Thanks
CPC

[Rudi De Vos]

yes,

First all other were added to the master tree before 1.3.0 was merged.