MS Remote Desktop Connection & Blank Screen after for VN

[InGearX]

It's a known problem:
If you use Microsoft WinXP Remote Desktop Connection (has some neat features)
and then try to use any VNC including Remote Admin or PCAnywhere you will encounter a blank screen.
Thus only Remote Desktop Connection can get you back in...

Seems that there is a solution:

hardly related to Ultr@VNC though...
*make sure your WindowsXP professional is upgraded to SP2.
*download this file and extract to wherever you want.
*run the install.bat. your computer will automatically reboot.
*run the postreboot.bat. now your computer can handle concurrent sessions.
have fun!

- [topic=307][/topic]

Has anyone tried it?

Any other work arounds?

Thank you...

[InGearX]

I have Service Pack 2 v2096;
Followed instructions;
And the above fix fails to work : (

[InGearX]

I tried the new fix (http://lizard.ddo.jp:81/xpsp2cs_02.zip) as per your instructions and I was able to VNC and Remote Admin in just fine and then went in with WinXP Remote Desktop and after that I was not able to use VNC (blank screen then closed after 10 sec) nor Remote Admin (failed to load screen at all)

(but this is a change from prior, because they would both load and just stay with the blank screen)

Just incase I had my server do
install.bat
and
postreboot.bat
again, with same results.

So I compared (via UltraEdit and just size)your termsrv.dll to new one in "system32\" and they were identical;

One strange thing is that in my
C:\WINDOWS\system32\
I could not find directory
"dllcache\"
hmmm...

I would really like to help to solve this problem for my self and for everybody else;

I really appreciate your help;
Anything else we could do, would be great...

Thank you and awaiting...

- InGearX to lizard ([user=16][/user])

[InGearX]

IM to lizard:

Thank you,
Just checked and compared:

C:\WINDOWS\system32\dllcache\termsrv.dll

and it checks of to be exactly the same as in
C:\WINDOWS\system32\termsrv.dll
and of course the termsrv.dll supplied in your package (211KB vs original 288KB)

I think it might be just something else : (

[LION]

Hi everyone.

I have same problem like this.
But I cannt get the solution file. So Please someone tell me What I Do.

[MO]

Well I will say that I can connect to my server at work through RDP then start VNC from that machine into another machine in the LAN (at work) then from that machine I can start PCAnywhere and dial out to any connection I want.
The trick to getting the screen to refresh is to click on the title bar of VNC or PCanywhere (depending on which you want to refresh). It should fix your blank screen problem.

[rmoller]

The issue occurs if

- UltraVNC is running as service
- someone has connected with RDP client TO CONSOLE (session 0)

(Ultra)VNC is by far the only program getting problems when you do this - many backup programs etc. fail similarly.

MSTSC /CONSOLE /V servername

connects you to the console screen instead of a new separate console. The problem is - when you do this, console is no longer running as session 0, but - say session 3. However, all services - including UltraVNC service - continues to run in session 0, which is by now disconnected instead of connected to the console. The whole environment of running processes is changed (semi-)permanently.

There are two ways out of this. Either a reboot of the server or forcing a logoff for every session in the system, including the console.

This link describes a command line to reset all sessions; I have tried it and it works for me. It can be run remotely with the help of SysInternals PSExec or however you might want to trigger it.

Rasmus

[gp]

[quote]
The issue occurs if
- UltraVNC is running as service
- someone has connected with RDP client TO CONSOLE (session 0)
[/quote]


Have this problem as well with v. 1.0.1
Anyway, with 1.0 RC 18 this problem did not occur.

I find this very annoying because we use Remote Desktop Console and VNC in parallel on Win2k3 servers (Win2k does not support /console on RD therefore this is not an issue on this OS).

Is there any way to fix that permanently?
As far as I know other VNC implementations (like WinVNC) do not have this problem