Blue screen with mirror driver

For feature requests and bug reports RC15 RC16. Please use the forum at http://forum.ultravnc.net/

I got a pretty reliable way to get a blue screen on my system. In short:
If I use a debug build of winvnc built with .NET 2002, the C++ runtime
detects a possible bug in the code. If I abort there, restarting the
server causes a blue screen, sooner or later. I assume that placing an
exit() statement at that location of the code would produce the same
results.

More details:
I use a custom built version of winvnc, based off 20.5 (tag) with minor
modifications and that I run as an application (not as a service). I
build using MS VisualStudio .NET 2002. When a client connects to the
server, I get a C++ runtime error, related to an unitialized variable in
the code (right or wrong).
If I chose to ignore the runtime error, I'll get more errors like this.
If I choose to abort, the server stops. If I restart the server (running
as an application, not as a service, just as before), I get a blue
screen, either immediately when the server is restarted, or later when a
connection is established. Sometimes, I have to repeat the server abort
once before it happens, but most of the time the server machine blue
screens quite fast after the server has been re-launched.
I speculate that the mirror driver is left in a "bad" state, and that
when the server is restarted, the server trying to use the driver causes
the blue screen.

One may say that I should either use a different compiler, or a release
build were the warning is absent. But I have seen blue screen issues
with release builds as well, in other words, without the artificial
abort of the server. I believe this procedure exposes a soft spot in the
server/driver architecture, where the server crashing leaves the driver
in a bad state where it will possibly blue screen the machine. And this
may be worth investigating considering that we have here a reproducable
blue screen...

Were this issue worries me, is that I have seen cases where the VNC
connection was lost due to a bad wireless connection. At that point, the
server was stuck and unable to reconnect with anything. Closing the
server could then cause a blue screen, but that scenario is much more
difficult to reproduce, though it happened to me in testing 5 times or
so. Maybe solving the reported issue will fix the other blue screens I
have seen but can't repro as easily?

My config:
- a PC running XP embedded, which is a stripped down version of XP Pro,
which should behave just as XP Pro in that case.
- The video is built-in my Intel D865GBF motherboard, using Intel
Extreme Graphics v6.14.10.3762 or 6.14.10.3943.
- the server is a private built, based on RC20.5, with minimal changes
to the source code. My guess is that a "pure" 20.5 would cause the
problem as well. But I can't test that easily.
- I use VNCViewer 1.0.20.6, that is, the binary available in
http://www.uvnc.com/RC206/

Any idea?
-georges




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click