Multi-ver bug? Server Property Page rejects input

Find help for Frequently Asked Questions here - please look here first before posting an already answered question.

Multi-ver bug? Server Property Page rejects input

Postby CP44 » 2013-10-28 14:04

I downloaded the 1.1.9.3 files, stopped my UltraVNC server instance, and dropped the newer EXEs, DLLs, and other supporting files into my UltraVNC folder. Then I restarted the service to check for changes, but the tray icon did not return. I stopped the service and ran winvnc.exe by double clicking it, and was greeted with the "UltraVNC Server Property Page" (Admin Properties leads here) -- it was pre-filled with my normal settings. OK and Cancel both made it close, but it would come right back... same for the X; Apply seemed to have no effect.
The only abnormal thing about my UltraVNC folder is that it not on C: drive, but I think I have ruled that out as a relevant factor.

By making various changes to the settings and reloading the ultravnc.ini file, I found that the settings were saved for each press of OK or Apply (should not be a permissions problem). I had originally used UVNC_1_1_9_xp-win7_X86.zip, but the same problem was found with winvnc.exe from UVNC_1_1_9_xp-win7_X64.zip , UVNC_1_1_9_w2k_X86.zip , and UVNC_1_1_9_win8_X86_X64.zip .
UAC elevation and XP SP3 compatibility modes had no effect.
Hoping this was just a recent for/while/if slip-up, I grabbed the zip files from the 1.1.8.9 release, and had the same problem with their winvnc.exe versions. Using Process Monitor, I tried to verify that password storage had not moved to a new, weird location causing VNC startup to fail to find passwords. I only found icon1.ico and icon2.ico to be missing; supplying files by those names had no effect.

The tray icon never formed when this dialog box was stuck repeating. The debug log (below) leads me to believe the settings were loaded and then immediately cleared, yet the values were still read from the INI and applied to the dialog box. It also mentioned saving to the registry, but I am guessing that is a legacy remark and marks the write to the ini file (RegSetInfoKey routinely happens for Installer and Services keys, but RegSetValue was not seen).
I have also tried changing most settings/checkboxes, multiple passwords, different PWs, blank PWs, clearing the INI file, starting with the ini file supplied in the zip files, making uvnc_settings.exe save its own INI file, sending freshly extracted copies to new folders by themselves on the original drive and the C: drive, running some EXEs under Sandboxie, and using some EXEs extracted from the full installers using Sandboxie. The symptoms remain for the 1.1.9.3 and 1.1.8.9 versions.

This computer is...
Microsoft Windows 7 (6.1) 64-bit Service Pack 1 (Build 7601)
DirectX Version 11.0
Aside from bits of discussion about what versions of Visual Studio people use to compile UltraVNC, I have not been around the VNC forum enough to know what other tidbits could be useful for debug purposes. (I did check the forum enough to know that "pops", "popping", and "keeps" are rejected by the forum search as not occurring and that the best match for this complaint comes from people who did not want VNC installed, therefore did not intend to fill out the dialog box -- except for the ChunkVNC results.) Please let me know if this has been seen before or if I can provide anything more.

The debug log showed the following on initialization...

Code: Select all
Mon Oct 28 09:08:28 2013
vncserver.cpp : authhosts set to ""
vncproperties.cpp : ***** DBG - Load User Preferences
vncproperties.cpp : clearing user settings
c:\users\rudi\desktop\ultravnc_installer_other\ultravnc\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : FromClear called
vsocket.cpp : VSocket() m_pDSMPlugin = NULL
vncserver.cpp : trying port number 5900
vsocket.cpp : VSocket() m_pDSMPlugin = NULL

and then loops like the following for every press of OK...
Code: Select all
Mon Oct 28 09:37:19 2013
vncproperties.cpp : saving current settings to registry
vncproperties.cpp : enddialog (OK)
vncproperties.cpp : dialog result = 1
c:\users\rudi\desktop\ultravnc_installer_vista\ultravnc_test2\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : ToText called
vncservice.cpp : @@@@@@@@@@@@@ GetCurrentUser - UserNAme found: User
vncserver.cpp : authhosts set to ""
--The system cannot find the file specified.
vncproperties.cpp : ***** DBG - Load User Preferences
vncproperties.cpp : clearing user settings
c:\users\rudi\desktop\ultravnc_installer_vista\ultravnc_test2\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : FromClear called
vncproperties.cpp : $$$$$$$$$$ ApplyUserPrefs - Plugin NOT enabled
vncmenu.cpp : vncmenu killed
winvnc.cpp : ################## Closing Imp Thread
winvnc.cpp : OpenInputdesktop OK
winvnc.cpp : SelectHDESK to Default (174) from 48
winvnc.cpp : Username User
vncmenu.cpp : vncmenu(server)
vncservice.cpp : @@@@@@@@@@@@@ GetCurrentUser - UserNAme found: User
vncservice.cpp : @@@@@@@@@@@@@ GetCurrentUser - UserNAme found: User
--The system cannot find the file specified.
vncserver.cpp : authhosts set to ""
--The system cannot find the file specified.
vncproperties.cpp : ***** DBG - Load User Preferences
vncproperties.cpp : clearing user settings
c:\users\rudi\desktop\ultravnc_installer_vista\ultravnc_test2\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : FromClear called
vncproperties.cpp : $$$$$$$$$$ ApplyUserPrefs - Plugin NOT enabled
c:\users\rudi\desktop\ultravnc_installer_vista\ultravnc_test2\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : ToText called
vncmenu.cpp : ########### Shell_TrayWnd found 0
vncproperties.cpp : INITDIALOG properties
vncservice.cpp : @@@@@@@@@@@@@ GetCurrentUser - UserNAme found: User
vncserver.cpp : authhosts set to ""
--The system cannot find the file specified.
vncproperties.cpp : ***** DBG - Load User Preferences
vncproperties.cpp : clearing user settings
c:\users\rudi\desktop\ultravnc_installer_vista\ultravnc_test2\ultravnc project root\ultravnc\winvnc\winvnc\vncpasswd.h : PASSWD : FromClear called
vncproperties.cpp : $$$$$$$$$$ ApplyUserPrefs - Plugin NOT enabled

Many thanks to anyone who reads through this, though it is long. Even better if you have a quick fix... I am trying to provide useful info instead of saying "it doesn't work, fix it for me" : D
For now, I have reverted the server EXE to 1.0.9.6 from pre-upgrade backup.
[Post Edited: BBCode enabled, log segments in Code tags instead of Size tags]
Last edited by CP44 on 2013-10-29 04:22, edited 1 time in total.
CP44
 
Posts: 5
Joined: 2013-10-28 13:18

Re: Multi-ver bug? Server Property Page rejects input

Postby Rudi De Vos » 2013-10-28 18:05

The password storage is in the ultravnc.ini file in the same folder as winvnc.exe.
If no password is set, you get
greeted with the "UltraVNC Server Property Page" (Admin Properties leads here) -- it was pre-filled with my normal settings. OK and Cancel both made it close, but it would come right back... same for the X; Apply seemed to have no effect.

this is intentional to prevent you to run winvnc with a empty password.

The password need to be set via the properties popup (gui)
for password "aaaaaaaa" 8xa

[UltraVNC]
passwd=502CC0385FCED91B95
don't set
passwd=aaaaaaaa -> this is not valid

The ini file in the installer is a dummy with a invalid password. The only purpose is to make the installer erase the ini on uninstall.

Normal the only thing you do on startup is to set a password via the properties popup you get.
As long as the password is not set, the popup return.
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5488
Joined: 2004-04-23 10:21

Re: Multi-ver bug? Server Property Page rejects input

Postby CP44 » 2013-10-28 18:48

The issue here is not the password as far as I can tell, unless the blank password detection is broken in my case. My passwords are valid and accepted by 1.0.9.6, and I have set many different passwords during troubleshooting, including "view", "test", and other random characters. As I said during the INI checks, I watched the values change between uses of OK and Apply... this included the saved password hashes.
CP44
 
Posts: 5
Joined: 2013-10-28 13:18

Re: Multi-ver bug? Server Property Page rejects input

Postby Rudi De Vos » 2013-10-28 21:02

If you have a working 1.0.9.6 the ini file is still valid in 1.1.9.x.
Try the following
1) copy winvnc.exe 1.1.9.x on the usb stick together with the ini file from 1.0.9.6 ( only this single exe is needed to run vnc for testing)
2) Run winvnc.exe from usb stick, try it also on a nother pc

I would test your ini file, but as you told me that it also happen with a new it would not bring a solution closer
As test, i made the ultravnc.ini read-only with a blank password. If you enter a password in the popup it is saved in memory and the popup loop
stops. You get a warning that the config could not be saved, but vnc is working until you restart it.

this is a nice problem...i realy wonder what it could be.
It can't be a general thing ultravnc 1.1.x is already more the 2 million times downloaded, with no
complains like this.
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5488
Joined: 2004-04-23 10:21

Re: Multi-ver bug? Server Property Page rejects input

Postby CP44 » 2013-10-29 12:24

I upgraded an XP computer to 1.1.9.3 via Terminal Services (RDP), tested winvnc.exe as a user, then started the service again, and connected to the Console session all without problems. I copied that folder onto this (Win7) computer as a "known good" condition, set up Process Monitor to monitor all activity from a non-admin user, set the folder permissions to allow all changes from "Authenticated Users" and began experimenting, running winvnc as the non-admin user. (Then it seems NoScript reloaded this page, so the notes I was typing were dropped.)

The main thing I noticed was this registry path
Code: Select all
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
Hostname

Setting Hostname to a string longer than my computer's real name (2 characters) seemed to allow all versions I then tested to work... 1193:32, 1193:64, 1096, 1189:32
Shrinking the Hostname value down to 1 or 2 characters seems to cause the Server Property Page loop again on fresh starts but not right away - until then, the winvnc.exe process can be restarted and appears to be OK. During testing, if I got stuck with the Server Property Page, I could extend the Hostname value and hit OK until the prompt disappeared. I can confirm that while the Server Property Page loop occurs, the INI's values are not changed (verified by checking some values and file hashes).

Another variable I noticed is the tray icon tooltip, which is probably unrelated. The IP address string seems to be detemined once... either as the 8 addresses this Windows uses, a random single address, or "IP address unavailable". End flags like vnchook and schook do change. This behavior seems unaffected by Application/Service/UAC Elevation state -- again, hopefully just a side note.

As I submit this message, I have just gotten around the Server Properties Page loop by extending the Hostname value by 8 characters (adding a fictitious domain suffix) and pressing OK until the loop ended. The IP address in the tooltip appears valid but is not for my computer (starting with 92.242.144) - it is registered to Barefruit Ltd. in GB/UK, while I am in USA.
Hopefully this provides something to work with; I will add anything else I can find that is relevant.
CP44
 
Posts: 5
Joined: 2013-10-28 13:18

Re: Multi-ver bug? Server Property Page rejects input

Postby Rudi De Vos » 2013-10-29 13:11

Wow, thanks for testing.

I wil check it this evening.
That a small hostname have influence on saving properties....i never would have found that one, even after months testing.

Greetings
Rudi
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5488
Joined: 2004-04-23 10:21

Re: Multi-ver bug? Server Property Page rejects input

Postby CP44 » 2013-10-29 14:02

Although the method that generates the IP tooltip is still beyond me, I think I now understand why VNC was querying the registry for a policy related to DNS override... the DNS suffix I assumed shouldn't exist does not exist at the root server level; but it does resolve when queried from my computer ... to an IP from the UK that does me no good. An attempted DNS resolution on the Hostname value explains the incorrect IP I am now labeled with.
In proper DNS environments, this behavior may help some people. I am still curious if the tooltip ever updates to try to display a valid IP if one or more become known (instead of the "not available" message).
CP44
 
Posts: 5
Joined: 2013-10-28 13:18

Re: Multi-ver bug? Server Property Page rejects input

Postby Rudi De Vos » 2013-10-29 18:47

Tooltip: one you ask the local name
Then you ask the ip addresses corresponding to this name. It use the OS name resolution.
IP address unavailable= lookup of name failed, the OS doesn't find an ip address that correspond with this name.

The update is every 5 sec, if the dhcp change the ip the tooltip is also changed ( and listener is restarted)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
Hostname

Making changes to this value require a reboot, else unknow ip address. ( the OS also need to modify his ip/name table)
Also because no internal lookup, the OS now try dns resolution, making the gui of the systray slow

Can't repeat the properties loop. Tried with 2 chars 1 char etc...
Rudi De Vos
Admin & Developer
Admin & Developer
 
Posts: 5488
Joined: 2004-04-23 10:21

Re: Multi-ver bug? Server Property Page rejects input

Postby CP44 » 2013-10-30 19:00

My experiment after work today (and a fresh restart) gave me a new impression. For some reason, on this computer, having the Hostname actually match the computer's name causes the loop. For a while, adding a . (period, dot, full stop) after the Hostname immediately fixed the issue. Doing that immediately gave me the tray icon from the service instance that was apparently trying to start without a dialog box (due to the -service_run argument). Realizing this might indicate an issue with the name resolution attempt, I tried to set a default DNS suffix of . for the computer using the Computer Name and somehow stopped that "fix" from working. My observation is now that if the Hostname matches the computer's name, I get the property page/Hostname loop. If the Hostname is different, winvnc.exe starts immediately, without issue, and lists all IPs. I do not know why my computer is being such a stubborn test case; but if there is a bug, I am now led to believe it has to do with the attempt to resolve the Hostname.
Many thanks for checking into this.
CP44
 
Posts: 5
Joined: 2013-10-28 13:18


Return to FAQ

Who is online

Users browsing this forum: No registered users and 2 guests