[solved] bug SBS 2003 R2 unaccessible after server is locked

[redge]

Upgraded from UVNC 1.0.5.6 to 1.0.6.4(installed as service) on a customers server. The server is reachable via uvnc, rdp and telnet. When connected to the server via uvnc and doing nothing till the server locks itself(Ctrl-Alt-Delete to login again) the connection drops, all clients connected via repeater disconnect also and then the server isn´t reachable anymore. Then rdp and telnet are failing to connect, too. No Connection possible till the server is restarted.

Any clues??

Moderated by redge at 2009-11-11 22:02:

tomha confirmed is solved with 1.0.8.0

[redge]

is a bug of locksetting=, not yet fixed

[tomha]

very bad thing
would be happy to get informed when the problem is solved
best regards

[GTA_doum]

Me too, would like to be advised, same problem here... UVNC server service not responding... Was working great on verion 1.0.5

Thanks.

[redge]

could you try with uvnc 1.0.6.5 ?
Update 1.0.6.5

[tomha]

Same behaviour under 1.0.6.5
First remote access via uvnc is ok. After the user is auto-logged off from the server the viewer screen freezes and then i get a socket write failed error. When trying to reconnect there is no access via uvnc or rdp till the server is restarted. Very dissapointing.

[redge]

tomha,
uvnc server runnning as application or service mode ?

[tomha]

Service mode

[GTA_doum]

Hi,

1.0.6.5 fixed the problem on my server. But the screen refresh does not always work, I often have to select Request Screen Refresh, or I go to send the Ctrl-Alt-Del, then enter the password and Enter, and the screen finally refreshes...

The refresh problem sometimes happens while logged in and just clicking in a two part window, the window then shows just parts of what it should...

[tomha]

I can not commit that this problem is fixed.

I tested again and again when the server is locked all connectivity is lost(not only uvnc, also rdp and telnet).

It is a bug in V 1.0.6.4 and 1.0.6.5 because this behaviour does not appear with version 1.0.5.6.

I tested with clean install after removing uvnc each time. vnc server was installed as service.

I could reproduce this problem on a second machine, so, once again, i do not agree that this bug is fixed.

[Rudi De Vos]

We don't have a small business server for testing...

Does it act as a 2003 web server or 2003 standard server.
If it happen on sbs it should also happen on the same architecture.

Are you sure it's 1065 ( check about box)
ultravnc.ini
check if
kickrdp=0
clearconsole=0

This are the 2 options that can cause winstation switches ans possible
lock the system.

[tomha]

I think there should be no difference between sbs 2003 R2 and Server 2003 R2.
In this especially case it is very hard to test, because i can only do this via remote connection an it is a productive server. If it fails i have to hard reset the server via VPro if remote functionality locks up. Now we went back to 1.0.5.6 an this server which works without problems.
I will set up a new test system next week and will report the results.

Regards
tomha

[Rudi De Vos]

Most of the new changes where for vista win7, a 2003 act as a xp server.

But a full network lockout is bizare..

[redge]

In this especially case it is very hard to test, because i can only do this via remote connection an it is a productive server.

You should never test a software on productive computer.
You should use virtual software, then a physical similar to productive computer for try the new software is fullfill your requirement, then install on productive computer especially if a server.

[redge]

could you tell us the step by step what you doing for help Rudi to find any bug.
vncviewer version and OS, uvnc server version and OS
network type and speed both side.
via internet or only local
you wrote you use via terminal service.

[tomha]

@redge:
of course testing on a productive system is at high risk, but this was the first system showing this behaviour after an upgrade from uvnc 1.0.5.6 to 1.0.6.4 or 1.0.6.5

SBS 2003 R2 x86 is installled on intel Q45 Mainboard. There are three clients(Q45 mobo, too) with Windows XP Pro x86(all SP´s and Patches applied). We connect through DSL with a Zyxel Zywall 2 Plus as HW Firewall. The other site(my office) is equipped with DSL, too.
Initially we installed UVNC 1.0.5.6 (as service, mirror driver installed and working)on the server and the clients. The server is accessed through port 1224, the repeater is listening on port 1225 repeating to the clients on port 1224. In this config there are no problems. The server is accessible via uvnc on port 1224, telnet on port 23 and rdp on port 3389, all the time.
Then we upgraded to UVNC 1.0.6.4 on all machines. Initially all access was ok. We did the upgrade on the physical machine as an update. After going back to my office the server was unreachable via uvnc, telnet and rdp. after a server restart it was accessible again. The standard behaviour of sbs 2003 is to lock the desktop after some minutes of inactivity and then it is unreachable till a restart.
I then uninstalled uvnc complete and reinstalled V 1.0.6.4 with the problem persisting. With V 1.0.6.5 the server gets unreachable after the desktop lock, too. Unfortunately i had no chance to examine the machine physically when its unreachable, so i had to restart it remotely. Then i uninstalled V 1.0.6.5 and reinstalled 1.0.5.6 which is working without problems again.

As i wrote yesterday, i will do further tests with an q45 board and sbs 2003 next week at my office and post the results.

[santonoff]

Server: Windows SBS 2003 (32 bit), SP2, 4GB RAM, AMD X2 (64 bit)
UltraVNC server version: 1.0.6.5
UltraVNC client version: 1.0.6.4

Strange behavior:

1) During login, the remote screen does not autoupdate. (Click Ctl-Alt-Del, screen does not change, refresh screen, see login dialog box, click on password, cursor doesn't appear, refresh screen, cursor appears, enter password, asterisks do not appear in password box, refresh screen, asterisks appear. Click Enter, after login, screen refresh is normal until....

2) Same problem as others with screen saver/lockup. I can use PSKILL (to kill winvnc on remote machine) and PSEXEC (to restart it on remote machine) and it is usable again. Until the next timeout. I'm trying to determine specifically if it's a CLIENT SIDE screen saver or a SERVER SIDE screen saver that causes the problem. I'll post again if I can isolate it to one side or the other.

Steve Antonoff
Marietta, GA

[santonoff]

Follow up to my last post:

1) UVNC 1.0.6.5 server locked when i was using the Client machine doing other things, so it was not a Client side screen saver that caused the problem. I went to the remote system (down the hall) and it's screen saver had NOT kicked in on screen, even though it should have.

2) After resetting UVNC, I turned the screen saver off on the remote machine. UVNC has not locked up since.

3) It seems that UVNC prevents the SBS 2003 server from going into the screen saver mode, and when that happens UVNC service locks up, too.

I have no idea if this is related to the "screen does not refresh or update before login" problem.

Steve

[tomha]

I tried to reproduce this strange behaviour with an VM with Server 2003 R2 installed.
The system enters the screensaver correctly and there was no lockdown.
So the problem seems hardware/driver related. At the moment i´m to busy to do further tests. On the customers server which is locking up, i unfortunately do not have physical access, so i have to keep UVNC 1.0.5.6 installed and cannot tell how the machine behaves physically when it is not remotely accessible. In my lab i have another Q45 mobo. So i will install Server 2003 for further tests on identical hardware, when i have got a little bit of spare time.

[santonoff]

Additional info about system:

System Board: ASUS M2NPV-VM
Video chip set: Integrated NViDIA GeForce 6 Graphics Processing Unit

Resolution in use: 1280 x 1024, 32 bit

[redge]

tomha

ultravnc server on w2k3 server sbs
you can checkbox on winvnc properties (not admin properties)
Poll full screen
Poll foreground window (that should solve the screen refresh issue on login screen for uvnc 1.0.6.5) it was what a was doing for fixing the issue but with welcome screen FUS (not classic logon)

if better, cool
if nothing change,
replace winvnc 1.0.7.7 (13 october 2009)
replace vncviewer 1.0.7.8 (17 october 2009)
http://www.uvnc.eu/download/ultravnc_10 ... ck_w32.zip

change log
topic #16279

[santonoff]

Normal settings are Poll Full Screen, Poll Foreground Window, Poll Window Under Cursor, System HookDLL and Video Hook Driver.

Check Video Hook Driver says 1.00.22

I'll try 1.0.7 to see if the problem goes away.

[santonoff]

1.0.7.7 does not exhibit the screen saver lockup problem. System has gone into screen saver mode twice, both times VNC kept running and was able to exit screen saver mode properly.

I haven't tried the login window yet.

[tomha]

Solved in 1.0.8.0

[dweia]

You sure it's fixed?

I have a very similar problem, which happens both with an installation of 1.0.6.5 and after de-installation and re-installation of ver 1.0.8.0

The computer the VNCserver is running on has installed "Windows Server 2003 Enterprise Edition Service Pack 2", and has an activated ScreenSaver with the option enabled to ask for the credentials again after the screensaver kicks in.

The effect is, that after a certain time (POSSIBLY the time necessary for the screensaver to come up, maybe less), the VNCserver freezes, and the entire computer is locked up. Unfortunately I don't have physical access to the computer, but according to the support-guys that DO have access, the computer wasn't even reacting to input on a locally connected keyboard, and they had to do a hardware-reset. What I could see was: no response on ports 22,80,443,3389,5900 all of which SHOULD be open normally.

One thing that might (but probably shouldn't) affect the problem is, that I was also logged in via RemoteDesktop at the time I tried out the configuration of UltraVNC - oh, and UltraVNC was run as a service, when it happend, and the "mirror-driver" was not installed.

Hope this helps to track the problem,
Gaja (Dweia)