UltraVNC On Windows 7 Video Issues?

[Norm@Home]

Hi All!

I've been using the older free version of RealVnc for a rather long time but I've been really frustrated with it's lack of a free version with support for Vista / Windows 7. So I had read about UltraVnc and decided to give it a try.

I am using the latest 1.0.8.2 version and I'm using the viewer on a Vista machine and the server on a new Windows 7 system I just put together.

I used pretty much all the suggested / default settings during the initial setup. The problems that I'm having are really minor but I'd like to see if there are any known fixes:

Problem one, if I right click on an icon pinned to the taskbar I can see on actual computer the context menu that pops up however the viewer does not show this i.e. I can't see it on the remote and forcing a screen refresh still does not show it.

Problem two, if I'm in windows explorer and I go into say a Temp directory and I see a list of files and I hit Ctrl-A to select all, I can see on the actual computer monitor all files selected / highlighted but on the remote computer in the viewer I can't see that. However in this case if I manually force a screen refresh, then I see whats been selected.

Is there a fix for either of these problems, perhaps a settings change?

Thanks,

- Norm

[B]

Oh I hope you get a good answer to those questions -- these have plagued me for a long time, in all versions of VNC on all versions of Windows. I end up constantly refreshing (at least there's a complicated hotkey for it). Twiddling with protocol options and screen resolutions doesn't usually seem to help...

[Norm@Home]

Oh I hope you get a good answer to those questions -- these have plagued me for a long time, in all versions of VNC on all versions of Windows. I end up constantly refreshing (at least there's a complicated hotkey for it). Twiddling with protocol options and screen resolutions doesn't usually seem to help...

As I had mentioned, I've never used UltraVNC which I believe is a fork of the original open source software. From what I can see it's had significant enhancements over the original version and adds some real nice features. I've used RealVNC on Win98, Win98SE, WinME, Win2K, XP and Vista. The problem in Vista is that the free version can't automatically start as a system service and you have to "buy" the personal version in order to get official Vista support. However there is a work around where once you login you can manually start the server and it will work. On rare instances I have noticed that I'd have to manually refresh the screen, but as I said that was really rare and otherwise it worked fine 100% of the time. I'm pretty sure that there must be some tweaks to fix this and it's just a matter of figuring out what they are. Hence, my question to those users who've have more experience than I.

- Norm

[supercoe]

Stuff to try that might help:

1) In the same directory as winvnc.exe only have schooks.dll instead of vnchook.dll
2) Enable Capture Alpha Blending.
3) Change the visual theme of windows.
4) Install the video hook driver.

I have the best luck with 1 + 2.

[Norm@Home]

Stuff to try that might help:

1) In the same directory as winvnc.exe only have schooks.dll instead of vnchook.dll
2) Enable Capture Alpha Blending.
3) Change the visual theme of windows.
4) Install the video hook driver.

I have the best luck with 1 + 2.

I tried 1 through 3 but it really was number 4 that seemed to do the trick.

The only question I have is that when I'm connected I get a message "A program that is running is incompatible with certain visual elements of Aero and the color scheme has been changed to Windows 7 Basic"? Now I really can't complain because it does work and the switch, unswitches when I disconnect so it's really not a big deal but is there anyway to correct this?

Thanks for the help!

- Norm

[supercoe]

Performance suffers greatly if Aero is enabled, it basically makes UltraVNC unusable.

There is an option to remove Aero in the properties.

I believe the video hook driver will automatically disable Aero, I don't think there is a choice.

[B]

Oh I hope you get a good answer to those questions -- these have plagued me for a long time, in all versions of VNC on all versions of Windows. I end up constantly refreshing (at least there's a complicated hotkey for it). Twiddling with protocol options and screen resolutions doesn't usually seem to help...

As often as I post here, I rarely use UltraVNC, and this is why.

Last night I need remote access and I gave it another shot, using the ChunkVNC build. Hovering over or right-clicking system-tray icons basically does nothing, except for slight partial lines across the tray. Ctrl-Alt-Del doesn't work (yes, I know there are fixes for that). Resizing or auto-fitting the screen is squirrelly (sometimes works and sometimes doesn't; sometimes works and then won't work again in the same session). Response time was nothing to write home about. I was going from an XP station to a Vista station; the Vista station had larger screens.

Anyway, I don't know if there's anything that can be done -- this is just a measure of my general dissatisfaction with UltraVNC. As always, I ended up using LogMeIn to get my work done. It works.


Edit: Aaaaand the repeater ("distributer") just crashed. It wasn't even in use. It was running on the same machine as the server service, and I was using the server machine for normal browsing (no VNC) at the time. Last VNC session was about 12 hours ago. Sigh.

UltraVNC is reputed by some to be the best of the VNCs. (Lifehacker seems to recommend it, at least.) And it may be. And that is what's troubling to me.



Edit #2: And now, about an hour later, the UVNC service crashed too. Again, VNC has <b>not</b> been in use during this time!

VNC server for X64/win32 stopped working and was closed.

A problem caused the application to stop working correctly.
Windows will notify you if a solution is available.

[supercoe]

B,

Are you running the repeater as a service? If so try running it as an application instead.

Is it possible to temporarily remove the UltraVNC service from the repeater computer? Just to see if it makes the crashing stop?

[B]

Nope. The UVNC was running as a service (via Chunk's system tray installation method) but the repeater was just running as an application.

Yeah, I could put the repeater on another machine here, probably on a virtual server. I was kind of planning on doing that when the new ChunkVNC release comes out.

But I could do it sooner. As noted, I really only work this thing out when I have need to do remote control.

[Note: UVNC service actually later restarted itself as intended.]

By the way, if running as a service is an issue for the repeater, that would kind of stink, since of course for a full time repeater you'd want that. (If the Linux version is more stable that would be acceptable too.)

Thank you for the suggestions... But in a way, I think I'm more concerned about the UVNC screen display issues (particularly the failure of right-click menus) than the crashing.

Edit: You probably access a lot more and different target PCs than I do -- haven't you noticed this kind of display problem?

[supercoe]

I've never tested running the repeater on Windows as a service that is why I don't recommend it. Some have stated that it works fine, some say that it crashes more.

The viewer not always updating right click menus does happen to me but not every time. I usually resort to right clicking and then clicking the refresh button on the viewer toolbar.

[B]

Right; I have to do the same thing (refresh) frequently with other versions of VNC too. That kludge gets old really fast. It's just not (yet) as good or reliable as the more commercial competition, unfortunately. GoToMyPC and LogMeIn don't have this problem (not sure about TeamViewer), nor does ordinary RDP, which of course works much differently.

So you see why I prefer to use a solution that "just works", especially when I'm in a hurry, and this despite my preference for multiplatform open source solutions that don't rely on 3rd parties.

I'm always surprised that people deploy VNC so widely when it still has, at least in my experience, serious usability issues.

At the same time, the commercial apps are very unattractive for mass deployments for all the usual reasons. For example, it <b>really</b> sucks to find you can no longer control one of your machines because someone's credit card expired. (For that reason alone, it makes infinitely more sense to install LogMeIn's free-forever version instead of its Pro version that goes dark whenever the license for that particular target runs out.)


Anyhow, I've tangentialized this thread enough. Thanks for the feedback.

[supercoe]

It sounds like your having the update issue more often than I am.

Usually in a 20-30min session with a client I'll hit refresh anywhere from none to a couple times.

How often do you find yourself needing to refresh?

[B]

In the past I've had to refresh TightVNC very regularly, like every few seconds, when connecting from PC to Mac (using Gitso). Less so when PC to PC, maybe a little more like what you describe.

With this installation of Ultra/ChunkVNC (PC to PC via repeater), I don't think right-clicking the system tray ever worked at all. But I'll get a chance to test some more in a day or two.

I'm sure a lot of it depends on just what one is trying to do while connected.

[Norm@Home]

I've only been using UltraVnc for a week or so, on one Vista x64 and one Win 7 x64 machine. While it may not be perfect, I have to say that I have not experienced the server crashing or any other severe problems.

The only problem I had noticed was the previously mentioned video issues and making those tweaks I had previously mentioned has made UltraVnc usable on my systems with no negative impact that I can tell.

- Norm

[B]

You said the only one that had a real impact for you (out of supercoe's list of 4 tweaks) was the video driver, right?

[Norm@Home]

You said the only one that had a real impact for you (out of supercoe's list of 4 tweaks) was the video driver, right?

Yes, it seemed like #4 checking off the video hook driver did the trick.

- Norm

[B]

So you see why I prefer to use a solution that "just works", especially when I'm in a hurry, and this despite my preference for multiplatform open source solutions that don't rely on 3rd parties.

I'm always surprised that people deploy VNC so widely when it still has, at least in my experience, serious usability issues.

Okay, I noticed I had fewer problems connecting locally across the LAN.


I took your suggestion of putting the repeater elsewhere. It's running on a production virtual server, and has not crashed in the last 5 days.

<b>However</b> I still have nothing but trouble connecting and using Chunk/UltraVNC remotely. Yet again I tried it when I needed it today, and it failed.

1. Attempted connection twice. Both times it failed (but like every average user, I managed to not record any error, because of course I was in a hurry.) Later forensics on the repeater log show:

Server added to list xxxxxx
recv 39
recv 0
connection closed by peer
Server Removed from list xxxxxx
Server added to list xxxxxx
recv 39
accept() connection
Viewer added to list xxxxxx
ID added xxxxxx
ECONNRESET detected
Server removed from list xxxxxx
Viewer removed from list xxxxxx
Server added to list xxxxxx
recv 39
recv 0
connection closed by peer
Server Removed from list xxxxxx

2. Later, after having successfully connected via LogMeIn and making NO VNC-specific changes, other than viewing the repeater log window, I was somehow able to connect okay.

3. But other problems persisted, and I still can't use VNC/Chunk/Ultra for any real work! No Ctrl-Alt-Del, screen resizing is a mess, switch screens stopped working (whereas it worked once before).

4. Then I lost connection and tried reconnecting, yielding yet another error:

Status: Connection closed (1)

VncViewer Message Box
Info Message
Server closed connection
- The server running as application

which others have mentioned.

Sorry this is not a full account; I'm in a hurry. The short story is, this is just not production ready for me! I'm afraid Chunk has little to do with it -- UltraVNC itself is proving to be as unreliable to me as, unfortunately, it always has been. Believe me I don't like to say it, but it's true.

[supercoe]

B,

After a long day of testing today I've come to the conclusion that these issues are happening when the server connects to the repeater before the viewer.

The server connecting first also causes the crash issue with the SecureVNC plugin.

At this point in time I've chosen to develop with "make sure the viewer connects first" in mind.

I know this isn't a fix for your issue but I figured I'd chime in on what I think is causing the problems.

[B]

Well, I'll take this as <b>good</b> news then, in that you've identified a commonality between two different bug scenarios.

Obviously that really, really, really has to get fixed in UltraVNC and/or the repeater, regardless of how you position ChunkVNC. (And obviously, making the viewer connect first is a pretty limiting thing, calling for even more coordination than the "what's your repeater ID" thing.)

Anyway, I'm also glad you were able to reproduce (?) the issue, and I certainly hope that "long day of testing" wasn't on my account.

Thanks.

[supercoe]

I certainly hope that "long day of testing" wasn't on my account.

Nope, I'm caught up with work and development is starting again.

[B]

Well, I'm still trying. I thought "hey, maybe it's a WAN or bandwidth thing, let me try it locally again to verify," thinking the local connection would go right in. No changes in my setup, repeater still active on a separate server, WinVNC still running as a service on my target.

But no... The viewer is stuck at "Negotiate Protocol Version..."

Checking the repeater, which I purposely hadn't even touched first, I see, including some previous recycling of the server re-attaching:

Server Removed from list xxxxxx <b>older stuff</b>
Remove server 0
Server Removed from list 0
Server added to list xxxxxx
recv 39
recv -1
Server Removed from list xxxxxx
Remove server 0
Server Removed from list 0
accept() connection
Viewer added to list xxxxxx <b>(my test viewer attempt)</b>
ID added xxxxxx
Remove viewer xxxxxx 0 <b>(after several minutes)</b>
recv -1
Viewer removed from list xxxxxx

I eventually got the "Connection failed - Error reading Protocol Version" popup at the viewer side.

In this test, you can see that the WinVNC service was <b>not</b> , for some reason, properly attached to the repeater, even though it was running and responsive in the system tray. As I've composed this message, it still hasn't shown up again at the repeater screen, so I gather it's just broken (even though I can bring up its About, Kill All Clients, etc., and a hover shows it listening on all NIC IP addresses).

Annnnnnd, right after I wrote that, Server showed up logged at the repeater again. (I was going to kill the WinVNC service too.) Let's try the viewer again... (thinking maybe it's the viewer attempt that kicked off the server before...)

I don't say this, like, ever, but "WTF"? This time both the server and the viewer appear to be properly logged,

Viewer removed from list xxxxxx <b>(as above)</b>
Server added to list xxxxxx
recv 39
accept() connection
Viewer added to list xxxxxx
ID added xxxxxx

So everything looks fine this time, except for the <i>minor</i> detail that the Viewer hasn't <b>worked</b>. Still sitting at "Negotiate Protocol Version..."

It's enough to make me just give up.

Canceled the viewer (got "server running as application"). Stopped the service. Connected viewer, then restarted service. So VNC control works again, at this particular moment, and I've just blown more time fiddling with this darn thing. Again, for those who use UltraVNC successfully and stably across campuses and enterprises, I honestly want to know -- how? What's your secret?

Annnnd, it died again (server running as application) when I tried to reconnect the viewer!

Viewer added to list xxxxxx <b>adding viewer first</b>
ID added xxxxxx
ID viewer found xxxxxx
Server added to list xxxxxx <b>server added</b>
local input is EOF
Server Removed from list xxxxxx
Viewer removed from list xxxxxx <b>end of GOOD test session</b>
Server added to list xxxxxx <b>server reconnects normally</b>
recv 39
accept() connection
Viewer added to list xxxxxx <b>try viewer again</b>
ID added xxxxxx
local input is EOF
Server Removed from list xxxxxx
Viewer removed from list xxxxxx
Server added to list xxxxxx
recv 39
recv 0
connection closed by peer
Server Removed from list xxxxxx
Server added to list xxxxxx <b>server still reconnecting</b>
recv 39
recv 0
connection closed by peer
Server Removed from list xxxxxx
Server added to list xxxxxx
recv 39
accept() connection
Viewer added to list xxxxxx <b>try viewer again</b>
ID added xxxxxx
ECONNRESET detected
Server Removed from list xxxxxx
Viewer removed from list xxxxxx
Server added to list xxxxxx
recv 39

So your "start the viewer first" approach/theory worked... once.

Ah, whatever. This is no fun at all.

P.S. I may have mislabeled the steps in the last log excerpt.

[beta]

do you have a updated video hook driver it is why windows changes to basic i disabled mine now works but nice to have updated hook