VNC Blackscreen. Read faq, NOW WHAT?

[nutsnbolts]

Hrm.

That's what I'm saying to myself at the moment regarding the blacking out of the screen when connecting to VNC.

Yes, there is a faq there. I have read through the entire thing and still, there is no solution to this madness. LOL.

I use remote desktop in conjunction to XP Remote shutdown tool.

According to the FAQ of the problem. If you have RDP running, VNC will be fine due to driver issue allocation or something to the like. I have tested this and yes, that's true.

You can work around this by restarting your machine as long as you don't run RDP, if I read correctly. Well, after the remote machine restarts, I would need to log into the computer so I use remote desktop again.

What is the purpose of VNC now if I have to keep using RDP to connect/reconnect/make it work/etc?

I thought this is supposed to be just a "run the server, now connect" DONE!

Now what?

[Rudi De Vos]

The problem is that MS made some changes starting from XP.

A service can only be inteactive with session0.
Prior to XP, Session0 was always the desktop...after XP, and for
some unknown reason, onces you used "FUS" or RDP the console session become 1 or 2...

Running as service, the OS block access to non session0
-->black screen.
MS made sure you only can use RDP to make a connection,
first with FUS, win2003 after RDP, Longhorn total block.

This is not only a vnc problem, but all remote controle application have the same problem....only RDP does not.
Even Pcanywhere was having the same problem for more then
a year, but know it seems finaly fixed.

Vnc running as application ->all OK
Vnc running as service -> OK until you switch user or use RDP.
For fast user switching, we try to activate a seccond vnc session running on the next available port, 5901
I don't know if the same trick works after RDP made a connection.

Sorry for the long answer,
It was just to indicate that we still need to do a lot of R&D,
and making a solid solution for the black screen in not easy.

[InGearX]

"VNC running as application ->all OK"

So pretty much I can avoid the black screen by running UltraVNC as an application, each time the user logs in?

But the problem is that when MS Remote Desktop Connection exits, it places the system in a no user state.

Where one would need to
a) use MS Remote Desktop Connection to log-in a user
OR
b) manually come to the machine and log in a user

So VNC is helplessly locked out...

Do you follow?
Am I all correct? Any solutions?

Thank you...

[PeterH]

InGearX wrote:

"VNC running as application ->all OK"
So pretty much I can avoid the black screen by running UltraVNC as an application, each time the user logs in?

If even that worked, I'd be happy, but I still get a black screen after running UVnc as an app after logging in via RDP.

What I've observed on MY Win2K3/SP1 with RDP enabled and using Server/viewer RC20.3 is:

* Any VNC login leads to a black screen on the client

* The client screen WILL update itself *if* I create and then maximise and minimise an RDP connection to the same machine - this is truly fascinating behaviour

* BUT the connection is not really active: mouse-clicks etc. have no effect and the screen does not update (unless I do the maximise/minimise RDP thing again). Screen refresh also has no effect.

* This is true of the HTTP Java viewer as well as the direct connection

* A local loopback test (conducted on the server, but via RDP because I am not near it) is interesting -- the screen *does* appear to update itself, literally going into a loop displaying the VNC header repeatedly down the screen. However, I can't be sure if this is a realistic test; the machine is not local so I can't do a hands-on loopback test

Note: For me, an RDP logoff does not stop UltraVNC server running, even if run as an application

Using RC20.3...

[PeterH]

Ok, I can answer my own question now, after looking all over this site (and doing some posts in other relevant topics).

NONE of solutions mentioned, e.g. TSCON 0 /DEST:console
worked for me. The only progress was noticing that VNC will work if the RDP window is present but not minimised. Not exactly useful...

However, switching to RealVNC v4.1.1 server (the latest available) solved the problem. I can RDP or not, VNC or not, and each works ok. Any viewer, including Ultr@VNC R20.3.

So if the same fix can be isolated and put into the final release UltraVNC 1.0, that would be wonderful!

[redge]

Rudi

It was just to indicate that we still need to do a lot of R&D,
and making a solid solution for the black screen in not easy.

is not a bad critic, I would never that way. only share idea

I remember, UltraVNC is based on RealVNC 3.3.x + all advantage of RealVNC 4.x.x without strong password 2048bit but now... only missing share RDP.

Is there really a lot of difficult to find the part of code where fixed RDP issue on RealVNC 4.1.1 ??

Thank you a lot for PeterH find the workaround solution until UlraVNC staff fix this issue.

edit:
tested successfully realvnc 4.1.1 and RDP, no black screen as level system service !
user by RDP is just loged off and new user VNC can log on
Rudi, you need to revise your code with very LESS R&D effort, realvnc had the solution

[paintcheck200]

Similar to the issues I'm having - except I'm not using RDP (or least so I think). Always been confused about differences between RDP client and REMOTE Desktops client that s in the admin pack. The symtoms I have are. The OS is server 2003, sp1,

[topic=2743][/topic]

*If server has just booted and I ultravnc to it - its fine.

*If I use the "REMOTE DESKTOPS" utility that is in the admin pack, and then close it - I can no longer use ultravnc - unless I restart the winvnc service or re-login with the REMOTE Desktops utility. Same as nutsnbolts problem.

We would really like to use UltraVNC in our production enviroment, but this is just to big of an bug/issue to actually use it.

[bitbuerster]

Vnc running as application ->all OK
Vnc running as service -> OK until you switch user or use RDP.
For fast user switching, we try to activate a seccond vnc session running on the next available port, 5901
I don't know if the same trick works after RDP made a connection.

So if I understand that right:
- running vnc as a service will fail in the very moment that someone uses FUS
- the only way to keep FUS would be to install vnc on each user account and make it an autostart there
- then however, there is no chance to remotely reboot a PC as it would require vnc being run as a service

Isn't there any workaround to this? Like installing VNC once as a service and in addition, as an autostart application in each user account?

tnx

[redge]

Like installing VNC once as a service and in addition, as an autostart application in each user account?

you can run VNC server as addition with autorun
"%programfiles%\UltraVNC\winvnc.exe" -fus