Beta 1.0.9.2

[Rudi De Vos]

-changes

-uvnc close as last application, on reboot
-reboot in safe mode with uvnc access after reboot.
-Fix SoftwareSas registry from systray (ctrl-alt-del)
-cad with and without auc on Vista and win7
-update installer start server after installation (option)

safeboot
On XP -> boot.ini is changed , added /safemode:network
On Vista >= bcdedit is used to put the system in safemode
when uvnc start in safeboot, boot.ini /safeboot is removed
and bcdedit corrected for normal boot.

PS: On win7 X64, you need to disable the firewall before rebooting in safemode, else vnc get blocked until you logon... Firewall safemode settings seems to differ from the normal mode.... Took me hours to findout. X64 version is needed on X64, else safeboot doesn't work.


Tested:

win7 x64 service
-safeboot reboot OK
-ctrl-alt-del no uac OK
-ctrl-alt-del uac OK
Vista win32 service
-safeboot ok
-ctrl-alt-del no uac OK
-ctrl-atlt-del uac OK

Still need some feedback for safeboot ( XP, w2k)

Without uac, you seems not to be bound to the "program files", ctrl-alt-del also works if the service is started from another location. WIth uac, a secure folder is needed.

download:
http://www.uvnc.eu/download/UltraVNC_1. ... update.exe
http://www.uvnc.eu/download/UltraVNC_1.0.9.2_update.exe

http://www.uvnc.eu/download/UltraVNC_1. ... _Setup.exe
http://www.uvnc.eu/download/UltraVNC_1.0.9.2_Setup.exe

http://www.uvnc.eu/download/UltraVNC_1.0.9.2.bins.zip
http://www.uvnc.eu/download/UltraVNC_1. ... ns_x64.zip

[Rudi De Vos]

download files added and renamed to 1.0.9.2 Beta

[sfhub]

-update installer start server after installation (option)

How do I enable this option?

I tried the update installer and the 1.0.9.2 release fixed the previous overwrite error with securevncplugin.dsm

However after the update installer closes a server running as an application (vs service) it doesn't restart, so during a remote upgrade, there is no ability to finish the end of the install and reboot the remote machine, since the server was previously closed.

[Rudi De Vos]

It is one of the check boxes of the installer

[sfhub]

Thanks, totally missed it first time around.

[timo]

What is the correct procedure to test safeboot with XP?

I tried the following:
- update to 1.0.9.2 Beta, both viewer & server
- Restart Server
- Mouse on VNCServer icon, right-click and select "Reboot in safemode"

Nothing happened.
No change in Boot.ini on server.
Did I miss something?

Server is running XP 32 bit

[Rudi De Vos]

timo, was the server running as service ?

[timo]

Yes, it was running as a service.

[Rudi De Vos]

Seems i disabled it for <Vista... because i didn't tested it for XP
myself yet.

[Rudi De Vos]

All files updated, same download.

+safeboot <Vista activated
+Viewer added, with possible fix for crash on first run ( LAN)
+exe version info added ( required MS logo)
+signed uninstaller ( required MS logo)
+service as not interactive set ( required MS logo)

http://www.uvnc.eu/download/UltraVNC_1. ... update.exe
http://www.uvnc.eu/download/UltraVNC_1.0.9.2_update.exe

http://www.uvnc.eu/download/UltraVNC_1. ... _Setup.exe
http://www.uvnc.eu/download/UltraVNC_1.0.9.2_Setup.exe

http://www.uvnc.eu/download/UltraVNC_1.0.9.2.bins.zip
http://www.uvnc.eu/download/UltraVNC_1. ... ns_x64.zip

[timo]

Tested for XP.
Server reboots in safemode.
At first, the display in viewer after it reconnects to safemode is NOK.
See http://personal.inet.fi/koti/timom/screenxp.jpg.
What you see on the lower part of the image is the viewer screen when the connection is broken, that is when werver starts to reboot to safemode.
At the upper part of the image is the viewer login screen after the reboot to safemode.
The server has two displays, so login screen can be seen doubled on viewer.
Also, scaling is in use:
scale_den=100
scale_num=85
Scaling=1
ServerScale=1

When I pressed Ctrl+F11 (normal screen), display changed to normal and showed the correct login screen.
When I restarted the server to return to normal mode, viewer crashed.

Tested XP again without reconnection:
- screen is OK
- no viewer crash on restart

Tested also for W2K.
Same kind of display can be seen with W2K server after reconnection:
See http://personal.inet.fi/koti/timom/screenw2k.jpg.
Also Ctrl+F11 -> normal screen.
W2K server has only one display, but it also uses screen scaling.

It seems that if reconnection is used, change from two displays in normal operation -> single display in safemode and/or change in screen size is too much to handle to the viewer.
If reconnection is not is use during change to safemode, everything works.

[Prisma]

X64 version is needed on X64, else safeboot doesn't work.

Hello Rudi, please excuse me, I really don't wanna insist. But you know, I only want to help. With the following trick you should get it work:

Please have a look at the windows title. It's definitely a cmd32 window opened with double click within sysWOW64. But I tested it also with a command prompt opened trough a Win32 application. It's the same, it works. Or are there other additional problems I don't know?

[djsote]

Hi, i am spanish and my english is very bad.

I have a problem with ultravnc and 1.0.x

All of my computers are into a domain, and when i need to press control+alt+supr in win XP works fine, but in windows 7 professional 32 bits when i press control+alt+supr nothings occur.

Can i help me?

I try to install the 1.0.9.2 but any news.

Thanks & Regards.

[Rudi De Vos]

timo

It seems that reconnect can handle *different color depth.
What you is is 16bit colors displayed on a 32bit bitmap.
(The reconnect suspend the update thread and start using the new data when connected)

For now, reconnect in safeboot -> restart viewer.
This is to deep in the code and we risk to break a lot of other things.

"Reconnect need to be able to switch color depth on reconnect..."
put on the todo list.

prima

Have you tested the bcdedit executed from a w32 app works and don't corrupt the boot header.

[Prisma]

Have you tested the bcdedit executed from a w32 app works and don't corrupt the boot header.

I have to admit that I haven't tested it. But it is the genuine X64 bcedit.exe that is started, only through a link. Why should this corrupt something?

[Prisma]

I'd test it, but I'm too stupid to find the correct commandline parameters for savemode reboot. gimmie a tip, please rudi. what parameters do you use?

[Rudi De Vos]

set
bcdedit /set safeboot network
unset
bcdedit /deletevalue safeboot

[timo]

timo

It seems that reconnect can handle *different color depth.
What you is is 16bit colors displayed on a 32bit bitmap.
(The reconnect suspend the update thread and start using the new data when connected)

For now, reconnect in safeboot -> restart viewer.
This is to deep in the code and we risk to break a lot of other things.

"Reconnect need to be able to switch color depth on reconnect..."
put on the todo list.

I checked with W2K server what happens to the display.
- In normal mode, it is 1024x768, 16 bit colours. Display driver could manage 24 bit, but I run it in 16 bit mode to get the most of the mirror driver. 32 bit colour is not available
- In safe mode, it is 640x480 and 16 bit colours

So, no change in colour depth, but a change in screen size.

Which one actually is the cause of the problem?

I will check the same information with XP server later on.

Anyway, I agree what Rudi wrote: For now, reconnect in safeboot -> restart viewer. I can live with that, it is not something I would use on daily basis.

[timo]

And for XP Server
- In normal mode: Two screens, both 1280x1024, 32 bit colour
- In Safe Mode: Single screen, 1024x768, 16 bit colour

So in this case, change includes
- number of screens
- screen size, and
- colour depth

[Prisma]

Tested. Like expected no crash. I did:

Within cmd32:
1. mklink %windir%\SysWOW64\bcdedit.exe %windir%\System32\bcdedit.exe
2. bcdedit /set safeboot network
3. shutdown -r -t 0
4. Win7 starts in safemode
5. bcdedit /deletevalue safeboot
6. shutdown -r -t 0
7. Win7 starts normal

Please do a cross check, but I'd say, everythings working!!

[sfhub]

All files updated, same download.
...
+Viewer added, with possible fix for crash on first run ( LAN)
...

I can confirm this release fixed
vncviewer.exe crashes on first few connects, then it works
vncviewer.exe crashes on first few connects, then it works

The upgraded viewer works with 1.0.9.1 and 1.0.9.2 servers without crashing.

Also during a remote update:

==
Setup - UltraVNC dialog

Extracting files...
[progress bar 1/3]
==

Stops updating the progress 1/3 into the install.

Didn't realize at first, but the reason it stopped was because the dialog box that asks

==
uvnc_server already installed , Remove ? ( NO will skipped server installation)
[Yes][No]
==

was present, but either was hidden behind the Setup progress dialog or was not otherwise visible. I thought the remote server was shutdown until I realized I could still manipulate the desktop and then I clicked on "UltraVnc" in the taskbar and the hidden prompt showed up and I could continue.

This was a little confusing. I'm pretty sure previous update versions had that yes/no dialog come up in the foreground.


Also minor typo correction, Yes/No prompt above should be worded "NO will skip server installation" instead of "NO will skipped server installation"

Thanks.

[sfhub]

I just did another remote install and this time the prompt asking to remove the service comes up in the foreground. I don't know why it didn't the first 2 installs.

[Rudi De Vos]

prisma, found a btter way

wow64disablewow64fsredirection(off)
bcdedit
wow64disablewow64fsredirection(on)

No link needed

Tested and seems to work.

[Rudi De Vos]

sfhub

You need to select to install Server Slilent... not full.
[v] Start service

[sfhub]

Does anyone know why the cursor is a bit jumpy when Track cursor locally is enabled.

What I'm seeing doesn't seem to be related to queued mouse movements as it will often happen when the mouse pointer is just sitting there. It seems to happen more when I hover over (mouse over) objects.

The pointer momentarily jumps an inch or two then goes back to the current position.

I notice it a lot more when the server is a slow machine (as in P2) but I think it happens on my fast machines too, I just don't notice it because it happens much quicker.

I do have "Automatically move pointer to default button in dialog boxes" enabled for my windows mouse options in case that makes any difference.

It feels like there are two independent trackings of the mouse pointer and they get out of sync and some display routines use the first tracking info and the other occasionally uses the one out of sync.

If this is just expected behavior then no biggie, it isn't a deal breaker, but on the slower machines it gets a bit tiresome so I figure I'd mention it in case it was a bug.

[sfhub]

sfhub

You need to select to install Server Slilent... not full.
[v] Start service

Thanks, that would get rid of the prompts, but the (now not reproducable) problem I was seeing is the install time prompt to remove server was hidden and obviously the progress bar stopped waiting for user input which might never happen because the user didn't know he was being prompted. I don't know why it happened the first 2 installs but doesn't happen anymore. I chose full install in both cases.

[Rudi De Vos]

sfhub.

You need to differentate between install when running as service
and as application.

Running as service the silent is needed, else it ask to kill the service.
In 1.0.91 Running as application there was an error, that the dsm was buzy ( this doesn't exist in 1.0.92)

To fix stuff i need to be able to repeat it.

mouse:
The auto mouse has an impact.
Viewer send mouse position.
If mouse is moved manual on server site, server send mouse mpoition to viewer.
I guess that auto mouse moves by server are not detected -> it fall back to the origal viewer position -> jump effect.

[sfhub]

mouse:
The auto mouse has an impact.
Viewer send mouse position.
If mouse is moved manual on server site, server send mouse mpoition to viewer.
I guess that auto mouse moves by server are not detected -> it fall back to the origal viewer position -> jump effect.

So I turned off auto mouse to default dialog box and it is still jumpy.

What it feels like is when I have track mouse locally enabled, I move the pointer on the client, but after it reaches a new position, an out of order message comes in from the server that tells the client the mouse position should be where it was .2 seconds ago, so the client then takes the server position into account, displaying the server's late position info for a micro second, then overriding that with the locally tracked current position, hence jumping back and forth.

I don't know if that is what is actually going on, just what it feels like.

This is with slow server machine over a remote 100ms ping time connection.

[sfhub]

sfhub.

You need to differentate between install when running as service
and as application.

Running as service the silent is needed, else it ask to kill the service.
In 1.0.91 Running as application there was an error, that the dsm was buzy ( this doesn't exist in 1.0.92)

To fix stuff i need to be able to repeat it.

Ok, I figured out what was causing the issue. I am sorry I wasn't able to give better details earlier.

I probably wasn't communicating it that well.

This is all during update of VNC running as service.

The issue isn't that I get the prompt to remove/close the service. *If* that prompt is *visible*, I can just choose Yes to remove/close the service, the client window will close (since the server shutdown), then a second or two later, the windows service manager (I'm assuming is the one doing it) will restart the service automatically after detecting it is down. I can then just reconnect to the server and finish answering the subsequent install prompts.

The problem was that the prompt to remove/close the service was *not visible*, yet the installer was waiting for a response from me.

I have now figured out what was happening and it can happen during a local update of the service also.

To duplicate:
During update of VNC service locally, choose full install.
At "Select Additional Tasks", Select "Register UltraVNC Server..." and "Start or restart UltraVNC..."
At "Ready to Install", select [Install]
Now immediately start tapping your mouse continuously on the "Setup - UltraVNC" progress dialog, do this until the "Extracting files..." progress dialog stops moving. (I think it only requires one click on the progress dialog to induce this behavior, but I said continuous taps to make sure you see the problem the first time around)

You'll notice at the windows task bar below there are two UI items (related to vnc) listed, one labeled "Setup" with the VNC icon and one labelled "UltraVNC" with non-descript icon.

The latter is the dialog box asking you if you want to remove the service. However, it isn't visible, apparently due to previous mouse clicks on the progress dialog, prior to creation of the "remove service" prompt. All the user is seeing is the progress dialog, which has now stopped updating, so they don't realize they are even being asked a question (because the prompt itself is not visible) This is a little confusing because you cannot really continue the install until you answer the prompt, but you don't know the prompt is there.

The first 2 times I installed, I was probably moving the mouse pointer during the install and since I have tap on mouse pad detected as "click" it probably ended up clicking on the progress dialog at the right time to make the "close service" prompt come up not visible. Since I was doing the update remotely, it wasn't as obvious that I had clicked on the prompt.

Now, at this point, if you simply click on the task bar "UltraVNC" entry, the "remove service" prompt will become visible and you can answer the install and continue. After making the "remove service" prompt visible, you can no longer click on the "Progress" dialog and cause it to hide the "remove service" prompt. This is the behavior I would have expected from the start.

Not sure if anything can really be fixed. This might just be a windows UI (or 3rd party installer) bug or there might be different options which can be selected when the prompt is initialized to alleviate the confusing behavior. I'm just describing what I encountered, not saying anything can be done.

There is the concept of "Modal" dialog where a particular dialog box stops the workflow and should always be showing up in the foreground
http://en.wikipedia.org/wiki/Modal_window
For some reason the Modal dialog asking to "remove service" can be made to not be visible by errant (or purposeful) click of the "progress dialog" prior to "remove service" prompt being created.

BTW this happens for server updates on both Vista and XP.