Hangs and appcrash on Vista

[Steve_Messinger]

I've been using uvnc server on both Win7 and Vista for a while now.
It's been rock solid on Win7, but I frequently get what I'll call "hangs"
on Vista, and at least once I've gotten an "APPCRASH".

Thanks in advance for any pointers on known issues or suggestions for
avoiding problems.

The typical symptom is that the display from the Vista system freezes
and will not respond. It is necessary to close the viewer window and
restart the viewer session. Occasionally the window closes on its own,
with a message box indicating a loss of communication (although I do
not have the exact message available).

These "hangs" occur at seemingly random intervals, but it usually
happens within a half hour or so. It almost always happens while I
am NOT actively using the window - when the system has gone to its
idle mode screen saver (which I have set for 20 minutes). It does not
happen EVERY time it goes to the screen saver, though.

I have my system set to lock (go to the logon screen) when returning
from the screen saver, and it may be of interest that when it "hangs"
it almost always is showing the logon screen, not the screen saver
or the normal desktop.

It's not clear to me whether these are actually hangs, or just loss of
contact with the server. However, usually running vncviewer again
restores the connection with no trouble. The APPCRASH that I've
included below is the only one that I remember getting.

I'm not familiar with what error logging or debug capability may be
available with uvnc, so pointers in that direction would be welcome.

More about my setup:

I'm running "VNC Viewer Free Edition 4.1.1 for X" on a Linux 2.6.18
system, with servers on Windows XP, Windows Vista and Windows 7.

On Windows XP, it is "VNC Server Free Edition 4.1.3", but on Vista
and Win7 it is 1.0.9.5.

My Vista is at Service Pack 2, with all patches applied, running on a
32-bit Intel Core2 Duo T9600 2.8GHz system with 4G of RAM, connected
to a corporate intranet.

I'm not sure what uvnc properties are important to report --

In the "Properties" page I have Poll Full Screen (Ultra Fast), Poll
ForegroundWindow and Poll Window Under Cursor checked (and nothing
else).

In the "Admin Properties" page, I have Accept Socket Connections,
Auto port selection, Enable JavaViewer, Do Nothing When Last Client
Disconnects, Disconnect all existing connections for Multi viewer,
Remove Aero, Remove Wallpaper for Viewers, Capture Alpha-Blending,
Enable and User impersonation for File Transfer.

I do run the server as a service so I can log in remotely after booting
(and I have User Account Control turned off).

Problem signature:
Problem Event Name: APPCRASH
Application Name: WinVNC.exe
Application Version: 1.0.9.5
Application Timestamp: 4cf10cba
Fault Module Name: WinVNC.exe
Fault Module Version: 1.0.9.5
Fault Module Timestamp: 4cf10cba
Exception Code: c0000005
Exception Offset: 000aa6fb
OS Version: 6.0.6002.2.2.0.256.4
Locale ID: 1033
Additional Information 1: 01fe
Additional Information 2: 881ee3c1a8d743972005e1655fdc1fdd
Additional Information 3: 9f99
Additional Information 4: 2283c3b95f03786a97721620e4603cf8

Thanks again.

[Steve_Messinger]

Ok - silly me. I finally realized that there is an option in the Admin
Properties to log debug infos.

I turned on the debug printing and see some interesting things, but I
don't know how to interpret them.

For example, here's what looks like a sequence ending in a disconnect:

Wed Dec 22 10:34:52 2010
vncservice.cpp : threadname, inputname differ
vncclient.cpp : vncClientThread
vncservice.cpp : SelectDesktop
vncservice.cpp : OpenInputdesktop2 NULL
vncservice.cpp : OpenInputdesktop2 OK
vncservice.cpp : SelectHDESK to Winlogon (304) from 2c0
vncservice.cpp : threadname, inputname differ
--Invalid window handle.
vncservice.cpp : threadname, inputname differ
vncservice.cpp : threadname, inputname differ
vncdesktopthread.cpp : ++++InputDesktopSelected
vncservice.cpp : threadname, inputname differ
vncdesktopthread.cpp : m_desktop->Shutdownvncdesktopsink.cpp : ShutdownInitWindowthread
vncservice.cpp : SelectHDESK to Winlogon (2c) from 290
vncdesktop.cpp : delete ((RGBPixelList)
vncdesktop.cpp : delete ((RGBPixelList)
vncdesktop.cpp : delete ((RGBPixelList)

[... etc. skip a bunch of stuff ...]

Wed Dec 22 10:35:08 2010
vncdesktopsink.cpp : OOOOOOOOOOOO 49453 2034396
Wed Dec 22 10:35:09 2010
vncservice.cpp : SelectHDESK to Winlogon (2c) from 304
--An established connection was aborted by the software in your host machine.
vncclient.cpp : client disconnected : 15.62.80.224 (1)
vncclient.cpp : disable update thread
vncclient.cpp : enable/disable synced
vncclient.cpp : kill update thread
vncclient.cpp : stopping update thread
client sent 18356 updates
vncclient.cpp : update thread gone
vncserver.cpp : removing authorised client
vncserver.cpp : deleting desktop server
vncdesktop.cpp : ~vncDesktop
vncdesktopsink.cpp : ~vncDesktop::Tell initwindowthread to close
vncdesktopsink.cpp : OOOOOOOOOOOO 18 0
vncdesktopsink.cpp : OOOOOOOOOOOO called wm_quit
vncdesktopsink.cpp : WM_DESTROY
vncdesktopthread.cpp : quitting desktop server thread
vncdesktopthread.cpp : quitting desktop server thread:SetBlockInputState
vncdesktopthread.cpp : quitting desktop server thread:ClearShiftKeys
vncdesktopthread.cpp : quitting desktop server thread:g_DesktopThread_running=false
--The system cannot find the file specified.
vncdesktopsink.cpp : ShutdownInitWindowthread
vncdesktopsink.cpp : OOOOOOOOOOOO end dispatch


I don't see how to determine what caused the server to close the
connection, or how to avoid it.

Any suggestions?

[Rudi De Vos]

It's hard to see what's actual happening, some guesses.

1) screensaver modify resolution
2) session switch

To be able to support Vista>= winvnc most be running in the console session. In case the console session switch, winvnc restart himself and try to reconnect to the viewer. The uvnc viewer wait for reconnect and continue.

Normal the screensaver and winlogon should happen in the same session
as the desktop unless you are using multiple users.. then the winlogon
sometimes happen in another session -> winvnc restart


If possible, check if it also happen with the ultravnc viewer, possible
the reconnect trick we use cause other viewers to wait forever...

[redge]

Steve_Messinger

your network is only wired, right ? (no wireless for computer tested)
could you, please, try ssvnc viewer for linux more aware feature of ultravnc
http://www.karlrunge.com/x11vnc/ssvnc.html


do you use anything special on vnc server on Vista that not available on win7 except the settings you wrote

your issue solved since last post of Rudi ?

You could improve speedup ticking adding System HookDll
what the version if in use of SCHook.dll ? it should be 1.0.0.3

crash only happen if vnc is in use or with any application without active vnc connection ?

[Steve_Messinger]

Rudi and Redge -

Thank you for the replies. I'm in the middle of a holiday break at work,
so I won't be able to check out the suggestions for a few days.

I'll get back to you then.

[redge]

you should try ssvnc 1.29 with uvnc 1.0.9.5 and above

[Steve_Messinger]

Sorry for the long delay. I'll try to respond to some of the earlier comments.

For your message, Rudi:

> To be able to support Vista>= winvnc most be running in the console
> session. In case the console session switch, winvnc restart himself and
> try to reconnect to the viewer. The uvnc viewer wait for reconnect and
> continue.

I am running uvnc server (winvnc) as a service and have User Account
Control turned off so that I can log in remotely after booting. Does
that answer the question? I don't have a good grasp on what the
console session is or how it would switch.

> Normal the screensaver and winlogon should happen in the same
> session as the desktop unless you are using multiple users.. then the
> winlogon sometimes happen in another session -> winvnc restart

The screen saver generally seems to work ok - it will go to the screen
saver and allow me to go back to the regular display without problem
most of the time. (I do have it set to lock the display after the screen
saver exits.)

There are two users defined on the computer - the one I normally use
authenticates on the corporate network. The other defined user is
for local login on the computer. I never log in as the other user.
Does that resolve the question of whether there might be another
session involved? How would I know?


> If possible, check if it also happen with the ultravnc viewer, possible
> the reconnect trick we use cause other viewers to wait forever...

I did try connecting from my Windows 7 system to the Vista system,
using the uvnc 1.9.5 viewer there. I do get the same type of problem,
where the server seems to disconnect, leaving the window frozen on
the screen. It is necessary to close the viewer window and reconnect.


For your comments, Redge:

> your network is only wired, right ? (no wireless for computer tested)

Correct, in this environment it is just wired. The computers are
connected to a small 8-port router, which in turn is connected to the
corporate network.

> could you, please, try ssvnc viewer for linux more aware feature of
> ultravnc http://www.karlrunge.com/x11vnc/ssvnc.html

Instead of trying a different viewer on the linux system, I used the
Windows7 system to run the uvnc 1.0.9.5 viewer (as mentioned above),
and I still see the problem there.

> do you use anything special on vnc server on Vista that not available
> on win7 except the settings you wrote

I don't think so. I could provide a screenshot of the properties
windows if that would help.

> your issue solved since last post of Rudi ?

No, the problem isn't resolved.

> You could improve speedup ticking adding System HookDll

I will try that. I don't necessarily understand the benefits and
risks of the various update options.

> what the version if in use of SCHook.dll ? it should be 1.0.0.3

Interesting - on the Vista system schook.dll is version 1.0.0.3, but
on the Win7 system it is 1.0.0.1. I'm not sure how that happened.
(The Win7 system is 64-bit - does that explain it?)

> crash only happen if vnc is in use or with any application without
> active vnc connection ?

I only saw the appcrash once. In all other cases it has just been the
uvnc server on Vista apparently dropping the connection, requiring me
to close the viewer window and log in again.

Thanks again for the comments.

I'll let you know if enabling the system hook dll makes a difference.

--
Steve

[Steve_Messinger]

I just got a second APPCRASH on the Vista system:

Problem signature:
Problem Event Name: APPCRASH
Application Name: WinVNC.exe
Application Version: 1.0.9.5
Application Timestamp: 4cf10cba
Fault Module Name: StackHash_069a
Fault Module Version: 6.0.6002.18005
Fault Module Timestamp: 49e03821
Exception Code: c0000374
Exception Offset: 000afaf8
OS Version: 6.0.6002.2.2.0.256.4
Locale ID: 1033
Additional Information 1: 069a
Additional Information 2: 522a67a972acfb7527f34be981885752
Additional Information 3: b68b
Additional Information 4: 550725044ace8fdf1866057ca1d3bf50


Note that this did not kill the server. I was able to just log in again from
the other system. This happened when using the old non-uvnc viewer
on Linux.

[redge]

Steve_Messinger

remote desktop connection enabled and running with ultravnc as service ?

please
can you do a memory test like memtest 4.10
isolate problem of memory or test hard drive full disk in case of bad sectors where located ultravnc for example

good test ready to use and boot on CD
www.ultimatebootcd.com

I hope you won't have cad.exe on ultravnc folder with uvnc 1.0.9.5
you need sas.dll for vista installed with setup.

[Rudi De Vos]

That crash info isn't usable...

To be able to analyse the crash data, a special winvnc version is needed
and the crash need to generate a dump.
This dump can be imported by us to analyse the data.

Something is wrong... but seems to manifest himself only when special conditions are met...

When you run winvnc as service, it can survive a crash.
Winvnc (application part) is restarted by the service.

1) Is the user a domain or local user ?
Don't understand exact what the "other user is"

There are reports that domain users can block.

winvnc running as service start the application part as the current
desktop user... But if the domain settings prevent the service ( local system) to impersonate that user ( permission denied) winvnc app part can't be started -> lock

[averkiev]

That crash info isn't usable...

Actually it's. It's posssible to map crash address to a function that crashed using MAP file.

http://support.microsoft.com/kb/196755

[Rudi De Vos]

When you create a release exe, you also generate a symbol file.
If this release crash, you can import the dump and it show the functions and vars at time of the crash...
You can replay the dump almost like a normal debug run

But this implement that you need to keep a full compiled subtree for
each compilation you make, because as soon as you change a bit and
recompile, the corresponding symbols file are not longer valid.

This mean i need to make a copy of the sourcetree at a save spot,
compile it at that location and keep the 1GB obj and other files...

I never used the mapp stuff, but unless you have the corresponding
symbol files it will also fail i guess...i realy need to function parameters
( knowing that a memcpy failed doesn't give me a lot of info)

[Steve_Messinger]

Redge:

> remote desktop connection enabled and running with ultravnc as
> service ?

I'm not really sure what you are asking, but yes, the UltraVNC server is
running as a service on my Vista machine.

> can you do a memory test like memtest 4.10
> isolate problem of memory or test hard drive full disk in case of bad
> sectors where located ultravnc for example
>
> good test ready to use and boot on CD
> www.ultimatebootcd.com

I'll try to run a memtest when I can.


> I hope you won't have cad.exe on ultravnc folder with uvnc 1.0.9.5

Oops - I *DO* have a "cad.exe" file in the Program Files/UltraVNC
folder. Is that bad? Should I delete it?

> you need sas.dll for vista installed with setup.

I do have a sas.dll file in the UltraVNC folder -- does that count as
"installed with setup"??


Thanks for the help.

--
Steve

[Steve_Messinger]

Rudi:

> To be able to analyse the crash data, a special winvnc version is needed
> and the crash need to generate a dump.

I would be glad to run an instrumented version of winvnc if that would
help resolve the problem.


> Something is wrong... but seems to manifest himself only when special > conditions are met...

I have only seen the appcrash a couple of times. However it very
frequently does the thing where it seems to drop a connection, requiring
me to reconnect from the viewer.


> 1) Is the user a domain or local user ?
> Don't understand exact what the "other user is"

I have two users defined on my Vista system. One is a domain user,
which is what I always use. The other is a local user and I never log in
as that user.

> There are reports that domain users can block.
>
> winvnc running as service start the application part as the current
> desktop user... But if the domain settings prevent the service ( local
> system) to impersonate that user ( permission denied) winvnc app part
> can't be started -> lock

I don't know how to interpret this comment. All I can say is that it
works great to log in and work with. But anytime it sits idle for an
extended period it will eventually drop the connection and I have to
exit the viewer and log in again.

(Plus the couple of times it got the appcrash)

Thanks again.

--
Steve

[Rudi De Vos]

[post=83242][/post]

This version is saved to be able to analyse crash dumps

[Steve_Messinger]

Rudi:


> [post=83242][/post]
>
> This version is saved to be able to analyse crash dumps


Ok - I followed the link and downloaded the winvnc10951h files to my
Vista machine. (It was painful - the McAfee system intrusion protection
that corporate mandates kept preventing me from unpacking the zip
file. I had to disable it.)

Then stopped the service, I moved the 1.0.9.5 version of winvnc.exe out
of the way, moved the 1.0.9.5.1 version of winvnc.exe into the Program
Files\UltraVNC folder, and started the service again.

-- First problem: when trying run the old "standard" vncviewer on my
Linux system, I had trouble with the screen refresh. It is running on
a system with a restricted colormap, so it always starts with a "bad"
colormap, then blanks the window and redraws it with a new colormap.
With the 1.0.9.5.1 winvnc, it blanks the window but never redraws it,
so I end up with a black screen. Fortunately, I can also run the
viewer from my Windows 7 machine.

-- On my Windows 7 system, I ran the 1.0.9.5 version of vncviewer.
(Is that what you wanted? Or do I need to run the 1.0.9.5.1 version
of vncviewer also?)

-- That seems to work about as before. It works ok for a while, but
eventually the connection closes spontaneously. So far it has not
caused another appcrash from the 1.0.9.5.1 winvnc on the Vista
machine.

So, is there anything useful that I can do? Do I need to run the
1.0.9.5.1 version of vncviewer? Do I need to wait for the appcrash to
get a crash dump? (And where do I find the crash dump? In the
Program Files\UltraVNC folder?) Should I be worried about the cad.exe
file that Redge mentioned?

Thanks again for your expertise.

--
Steve

[redge]

So, is there anything useful that I can do? Do I need to run the
1.0.9.5.1 version of vncviewer?

Yes

Do I need to wait for the appcrash to
get a crash dump? (And where do I find the crash dump?

yes

Should I be worried about the cad.exe
file that Redge mentioned?

No. but better to remove cad.exe, anyway file is ignored if sas.dll exist on the folder of ultravnc on vista computer.

did you set properly the winvnc polling ?
set like 7
[post=83158][/post]

[Rudi De Vos]

On Vista, when a application crash, the OS generate a dump
and ask if you want it to send to Microsoft for analysing.

The popup have an option " details" or "more info" that show what files
are being send. It are this files we need...

If you send them to Microsoft it can take a long time ( possible they wait until some the number hits some trigger) before they notify us.
Also, it looks like they only do it for the latest OS ( win7 win 2008).

[Steve_Messinger]

Rudi and Redge:

After switching to the instrumented build, I didn't get any more crashes
for a few days. That's not surprising, since I only got a few crashes
in the first place.

However, uvnc is now unusable with my old 4.1.1 viewer because it
never redraws the screen to update the colormap - it just paints the
window black and leaves it there.

Even running the same build of the uvnc vncviewer 1.0.9.5.1 on the
Windows 7 computer to view the Vista system, the connection dies
frequently, with the loss of connection problem.

Since this is on my systems at work, I can't afford to spend so much
time with computer problems. I can't spend the time to restart the
connection every time I want to access the Vista computer.

Therefore I decided to try and alternative. I found that the current
version of TightVNC works great. I ran all day yesterday with NO
loss of connection, and it even stayed up all night.

I'm afraid that I'll need to abandon the effort to get UltraVNC to work
with my Vista system. I had no trouble with uvnc on the Windows 7
computer, but that's not enough.

I would be willing to try a brief experiment or test some code if you
need some help, but for now I need to just get on with my work.

Thanks again.

--
Steve