vncviewer.exe crashes on first few connects, then it works

[sfhub]

Server and Client are both 1.0.8.2 Dec 7th build
Viewer is WinXP. Have tried Server running on Vista and WinXP. Same problem on both.

I've seen a couple of references to this with no real resolution.

It occurs for me intermittently. I don't know for sure what is causing it, but it "feels" like some sort of race condition.

When it happens, the connection succeeds to the server and I see the remote screen, but after about 2 seconds, a windows error prompt pops up saying vncviewer.exe crashed with reference to ntdll.dll

Sometimes the next attempt to connect succeeds but other times I might need to try 3 or 4 times. Eventually it does connect and everything works fine afterwards, just have problems with that initial connection. At other times, there are no problems with the initial connection. This is why I say it feels like some sort of race condition.

Anyway, here are the other references to this problem I've seen:

[topic=17932][/topic]

[topic=16540][/topic]

[post=65004][/post]

[topic=17533][/topic]

There is reference to a race condition but I have no evidence this is the same problem, just a possiblity for developers to consider based on symptoms.

[topic=17381][/topic]

[supercoe]

I've added the code in the last link to 1.09 patches:
[post=69230][/post]

[sfhub]

Hi, thanks for doing that.

I think that patch was just a quick and dirty workaround to avoid a problem rather than an actual fix.

Also I'm not sure if that is the cause of the problem I was seeing. That person described a problem with entering the wrong password. In my case, I'm entering the correct password and getting the initial screen displayed before seeing a crash. It might be the same root cause but it might not.

I think someone probably needs to look into it further to see if these symptoms are both caused by the same root cause. Instead of (or in addition to) that patch, it would be best to eliminate the race condition altogether rather than just catching the error.

[sfhub]

I think the viewer crash might be related to having "Quick Options" set to Auto.

When I set the options to Manual, I don't seem to get the crash anymore. This is after testing it all day.

I think when the connection is set for Auto, it exposes a race condition which will intermittently cause the viewer to crash. It apparently doesn't happen for everyone and even for the people it does happen to, the crash is sporadic, so there is probably some other timing or condition involved, in addition to "Quick Options" Auto.

[B]

Thank you! That would be a terrific development -- if nothing else, it's a great workaround. Very few people really need it set to "auto", so picking your ports and hard coding them should be painless.

[sfhub]

I think "Auto" is less about port #s and more about selecting the appropriate connection parameters for the bandwidth you have available. Things like compression, encoding, colors, etc.

[sfhub]

I compared the log files of a "crashed" session with a "good" session to get a rough idea where in the process it was crashing. Here are the two log files:

You'll notice that the Crashed Session has no more log information after the final "New keepalive interval 5"

The Good Session successfully expands the bufsize and receives a cursor shape update.

Somewhere between those two areas the viewer is crashing. Whenever it crashes I see the remote desktop along with a blacked out box around the pointer, which makes sense since the crash happens before "Receiving cursor shape update", but after "New keepalive interval 5"

Crashed Session

Started and Winsock (v 2) initialised
bufsize expanded to 4352
Registered connection with app
Clipboard changed
Don't send initial clipboard!
Connected to 192.168.1.121 port 5900
DSMPlugin enabled
RFB server supports protocol version 3.6
Connected to RFB server, using protocol version 3.4
VNC authentication succeeded
Read a 25-byte string
Desktop name "pc ( 192.168.1.121 ) "
Geometry 1920 x 1080 depth 32
Screen work area is 1920 x 1170
Reset keyboard for first use
Flush dead key gives: 1 character(s): 0x0020 ( )
Cache: Cache buffer bitmap creation
Screen work area is 1920 x 1170
Update-processing thread started
Screen work area is 1920 x 1170
Screen work area is 1920 x 1170
ServerState- reading 12 bytes
ServerState (1, 1)
New input state 0ServerState- reading 12 bytes
ServerState (2, 5)
New keepalive interval 5bufsize expanded to 16640
Receiving cursor shape update, cursor 32x32
bufsize expanded to 32309
Requesting new pixel format
Receiving cursor shape update, cursor 32x32
ServerState- reading 12 bytes
ServerState (1, 1)
New input state 0ServerState- reading 12 bytes
ServerState (2, 5)
New keepalive interval 5

Good Session

Started and Winsock (v 2) initialised
bufsize expanded to 4352
Registered connection with app
Clipboard changed
Don't send initial clipboard!
Connected to 192.168.1.121 port 5900
DSMPlugin enabled
RFB server supports protocol version 3.6
Connected to RFB server, using protocol version 3.4
VNC authentication succeeded
Read a 25-byte string
Desktop name "pc ( 192.168.1.121 ) "
Geometry 1920 x 1080 depth 32
Screen work area is 1920 x 1170
Reset keyboard for first use
Flush dead key gives: 1 character(s): 0x0020 ( )
Cache: Cache buffer bitmap creation
Screen work area is 1920 x 1170
Update-processing thread started
Screen work area is 1920 x 1170
Screen work area is 1920 x 1170
ServerState- reading 12 bytes
ServerState (1, 1)
New input state 0ServerState- reading 12 bytes
ServerState (2, 5)
New keepalive interval 5bufsize expanded to 16640
Receiving cursor shape update, cursor 32x32
bufsize expanded to 32218
Requesting new pixel format
Receiving cursor shape update, cursor 32x32
ServerState- reading 12 bytes
ServerState (1, 1)
New input state 0ServerState- reading 12 bytes
ServerState (2, 5)
New keepalive interval 5bufsize expanded to 85132
Receiving cursor shape update, cursor 32x32

[B]

I think "Auto" is less about port #s and more about selecting the appropriate connection parameters for the bandwidth you have available. Things like compression, encoding, colors, etc.

I don't think that's true. Judging from the descriptions and placement of that "Auto" option in both TightVNC and UltraVNC, it certainly seems to involve ports and display numbers ONLY....

[sfhub]

Not sure if you are looking at the same "Auto" as me, mine says:

AUTO (Auto select best settings)
ULTRA (>2Mbit/s) - Experimental
LAN (> 1Mbit/s) - Max Colors
MEDIUM (128 - 256Kbit/s) - 256 Colors
MODEM (19 - 128Kbit/s) - 64 Colors
SLOW (< 19kKbit/s) - 8 Colors
MANUAL (Use options buttons)

The port and display numbers are in a separate entry area.

If AUTO involved "ports and display number ONLY" then why would the alternate options (if you click on ULTRA, LAN, MEDIUM, etc, AUTO is automatically deselected) specify bandwidth and colors?

For that matter, how would you even implement Auto port selection? Scan all 65k ports?

Finally, if you look at the UltraVnc Viewer Configuration manual, it tells you what each of those settings translates to and there is only mention of the connection settings, nothing to do with display or port #s.

http://www.uvnc.com/install/viewerconfig.html

[B]

I don't see those settings at all in the server (using the copy from ChunkVNC).

In UltraVNC the "auto" setting I'm talking about is in Admin properties, on the
Server Property Page, under "Incoming Connections".

In TightVNC the same "auto" setting under the Server tab.

I'm pretty sure we're talking about two different "auto" settings.

Edit. OH NEVER MIND. You're talking about the viewer, and I was talking about the server.

[sfhub]

Yes, the viewer is crashing, not the server.

[sfhub]

It looks like I can get the intermittent client crashing behavior to stop by selecting "Auto Scaling" in the connect options.

My viewer PC has a 1920x1200 display. I've had the viewer crash with remote displays of 1920x1080 and 1024x768 so I'm not sure if scaling is where the problem happens. Possibly turning auto scaling on avoids a race condition.

[jaybios]

sfhub - Excellent findings, i've tested it over 12 different PCs setting the connection speed manually and it doesn't crash at all any more! thank you so so much!

[sfhub]

Glad it helped someone.

So after finding that setting "Auto Scaling" avoids the problem (even when I have the connection params set to AUTO), I figured maybe it had to do with the server having a higher resolution than the client. I configured the server to be 1280x1024 so it fit natively on my viewer 1920x1200, and still got the crash, so it doesn't have to do with the resolution.

I then started testing remote machines over a VPN connection, orders of magnitude slower than my LAN. It crashed far less often but I was still able to crash it once.

So I think there is good evidence that it is probably a race condition and it shows up more often when using a high speed local LAN vs slower speed remote connection.

My current workaround is to set the Connection Settings as "AUTO" and when I'm accessing a unit on the high speed LAN, I'll click on "Auto Scaling" first.

Incidentally, it would nice if "Auto Scaling" had the option to only scale down, not up. If the remote screen fits natively then it would be nice to have the one-to-one pixel matching for a nice crisp screen, and only when the remote screen is too large, scale it down so I don't need to use scroll bars to access the remote desktop.

[chadvonnau]

I have the same problem, but the workaround for me is selecting "LAN" connection type. Turning Auto Scaling on or off in other modes doesn't stop the crashes for me. I am in a LAN environment.

[sfhub]

Yes, the problem looks like a race condition so the key to avoiding it is to change the timing of the connection sequence so the condition is not triggered. Depending on your network and the speed of your machines, different options may produce different timings for the connection sequence.

I've never had the crash happen on remote connections over VPN where the latency is 100ms.

My crashes have all been in a LAN environment where the latency is 1ms.

In my situation I can avoid the crash 99% of the time by changing the connection to autoscaling, but once every few months I'll see it crash even with that setting. Again, I don't think the setting itself if fixing or indicating where the problem lies, but it is just one technique to change the timings to avoid the problem.

I've tested the 1.0.9.0 RC1 client against a 1.0.8.2 server and the crash is still there.

[sfhub]

Tried with server running mirror driver and crash doesn't happen (in the viewer), but as usual with a race condition, the change might have nothing to do with the actual cause, just might be changing the timing of events to avoid the issue.

[redge]

sfhub
is your MTU is set to auto or static 1500 standard for Ethernet in windows or in your router ?
or
do you have any traffic shaping manager ?
http://www.cfos.de/traffic_shaping/traf ... ping_e.htm

viewer: vista business
server: win7 home premium
i just tested vncviewer 1.0.9.1 quick option=auto as is no other modification over lan 100Mbit/s without dsmplugin, success.

[redge]

sfhub

what is your LAN speed 100 Mbits or 1000 Mbit/s 1 gigabit/s ?
for gigabit, there a known issue with jumbo packet need to be disabled on Network interface card
I can't verify, won't have network gigabit.

[nihartjones11]

I have had this problem for some time. I never had the problem on low-end machines (P4s), but over the last year I have upgraded my machines to Core2 Duos and Core2 Quads, and they all experience this issue. I have seen this on both Vista and Win7, 64-bit versions of both.

My solution: I found that if I leave the mouse alone (hands-off!) for the first few seconds when the view-screen comes up, everything is fine. Works every time... but touch/move that mouse, and I get this issue.

It doesn't seem to matter what my connection and/or screen-scaling options are. However, my current viewer settings are:
Auto select best settings
Track remote cursor locally
and I start the viewer with the -scale 85/100 switch

The Viewer is 1.0.8.2 built Dec 7 2009
The Server is 1.0.8.2 built Dec 6 2009

Running Win7 64-bit on both ends. It happens on my gigabit-LAN to local machines, and on a high-performance Comcast Internet connection (20 MBits) to my remote office locations.

I agree that it appears to be a race-condition that has become sensitized due to the higher performance of the machines.

Hope this helps.

[Rudi De Vos]

It's hard to repeat and it only happen in the release version.
But i think the cause is found and fix.

Tech info
The cursor data get delete on encoder switch, but simultanious a
cursor update can still be in progress ( multiple threads)
If both happen togther -> crash;.. mutex protection added.


Please try this test versions... ( w32/x64 v. 1.0.9.2)

http://www.uvnc.eu/download/vncviewer_crashtest.zip

[Rudi De Vos]

pump

[nihartjones11]

Your fix seems to have indeed solved the problem. I can't get the viewer to crash, and I've tried all the familiar scenarios.

Thank you very much! I look forward to the next Stable Release.

[sfhub]

Yes, confirmed fix in these beta builds:

[post=81059][/post]

[nihartjones11]

Well... my declaration of success was premature.

It still has the same/similar problem, but it is obviously not as frequent or easily repeatable now. So maybe there is a similar mutex-protection that needs to be applied to another critical-section.

[sfhub]

Is it during login or later on? Are server and client same version? etc.

I could try to reproduce also if there are more details.

[nihartjones11]

It's in my first post, #20

[sfhub]

I have been using "Auto Select" best connection options and track mouse locally for a long time and could reproduce the crash at will for the longest time, but with the build above, none of my machines can reproduce the bug anymore (and I had a few that were real stalwarts)

1Gbps, 100Mbps, single core, dual core, etc.

Since you are still seeing the crash (infrequently) I'm trying to help isolate if there are any distinctive settings that might affect why you are still occasionally seeing it.

When you say "same/similar" problem, do you mean it is exactly the same symptoms or is it slightly different.

I tried immediately moving the mouse around before the full screen updated to try and induce the crash and no go.

[nihartjones11]

It acts the same (but much less frequently with this new build) as I described in my original post, and I am using all the same view-settings as described in that post. In fact, it is the only crash-scenario I have ever experienced, but then, I don't tinker with the viewer-settings outside of the initial setup. Here are the Connection Options that are shown after I'm already connected (using the 1.0.9.2 build that Rudi just posted the other day):

• Auto select best settings - of course this grays out most other selections
  
  Preemptive Updates is not checked
  
  Nothing in Misc Section is checked except that the grayed-out Share the Server is checked
  
  Mouse and Keyboard Section has Emulate 3 Buttons checked, and Track remote cursor locally selection. Mouse event throttle is set to 0.
  
  Display Section has Show Buttons Bar checked, all others unchecked, 100%, 1/1, and 0 reconnection attempts.

Also, when connecting to my LAN-machine running 1.0.8.2 UVNC Server, I use the -connect and -password options in the shortcut so I don't have to mess with a connection/password/login prompt... don't have security issues on my LAN. So basically, it's an instant-connect arrangement that I use. And since my LAN-machine has no monitor, it runs at only 1024x768 resolution so I don't need any scaling on my viewer. No command-line options are used other than the two mentioned.

Let me know if you need more settings/details, server or viewer.

Here's my 2-cents: Indeed, it does not happen every time, but as a software engineer with 30 years of embedded real time systems, I perceive the scenario to be related to the CPU/Memory Caches getting loaded with VNC-related instructions/data when you first execute the program. Upon initial execution, their are no cache-hits and everything has to be fetched from disk, and data has to be created in memory. If the viewer crashes, you tend to immediately reload it and do it again... this time a lot of stuff (especially the program instructions) are still in the caches and most cache-things will hit... the viewer starts up faster. The point is, the viewer's window-of-sensitivity to whatever is causing the crash-event will move in time from one execution iteration to the next, AND it will be different depending on the user's machine speed and resources. To me, there is some time-sensitive problematic hand-shake issue between server and viewer.

That might explain why I cannot reproduce the problem if I have just recently been using the viewer. I have to have been doing something unrelated to UVNC (gaming, word-processing, lots of web-browsing, etc.) essentially clearing out the CPU/Memory caches of all traces of VNC code/date, and then open the viewer to my LAN-machine, and move the mouse while it's in the process of opening... then I can usually get it to crash even with the 1.0.9.2 build. Immediately try again (while moving the mouse too) and it seems to work fine 100% of the time with the 1.0.9.2, but doing this successfully only a few times is hardly a declaration of finality. However, with 1.0.8.2, it would almost never work despite how many times I tried it, until I started leaving the mouse alone as viewer came up. I find that now, it's just habit.

So, 1.0.9.2 is better, but not quite there yet. Again, regardless of the build-version, if I don't touch the mouse during the connection process, it never crashes, even on first-use of the day.

I am happy to provide any further details if you need them. Good luck.

[Rudi De Vos]

The crash problem:
*It doesn happen in debug versions
*You need to run the release version to be able to crash
You only can import the dump, to analyse -> this is no real debugging
you only get minimal info. I try to crash the viewer for sevral hours... without luck.

I need to relay on your info

if I don't touch the mouse during the connection process, it never crashes, even on first-use of the day

This mean, it has to be some mouse function

restore background old mouse position
copy background new mouse position
place mouse


nihartjones11, can you easy crash the viewer ?
Does it offer to create a dump for sending to MS for analyse.

If i create a new viewer, release with symbol files, i should be able to
analyse the crash.... at least it tell me the accact spot in the code.
Are you willing to run some test ?