Black Screen when uses UVNC after a microsoft terminal serv.

[doraimom]

Hi.
I've been using UVNC for a long time, but one problem I couln't solve is to log in after using the Windows XP microsoft terminal service.
Microsoft terminal service is the software that allows any winXP to remote connect another winXP using a VNC connection.

I noticed that the remote machine, when is logged in using microsoft terminal service gets a BLACK SCREEN (in the remote machine), and the remote machine just comes back if you press a key or move the mouse. If you don't do any of these the machine will stay with the black screen.

The problem is:
If you try to use Ultra VNC after someone has connected the remote machine using Microsoft Terminal Service, the only thing you'll see is a black screen. I have tried everything Ultra VNC offers like: send a ctrl+alt+del to the remote machine, send a wake up, refresh, etc etc.. None of these solved the problem.

So, my last try has to be here in the source... UVNC's Forum.

Does anyone know if there is any thing I can do to solve this problem??

Thanks..

[bevtech]

Do your have UVNC installed as a windows service and set to automatic??

[doraimom]

As a service or just running the program, the same thing will happen. I have tried both of them. My PC right know is just running the program. I'm out of home. But in mom's house UVNC is always as a service.
I just didn't understand what you ment by set to automatic. If you mean that the service should be running all the time, everytime windows starts up, then that's what is going on in my mom's pc (it runs as a service).

I believe the matter here is if UVNC has any means to take windows XP back from the black screen or not, since it'll always appear in any winXP accessed by the remote desktop.

[bevtech]

Well UVNC uses console 0 and RDP will use console 1, 2 etc. I was just making sure that you had uvnc installed as a service and that seems to be the case here. I do know the following will not work.

Password Protected Screen Savors will not work with UVNC
FAST USER switching is not supported in UVNC

So if you have either one of the above active you can have problems.

It is also best to wait 5 min if you just had RDP open before connecting to the same server. I have heard other users running into issue when trying to use both at the same time or one right after the other. I have tested this with windows 2003 SBS and I didnt have that problem I could actually run both at the same time but other users have not had the same success

[doraimom]

Hi. Thanks for the reply.

All my PCs run with only one user. Even Admin account is disabled.

The screen saver is not locking the screen with password as well, but as far as I can remember this matter never affected any of my connections.

So, I still need some suggestion (if there is any way to solve this - I kind of thing there isn't) to overcome the black screen.

As far as I can tell ANYONE that has a WIN XP running can follow the steps I mentioned above and get the same results to see exactly what I'm talking about. The same thing happened in ALL computers I've tested so far, so it isn't a local problem. And I'm not new neither to UVNC nor to computers.

Thanks for the reply again. Hope we can find a solution.

[bevtech]

What type of VNC authenication are you using classical or mslogon??

should not really matter I am just trying to help brain storm..

Well I can run both UVNC and RDP at the same time on my windows 2003 server without any problem..

So I am kinda at a loss why it is giving you grief.


What version are you running of UVNC??? any special patches etc..??

[doraimom]

What type of VNC authenication are you using classical or mslogon??

Classical.

should not really matter I am just trying to help brain storm

??? Not sure if it were a joke or if you are just messing with me...

Well I can run both UVNC and RDP at the same time on my windows 2003 server without any problem.. So I am kinda at a loss why it is giving you grief.

I've never used win2003. So, for us to stay in the right problem here you need to follow the steps. It's about windows XP terminal service. That's just it.

I think that what you need, to understand what I'm talking about, is to put two winXP side by side in a local network and follow the steps.

Turn on the remote access in one computer (right click on my computer icon -> properties -> remote -> alow alow). In the other computer/notebook go START -> RUN -> Then type: " mstsc ". In this window put the IP from the first machine and connect to it. You'll see, at the same instant, the monitor from the other PC gets a black screen (remember, both PCs side by side). THAT'S IT! You'll see the so talked black screen. Even after you disconnect remotely, the black screen will remain 'till you move the mouse or use the keyboard (locally). I NEED YOU TO GET TO THIS POINT.

What version are you running of UVNC??? any special patches etc..??

Latest Version 1.0.2, normal one, without any patches.
NOW that you have followed the steps above and got to the black screen, just open UVNC VIEWER, put the first pc's ip again, press enter and here we go! You'll get the black screen all over UVNC window. You can use file transfer, and I think everything else also works, except the fact that you cannot see anything. I have also tried to make a http connection, but you'll get an error message after a few secounds of connection (after typing the password - Error: Framebuffer update rectangle too large: 0x0 at 61440,61448). I'm just giving you more information, but forget about http connection's problems. Let's start with the normal problem using UVNC viewer not http.

IF you just follow the steps I'm gentlely asking you to follow, you'll see what I'm talking about without any doubts and then it'll be easier for you to help me.

Thanks again.

[rmoller]

Services (like VNC) can interact only with session 0.
Normally console is attached to session 0, but during or after an MSTSC session, session 0 might not be attached to session 0 and is therefore not available to VNC.

See Black screen for Tivoli Remote Control for a script to remedy this situation.

Please try to connect to your XP using RDP and run QWINSTA.EXE from an MSDOS window. If "console" and "session 0" is NOT on the same line, then VNC cannot serve you the console. On my XP system, console is attached to session number 2 during RDP connection and unavailable to VNC.

Try to run QWINSTA.EXE after closing the RDP connection. On my system console will then again be attached to session 0 and VNC works again.

AFAIK this is a security restriction imposed by the Windows OS, and the restrictions are getting worse in Windows Vista.

[doraimom]

Please try to connect to your XP using RDP and run QWINSTA.EXE from an MSDOS window. If "console" and "session 0" is NOT on the same line, then VNC cannot serve you the console. On my XP system, console is attached to session number 2 during RDP connection and unavailable to VNC.

I did just as you said. I think my QWINSTA.EXE is a little different from what you've mentioned (you'll see it reading my answer). My local PC is running console with ID 0, and my remote PC is running console with ID 2 while I was connected with MSTSC, as you said It would be.

Try to run QWINSTA.EXE after closing the RDP connection. On my system console will then again be attached to session 0 and VNC works again.

I think you say your console is attached to ID 0 after closing RDP because you use your keyboard and mouse locally removing the black screen.

I did the test here. Since UVNC Viewer shows me nothing, the only way I know to check remotely what you've asked without removing the black screen (what would happen using it locally) was using TELNET. I did the test using MSTSC and after closing it too. In both tests the console was with ID 2.

See Black screen for Tivoli Remote Control for a script to remedy this situation.

So, from all you've said, if I my console was with an ID different from zero, then this would be the only thing you know that could remedy the problem right? I was going to try it (whatever it is), but the page is not working. It keeps loading forever. Do you have a mirror or something like this? Is it easy to use/run???

The LINK was pointing to:
http://www-1.ibm.com/support/docview.ws ... t661tivoli

Thanks.

[doraimom]

I'm thinking here rmoller. Something you said is looking strange to me.
You've said that VNC cannot connect if the console's ID is different from zero. Since my console stays with ID 2 after MSTSC is closed that could answer why I'm having problems.

But, I've tried to run MSTSC and UVNC Viewer all together. Since, console was with ID 2, Viewer was supposed to keep showing me the black screen, but for my surprise that's not what happened here. I could see everything.

So, here is the question: Is really the cause of my problem the console be with ID different than zero? Even if it's a special case, VNC worked while console was with ID 2.

[rmoller]

Sorry for the late reply;

my main RemoteDesktop experience comes from Windows 2003 Server; I have recently tested the XP variant, which behaves a little differently. With 2003, if you connect with RDP client: MSTSC /CONSOLE, session 0 will always be disconnected and all sessions on server must be reset or server rebooted for Winvnc to be accessible. This problem does not arise if youe use MSTSC without parameter /CONSOLE.

I use Winvnc as service on XP, and only now did I try different scenarios alternating between RDP and VNC:

- If I have an active RDP connection and start a VNC connection simultaneously, the VNC connection works and locks the MSTSC screen.

- If I have an active VNC connection and start a RDP connection simultaneously, the VNC connection will be disconnected.

- If I logoff from an active RDP connection (or call reset session 0) and then (prematurely?) attempt a VNC connection, then there is no response (similar to your problem, I think).

- If I disconnect an active RDP connection and then attempt a VNC connection, then the VNC connection proceeds fine.

My intuition and the IBM link pasted below tells me that a logoff should be better than a disconnect, but my experience tells my the opposite for XP.

So, I recommend you to try, if you haven't already, to disconnect your RDP session instead of logging off, or to initiate an RDP connection and then, while the RDP connection is open, initiate your VNC connection.

Our setup may be very different, f.ex. I use these reg values:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"fResetBroken"=dword:00000000
"fReconnectSame"=dword:00000000

and there are lots of others reg values that may differ.

good luck

Rasmus Møller

IBM text from link:

After having used a MS RD session with console option the
following batch program restores the initial state (previous to
the RD session) that is required to start a RC session.
The initial state is restored, using only Microsoft commands
(like query.exe, logoff.exe and reset.exe), by logging off the
user (if any) remotely connected to the console, thus closing
all user applications. Anyway, if you use the batch program
together with RC scripts and grace period option you can allow
the user remotely connected to the console via RD to accept or
deny the RC session and then his log off (further details are
below).

Following is our suggested batch for Windows 2003 and XP
platform:
----------------------------------------------------------------
----------------------------
@echo off

set sessionname=noset

rem Query the session zero
for /F "skip=1 tokens=1" %%i in ('call qwinsta 0') do set
sessionname="%%i"

rem Check if the Session zero is connected to the console
session. If so, exit
if /i %sessionname% EQU ">console" exit 1

rem Find out the session ID where the console is connected.
for /F "skip=1 tokens=2" %%i in ('call qwinsta console') do set
sessionnumber=%%i

rem Logoff the user remotely connected to the console.
rem Using "logoff 0" command tries to logoff normally.
rem Applications will be closed. The user profile will be
written. Application data
rem could be lost, however.
if %sessionnumber% NEQ 0 logoff 0

rem Reset session zero.
rem Only on Windows 2003, if you have just ran "logoff 0"
command
rem then "reset session 0" command is not necessary.
if %sessionnumber% NEQ 0 reset session 0

rem Attach the session zero to the physical console.
if %sessionnumber% NEQ 0 echo yes | reset session
%sessionnumber%

exit 1
----------------------------------------------------------------
----------------------------

There are two ways we suggest to run this script.
1. Using RC scripts.
- Create a new RC tool setting the rc_def_scripts policy method
to ENABLED
or FORCE.
- On the Windows 2003 target machine, create the pre_script.bat
into the
<lcf-tivoli>\PCREMOTE\w32-ix86\scripts directory containing the
above
batch program.
- When starting the RC session using the RC tool having the
scripts enabled, the state of the target machine is
automatically restored in order to allow the RC session to work
correctly.
- Moreover, you can run the RC session using the grace period
option (i.e.
setting the rc_def_grace_time and rc_def_timeout_op) in order to
give to the
remote user connected to the console via RD session, the
possibility to accept
or deny the RC session; of course, only when the RC session is
accepted, the
remote user will be logged off.
2. Using a Tivoli Task Library.
- Create a new Task Library;
- Create a new Task for windows platform setting Managed Node
name, path
file name of the above batch and the roles required to execute
it;
- When the target machine is in the state caused by RD session,
you can execute
the task in order to restore the initial state.
- Start a RC session.

Using this batch program, RC product is always able to remote
control a Windows 2003/XP box regardless its state.

By MS design, only one user can use console (locally or
remotely) at the same time. So, the following are the possible
Windows 2003/XP states:

1. User locally logged in.
2. User locally logged off.
3. User remotely logged in via RD session with console option;
4. User disconnected a RD session with console option;
5. User remotely logged off a RD session with console option.

All these cases are now supported using the above-described
batch program, but, of course, in the 3, 4 cases the user remote
logged in will be logged off.

As already said, MS stated that the connecting and disconnecting
a terminal session to/from the physical console is a very
expensive operation, this is the reason why this operation (MS
reset command on the session attached to physical console) takes
about 2 minutes to be completed. For instance, using the RC
scripts, you are able to run a RC session immediately, even if
the remote machine will be ready (displaying of Winlogon panel)
only after about 2 minutes.


*********************************
In order to keep application running after disconnecting
Prescript:
@echo off

set sessionname=noset

rem Query the session zero
for /F "skip=1 tokens=1" %%i in ('call qwinsta 0')
do set sessionname="%%i"

rem Check if the Session zero is connected to the
console session. If so, exit
if /i %sessionname% EQU ">console" exit 1

rem Find out the session ID where the console is
connected.
for /F "skip=1 tokens=2" %%i in ('call qwinsta
console') do set sessionnumber=%%i

rem connect session 0 to console session
rem then lock workstation
if %sessionnumber% NEQ 0 tscon 0 /dest:console /v
if %sessionnumber% NEQ 0 rundll32 user32,LockWorkStation

rem Attach the session zero to the physical
console.
rem "echo yes" command to force the input of the
interactive MS reset command

if %sessionnumber% NEQ 0 echo yes | reset session
%sessionnumber%

exit 1

***
Post script:

rem lock workstation
rundll32 user32,LockWorkStation
exit 0

Local fix

n/a

Problem summary

After starting Microsoft Remote Desktop using
the console on Windows XP or Windows 2003 platforms, the IBM
Tivoli Remote Control might display a black screen on the Remote
Control window of the controller workstation.

[arc]

Whenever I've used a console RDP session to a win2003 server, logged off and shortly after used a vnc session I too have experienced a black screen, but, after a short while 1 - 2 mins if I wait the screen eventually displays the logon screen and I can continue to log in.
I've also experienced the same on some xp machines.

Sometimes out of boredom I usually tap the CAD button in the corner. Notsure if this has made a difference.

[mjstumpf]

Posting here because it's entry 2 on a google search for my problem. Lot of talk in this post but most was only slightly useful to me.

In a nutshell, I set up a windows box and enabled remote desktop connections so I could administer/deal with it remotely. RDC is limited as you all well know, so I wanted to add VNC. Installing the latest ultravnc packages never went very smoothly, as it would only get quasi-installed and, when it worked at all, always displayed the blank black screen.

The fix? Go to the physical box, reboot, remove VNC, reboot, reinstall VNC, only use VNC from that point forward. (Hopefully while similar problems may happen if I use RDC, at least VNC was successfully installed and a reboot may cure it at that point)

Hope this helps someone.

[mmstahlman]

I had a very similar problem:
I was running XP SP2 and it worked for a while, but then I started getting nothing but a black screen when I tried to log in. I eventualy uninstalled and reinstalled SP2 for windows XP and it fixed the problem. I can't remember if i reinstalled VNC after I reinstalled SP2 though. Hope this helps.