Windows 8 Connection Freeze using u2 encoding

[plants]

Hi Rudi,
I've been using UltraVNC to assist clients for some time now, and now increasingly with Windows 8, so I feel quite confident about my findings (I used to work in software development, and a bug-finder at heart!)

I've developed my own 'Single-Click'-style application - inspired by early AutoIt3 efforts, and have been gradually perfecting it for stability. It naturally uses winvnc.exe in a reverse server connection to locate my listening client vncviewer.exe

One thing it does, is not use the reconnect feature built into UVNC, as I've found in the past I cannot rely on it completely. Thus, my application monitors the winvnc application's memory usage and 'infers' the state of the connection based on changes in memory usage, and is thus able to terminate and relaunch winvnc based on obvious criteria such as internet connection drops, crashes and lockups, changes in IP, etc.

Memory usage varies fairly dramatically when a UVNC is listening and when connection is established; the client's monitor resolution, the various applications they may be running that 'hook' themselves onto all launched applications and the video encoding method chosen by UVNC are all influencing factors in memory consumption

Nevertheless, I've been able to write some logic that is capable of distinguishing between connection states with complete reliability and so, finally, I would like to report my findings

If the connection between myself and the client is good, UVNC will choose the u2 encoding method. In the instance that the client is using Windows 8 and the encoding is u2, after a short while (varying between 1-5 minutes) the viewer will lock up and the server continues to exhibit normal memory consumption - therefore my application doesn't report anything out of the ordinary, but my connection to the client is irrevocably lost, even after restarting my viewer

I hope I've been sufficiently clear in my report; I've tried various combinations of this scenario with different operating system but the only determinants are Windows 8 and the u2 encoding method (but remember, UVNC's autoreconnect is not active)

I am using the very latest 1.1.9.0 (1.1.8.9 was really unstable, especially with Win8, as I'm sure you're aware!)

Thank you for your time and for coding such an awesome RD client and server
Tiziano

[Rudi De Vos]

Anything special to repeat it.
Whats on the screen, some apps to generate date or just a static screen?
Are you using the w8hook?
Keeps the cpu high while it freeze or just some deathlock ( threads keep waitin forever)

Repeating a bug in a developer environment is 80% solving a bug.

[plants]

Nothing special as far as I'm concerned - do you mean if there are any exotic modules attached to all processes?

All the supporting binaries are current and correct to my knowledge (if you could declare which of schook, vnchooks or w8hook should be present for what systems and what their dates should be, that would be really helpful!, as schook hasn't been included in the installation packs for a while now

In answer to your query: in the Win8 client's case, all three of those dlls are present
It is a deadlock in the viewer I believe - no CPU usage but the process window is not responsive (the mouse pointer turns into a busy timer when hovered over the window - using WinXP)

I have been assisting a client with Vista x86 and I've had similar but not consistent problems. In their case, the connection drops quite regularly (could be their internet, but it is too regular - is it possible that the server is dynamically changing encoding preference after a set time, which leads to a significant memory usage drop (identical to a connection loss), which then causes my wrapper to terminate and restart the server?

After one of these drops, but not consistently, the viewer locks up in an identical way to the Win8 scenario

Thanks for your help
T

[Rudi De Vos]

I just wanted to know what's running on the screen ( pixel changes). Vnc doesn't know what's running
it just transmit rectangles of pixels.The screen can be static or change a lot ( like when you have a small video running).
Sometimes bugs only happen on staic screens... while other require a lot of changes

w8hook is win8 only, it use the desktop duplication engine ( new in win8 for wddm 2.1).
If the w8hook.dll is in the winvnc folder it's using it. At least when you have the new (2.1) win8 video drivers.
This is a new part for win8 only, possible this can introduce new bugs, but when it also happen on Vista it has to be
soemthing else.

If it's a viewer deadlock you should be able to kill the viewer ( taskmgr) and restart it.
After thr restart the connection is back OK ?

It isn't the server, but the viewer that change encodings.
The auto encoding change is only possible when "auto mode" is selected. When you manual select
a mode or encoder it's fix for the session. If the speed is just on a encoder boundery and auto is selected
it can behave bad. Please test with selecting a fixed encoder to exclude/include the encoder switching as cause.

[plants]

Hi Rudi, thank you for the explanations, most informative

I mentioned modules that hook onto processes because there are certain window rendering (e.g.: Styler for WinXP) or explorer shell extensions that are present in every process, even winvnc (I use Process Hacker 2 for debugging). As UVNC is clearly concerned with window dimensions / positions, in terms of rendering efficiency, I thought you meant there could have been a connection between these unusual modules and corruption in transmission of the data to the viewer!

In answer to your question, the screens are mostly static; just a desktop and the occasional windows opened by me (console included)

I am always able to kill the viewer, explorer offers to 'End Now' when I click close, but I have a script to launch the viewer that kills all vncviewer processes before starting a new one. That seems to be 100% effective. The viewer then resumes as normal, but again dies in the same way shortly after

I had a long session with Vista the other night which was very frustrating, because it kept freezing all the time, in the manner described, but at least I was able to test every combination of viewer behaviour, as you've suggested (I often switch to 'Tight' encoding with Quality 0-2 and zip compression unchecked)

The most stable connection I found was with ZRLE

I have another example for you to consider, which happened repeatedly over the course of 3 hours:

As you know, my server 'wrapper' application kills and restarts the server when a significant memory usage drop occurs. I had the viewer fixed to ZRLE

On a regular basis, every 2-5 minutes, the wrapper would detect a memory drop in the server, thus terminating and restarting. The viewer would not close that connection however; a window to the previous (dead) session would remain for several minutes while a new active window continued to function normally. Given sufficiently frequent drops, there could be as many as 3 'ghost' connections (stalled child processes, I guess) running concurrently. These could be closed manually, they were not deadlocked as far as the system was concerned, and they would disappear on their own after a while

A note on termination: when my wrapper terminates the server, it uses the 'graceful terminate' feature built into the server (winvnc -kill) and definitely waits until both processes (the original server and the server kill process) have unloaded. There is no way there are more than one server running at the same time, which I'm confident of because AutoIT3 seems completely reliable and watching the behaviour with a task manager proves this to be true. This seems to me the most friendly way to handle the server, because it gives it the opportunity to inform the viewer that it is closing, restore the desktop wallpaper, etc. Correct me if I'm wrong though!

Sorry for all the exhaustive detail, but I think it's necessary! I get the feeling the viewer is the one with issues...
Again, thank you for all your help so far and I continue to hope that my contributions are of value to you

T

[Rudi De Vos]

Can you fast check
device manager ->network adapters->..->powermanagment.
Exclude the power save mode for the network adaptor.

I had just an inssue while testing something on a fresh installed win7, each time the screensaver jumped in
my network closed...and natural the client server app closed.

[Rudi De Vos]

Is winvnc running at service level ?
Does your sc wrapper start it at service level, or as a standard user.
( Do you see the red rectangles when you ctrl-alt-del on the server)

[Rudi De Vos]

winvnc.exe -kill proper close the server, but viewer stay open.
This is the normal behaviour unless you set the viewer option "reconnect attempts" = 0

First test: connected for 30 minutes using u2 ( win7), all stay connected no connection break.

win8:

[plants]

I just had a Vista -> XP session that lasted maybe 4 hours without a single drop. ZRLE and u2 both completely stable. Why? Because it was via ethernet cable
That said, I did have infrequent instances of grey patches covering various amounts of the screen, but the connection was rock solid, the response speed fast and consistent (350+ kbits)

I had suspected something with the power-saving of the wifi adapter, but I did not know if it would make any difference - I had tried different settings in the past, but without documentation from the manufacturer, it's hard to guess whether some of the parameters would have an effect on transmission quality. Thank you for finding and reporting that!

winvnc is running as application. I was unaware that a reverse connection could be made at the service level. Cool!

So, shall we assume that intermittent connection problems are due to poor signalling on WLAN. Is there any kind of buffering in place on the viewer side that may compensate for inconsistent throughput?

Thanks again Rudi, this is progress for sure
T

[Prisma]

Why don't you run the viewer in Visual Studio to find the loop or deadlock? I'm not a big C programmer too. But that's not necessary for finding a deadlock or loop. It would be enough to point Rudi to the code segment causing the lock.

[plants]

Well, I can quite conclusively say that an Ethernet connection eliminates any of the problems encountered with a wireless connection. Even a wireless connection very close and in a direct and unbroken line with a router can be problematic

Naturally, the permutations of testing scenarios in this regard tend to infinity and thus clearly impractical to undertake without proper debugging kit! I do have several laptops with different hardware and lots of different clients with an equally diverse range of hardware and Windows OS's, so I will endeavour to narrow down the possibilities and report my findings, but I am going to concentrate on WiFi connections

If I'm to be an effective tester, I'd need some idea of the variables involved. Some questions:
Could wireless packet sizes be significant? Packets are normally broken at 2346, should I try a specific value or range?
What degree of resilience to inconsistent or broken throughput does the viewer have in this particular scenario?
What sorts of conversations do the server and viewer have in a reverse connection that make them distinct from regular, client-initiated connections (these problems never manifest themselves over a regular connection using the same hardware / software)?
Has the logic for the handling of incoming data changed over the last few revisions - to lead us closer to the nature of the problem?
Can the viewer be forced to emit useful debugging info?
Would I not need source code and all relevant libraries to debug in Visual Studio?

I'm more than happy to take this on myself if someone would throw me a bone!
T

BTW: Up until recently I'd kept to using defaults as much as possible, however now I'm trying different viewer parameters too. Currently I'm using:
/listen 5511 /dsmplugin SecureVNCPlugin.dsm /encoding zrle /autoscaling /reconnectcounter 0 /autoreconnect 2 /autoacceptnodsm /autoacceptincoming /notoolbar /disablesponsor
Note: specifying an encoding does nothing, but I believe a QuickOption does, however it's not clear what number corresponds to which encoding

[Rudi De Vos]

The max packet size is 1452 or the congestion window size if we can read the tcp value.

Does the Wifi stay on ?
If the viewer freeze, can you still ping another server or the router ip.
Can you fast test this ?
If possible run it simultanious on the server site, to see if that site stay on.

[plants]

Hi Rudi,
I'm sorry for the reply delay. You've clearly been busy again!

I've not had a chance to test the Wifi scenario, as I've been using an ethernet connection exclusively, however it is still true to say that if the server is behind a router that has poor wifi reception or poor internet bandwidth, or simply the majority of the outgoing bandwidth is being used by another process (e.g.: cloud storage sync) the viewer frequently locks up and sometimes has to be terminated by force

During a lock-up the viewer does not produce a CPU spike or displays any other measurable activity
I'm still using 1.1.9.0, will upgrade soon...
T