[BUG] Win7 vncviewer Gray Screen w/1.0.9.6.1 - 1.0.9.6 works

[DennisD]

On a new install of Windows 7 x64 I was going crazy trying to figure out why vncviewer 1.0.9.6.1 would connect and only show a gray screen when I connected to UltraVNC on XP and different VNCs on Linux.

I, eventually, tried 1.0.9.6 out of a new zip file download of UltraVNC and it works fine.

I tried 10.9.6.1 out of a new zip file download to see if my installer copy was somehow corrupt and it acts the same way.

Both the 32 bit and 64 bit versions of 1.0.9.6.1 give the gray screen. The 32 bit version of 1.0.9.6.1 on XP works fine.

Let me know if there is anything you would like me to try to help you duplicate this issue or if you need any more information.

Dennis

[DennisD]

1.0.9.6.2 does the same thing except I get a blue instead of a gray screen. 1.0.9.6 works (except 1.0.9.6 ignoresselectedscreen in options.vnc)

[DennisD]

I tried vncviewer 1.0.9.6.2 ( http://www.uvnc.eu/download/10962/ ) and it gives me a blue screen instead of a gray one, but otherwise has the same problem. 1.0.9.6 works fine except it ignores the selectedscreen in options.vnc (a completely different issue).

[rcooke]

Do you have encryption enabled?

If so, turn it off and re-test.

[DennisD]

No DSMPlugins are enabled.

[rcooke]

Win 7 is the target (or "server") side?

What options do you have set? You want the mirror driver for sure.

Do you have UAC enabled?

Beware of the viewer's default settings. It tends to keep track of your choices and add them all together!

[DennisD]

I'm having trouble on the Win 7 client side. I'm connecting to Fedora (multiple versions), Win XP and Debian Servers. It acts the same in all cases.

UAC is enabled on the Windows 7 Professional client. I've tried deleting the options.vnc file and using the viewer defaults and also every combination of settings I could come up with. It all acts the same. I have the mirror driver running on the XP "servers", but not on tigervnc or x11vnc (LibVNCServer).

[rcooke]

If your new to uVNC then I recommend you start testing between two direct-connected (no repeater) machines with the same OS - preferably XP Pro. If they are on the same network, its pretty easy to setup.

After you get that working, change one machine to Windows 7. Then reverse roles.

I do not know what file you deleted. I thought all settings were kept in "ultravnc.ini". As it happens, I use shortcuts for my remote machines. I think (but am not certain) that avoids issues with "defaults" in the viewer. For example, the shortcut command line to remote in to the office FAX computer is:

"C:\Program Files\UltraVNC\vncviewer.exe" /password LetMeIn 10.0.0.15

You can add this to the end to enable debug output in a console window:

-loglevel 12 -console

[rcooke]

In fact, this is what appears in the log window when I connect to the FAX computer. (both are XP Pro).

fh is 3
Started and Winsock (v 2) initialised
bufsize expanded to 4352
Registered connection with app
Connected to 10.0.0.15 port 5900
DSMPlugin not enabled
RFB server supports protocol version 3.8
Connected to RFB server, using protocol version 3.8
VNC authentication succeeded
Read a 32-byte string
Desktop name "fax ( 10.0.0.15 ) - service mode "
Geometry 1024 x 768 depth 32
Screen work area is 1920 x 1050
Reset keyboard for first use
Flush dead key gives: 1 character(s): 0x0020 ( )
Clipboard changed
Ignore Clipboard while initializing!
No next window in chain; WM_DRAWCLIPBOARD will not be passed
SetClipboardViewer to 0x000b0aa4; next is 0x001a0a96. Last error 0x00000002Cache
: Cache buffer bitmap creation
Screen work area is 1920 x 1050
Update-processing thread started
Screen work area is 1920 x 1050
Screen work area is 1920 x 1050
ServerState- reading 11 bytes
ServerState (2, 5)
New keepalive interval 5Read remote clipboard change
Read remote extended clipboard change
Cache: Cache buffer bitmap creation
Requesting new pixel format
Cache: Cache buffer bitmap creation
Screen work area is 1920 x 1050
Receiving cursor shape update, cursor 32x32
bufsize expanded to 16640
Requesting new pixel format
ServerState- reading 11 bytes
ServerState (2, 5)
New keepalive interval 5Read remote clipboard change
Read remote extended clipboard change
ServerState- reading 11 bytes
ServerState (2, 5)
New keepalive interval 5Read remote clipboard change
Read remote extended clipboard change
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32
Receiving cursor shape update, cursor 32x32

[DennisD]

C:\Program Files\UltraVNC\ultravnc.ini is used for the server side (which is working ok).

C:\Users\%USERNAME%\AppData\Roaming\UltraVNC\options.vnc is used for vncviewer.exe (the only program I'm having an issue with).

Here is what it looks like when I try to connect to a Fedora 14 server (libvncserver) from this Windows 7 Pro desktop using vncviewer 1.0.9.6.1:






It's the same connecting to XP Pro. It seems to have kept the change to a blue screen instead of gray when I tried 1.0.9.6.2 (see earlier post). The color might not matter, or it might. I don't know.

Note that 1.0.9.6 works perfectly (except it doesn't keep which monitor you want to use on the local side, which is most likely independent of this issue).

[DennisD]

Here is the console loglevel 12 when it is working with 1.0.9.6:


Here's the about from 1.0.9.6:


This is 1.0.9.6.1 (obviously):

[DennisD]

I downloaded the zip for the 32 bit 1.0.9.6.1 and ran the vncviewer from that with the same results.

[rcooke]

Oh, I don't know if its a good idea to play around with 32-bit and 64-bit software on the same machine. That sounds like a bad idea.

Just stick to the one appropriate to your OS.

I think your problem is related to one I posted:
https://forum.ultravnc.net/viewtopic.php?f=54&t=28842

In as much as in both situations the solid colour represents an initial canvas onto which the server's screen is drawn. And in both cases no data is coming in, but likely for different reasons.

Although what does your connection status window say?

[B]

If it's happening when connecting to 3rd party Linux servers then it certainly sounds like a Viewer-specific issue. For what it's worth here are excerpts from the changelog I find at Softpedia -- why the heck I have to go there to find the UltraVNC changelog I have no idea.

What's new in UltraVNC 1.0.9.6:
April 5th, 2011

· server site scaling crash server and/or viewer
· (This also solve situations where the resolution after reconnect differ
· from the original)
· wallpaper fixed (aero/wallpaper +services crash seems also solved)
· options Gui group
· Allowshutdown=0 service problems fixed
· optimized memcpy function 1/1 scaling
· optimized capture functions
· recompiled addons for w2k (kernel pointer error)
· minimize artifacts on window move
· compatibility with other vnc flavors and old ultra versions
· vncviewer -config

Added:
· server systray ( show ip/name/app or service)
· forced reboot
· selectable display ( prim/sec/3the/all) for showing the viewer
· u2 (lzo/jpeg) encoder


Home > Windows > Internet > Remote Utils > UltraVNC > Changelog
UltraVNC 1.0.9.6.1 - Changelog

What's new in UltraVNC 1.0.9.6.1:
June 18th, 2011

server:
· crash chat x64
· AuthRequired=0, passwd=NULL: Warning message block service
· *About x64 say win32
· viewer 1082 and server 1096 with localcursor ( no connect, 100% cpu)
· serversite scaling and multiple viewers, framebuffer size get overwritten
· (Scale is now lock when multiple viewers are connected to avoid a
· framebuffer change, first connected viewer set scale. Site effect is that
· the viewer report the unused, incorrect scale, but at least it doesn't crash anymore)
· -connect ip, passed to winvnc running as service is not remembered for
· utoreconnect.
· -stopreconnect
· top the autoreconnect function of the server.
· server mouse moves jump on viewer when screen is idle.
· old plugin zrle crash

viewer:
· plugin (SecureVNCPlugin) used by viewer
· server without plugin
· give incorrect viewer message. And doesn't ask to reject the connection.
· monitor value is saved, but vncviewer read it as bool (true/false) Only 0/1 are correct imported
· old plugins fail when zrle encoding is used
· old plugins give incorrect info in statusbox
· -autoreconnect timeout, -reconnectcounter number (available from gui and commandline)
· autoreconnect timeout was incorrect, updated
· old plugin detection
· Messagebox was sometimes displayed on invisable desktop
· auth dll error messages for missing dll's incorrect
· mslogon and no groups, didn't checked admin account for access
· lock /logout screen on exit viewer option blocked shutdown server.

javaviewer:
· mslogon fixed

added special build:
· only one port for javaviewer (rfb port is used for java download and rfb data)

[rcooke]

You did not post your server settings. These are very important.

The server settings are here:


And these are what I typically use:

[DennisD]

The Bytes Sent goes up every so often. The Bytes Received doesn't really change.



I use vncviewer to non UltraVNC servers 90%+ more than I connect to Windows Servers, although they act the same way with regard to this issue.

[rcooke]

The Bytes Sent goes up every so often. The Bytes Received doesn't really change.

I use vncviewer to non UltraVNC servers 90%+ more than I connect to Windows Servers, although they act the same way with regard to this issue.

Dude: "Speed 0 kb/second". That is your problem. The server is not sending you anything.

I use Jolly's Fast VNC on my MAC to talk to everything. And I use VNCviewer to talk to my MAC OS's built in VNC server. And I even found an excellent VNC viewer for my iPhone and iPad!!!

One thing I had to understand is the VNC standard is very basic. uVNC has a LOT of extensions that other operating systems do not support - like file transfer for example.

I see in your connect log the uVNC viewer requested the server switch to 8-bit colour. Who says it can? I recommend you set both ends to the same screen size and colour depth. And you have to find out if the server your using has equivalent options to what I posted for the uVNC server.

Good luck, and happy hunting!

[DennisD]

It's the 8-bit color that gives me the blue screen! If I set it to auto, I get the gray screen again. Note that it doesn't matter if I connect to Linux or XP, it's the same.

I discovered it was the 1.0.9.6.1 (and .2 see above) version of UltraVNC because I tried TightVNC and it worked fine. This was on a new fresh install of Windows 7 Pro. I installed 1.0.9.6.1 and it didn't work. Tons of troubleshooting later (and after having TightVNC work), I tried an older copy of vncviewer and it worked. I narrowed it down to 1.0.9.6 working and 1.0.9.6.1 not working.

[rcooke]

When your testing between two Windows machines, are they the SAME version of uVNC?

[B]

Dennis, thanks for sharing your findings -- I bet you're saving other people a lot of the same headaches!

Conclusion: "auto" settings may not be the best bet when mixing VNC flavors or version numbers.

Idea: Provide the next version of UltraVNC with a very simple "Make VNC Compatible" button that willl help ensure connectivity with the largest possible pool of 3rd party VNC software. This would turn down settings and options to make it act like a generic VNC client from 2000 or so.

[rcooke]

Dennis, thanks for sharing your findings -- I bet you're saving other people a lot of the same headaches!

Conclusion: "auto" settings may not be the best bet when mixing VNC flavors or version numbers.

Idea: Provide the next version of UltraVNC with a very simple "Make VNC Compatible" button that willl help ensure connectivity with the largest possible pool of 3rd party VNC software. This would turn down settings and options to make it act like a generic VNC client from 2000 or so.

@B:

Hey, could you perhaps shed a little light one a best-bet group of settings?

[B]

Rudi would know best. I would just be guessing (no plugins, no polling options, only RAW and Hextile encoding, no JPEG compression, avoiding "auto" settings, etc.).

I guess we could pick up an ancient copy of AT&T/Olivetti VNC (before RealVNC) somewhere and test against that, as well as against the various Linux flavors.

[DennisD]

When your testing between two Windows machines, are they the SAME version of uVNC?

Yes. The XP Pro machines are all running 1.0.9.6.1 for both the server and vncviewer. Those machines can connect to ALL of the VNC servers (Linux and even the Win 7 Pro machine) that I connect to. The vncviewers are all using the settings I'm using here (although I've tried every combination of vncviewer settings I can think of with 1.0.9.6.1 on Win 7 Pro and it doesn't make any difference that I can see).

[rcooke]

I haven't forgotten about this. I'm setting up a test scenario to see if I can reproduce your results.

[DennisD]

I think the key might be in the console window where it says "Update-processing thread finishing" on the one that doesn't work. It seems to just be quitting the screen update processing. I started to try to build UltraVNC viewer from source, so I could add more debugging around the update-processing thread, but I never did get it to fully build and I'm now really swamped. Eventually I'll get back to it and see what I can find out.

[rcooke]

@DennisD:

I can happily run VNCviewer 1.0.9.6.1 x64 or 1.0.9.6 x64 on my Windows 7 Pro SP1 and connect to my FAX machine from outside my network - using a redirect in my router - but essentially a "direct" connection.

Will set up a repeater test next....

[rcooke]

I have a workstation (Workstation02) that is XP Pro and it connects to the repeater without using the DSM plugin. Like the FAX machine this is a 32-bit version of Windows.

From my Win 7 Pro x64 bit machine, I can use this shortcut to start up VNC viewer and connect:

Code: Select all

"C:\Program Files\UltraVNC\vncviewer.exe" -proxy repeater.ca::00000 ID:4263007 -quickoption 1 -keepalive 1 -dsmplugin SecureVNCPlugin64.dsm -loglevel 12 -console

I get a warning that the remote does not support encryption. Then I get a grey window for about 2-3 seconds before it turns into the target desktop.

Everything seems to work. I'll setup another test where the FAX or Workstation02 machine have encryption enabled.

All my machines are running uVNC 1.0.9.6.1 unless I say I tested something older.

[DennisD]

This could EASILY be something odd with this laptop (an HP Elie Book 8440p). I used the HP OEM software load of Windows 7 Prof.

It's the only Windows 7 computer I have access to right now. Everything I connect to is either XP (running UltraVNC 1.0.9.6.1) or Fedora or Debian (for the most part).

I've left 1.0.9.6.1 up at the gray (or blue) box for over an hour and it never connected. I'm not using any plugins with UltraVNC.

[rcooke]

Yeah, don't get me going on the topic of "Hacks HP likes to do to Windows Installs" or "Hacks HP likes to add to BIOS". Both have caused me serious grief over the years.

I'm running the non-branded, un-molested, OEM version of Windows. It might be identical to the retail boxed version.

An important test note, I discovered what was mentioned earlier about the importance of your connection settings. Going through the repeater, I discovered I could not use my usual favourite setting -quickoption 1, which sets the connection params to AUTO, looking for the fastest data rate. Every time I tried to connect with this option, my connection stalled on the version handshake. I noticed ChunkVNC uses -quickoption 3, I changed to that and the problem went away.

What I'm saying is I recommend you download ChunkVNC, compile it, and use it for a test. If it works with Win 7 - use SysInternalTools process explorer to get a look at the command line arguments its using.

[DennisD]

Well, looking back at your posts, I tried:

vncviewer -quickoption 3 -keepalive 1 -loglevel 12 -console (the same 1.0.9.6.1 vncviewer.exe sitting in my temp directory as I've used before)

AND IT WORKS! (well to the Fedora 14 server I connected to). I then tried it with no -quickoption and it worked. I then tried it with NO options...

It now works with just running vncviewer... I'm guessing there was a Microsoft patch *OR* one of the annoying HP updates that fixed it.

Ugh. Now I'll never know what the problem was. I'd MUCH prefer to know what the problem was than to have it just work.

If anyone runs into this with the same option, at least they know what we tried. I'll keep trying every host I can find and I'll post back here if it doesn't work, but I'm guessing a patch (M$ or HP) fixed it.