Not all Blue Screens are crashes!?!?
BruteForce
My workstation crashed today when someone plug in a new camera, so I
got myself involved in identifying what was the cause of that. I
usually don't run tests or do debugging on my workstation so I was
pretty bewildered with what happened.
So I analyzed the crash dump that my machine generated and guess what
happened? The camera did something wildly illegal and the debug version
of UB1394.SYS that runs on my machine thought of letting me know with a
debug breakpoint that I had coded years ago.
However my machine was not booted with /DEBUG so I ended up with the
infamous Blue Screen Of Death. If I had /DEBUG in my boot configuration
then my machine would just freeze and wait for the debugger to connect.
Had I booted that way, I would connect with WinDbg from my test PC and
resume execution without crashing. You could do that too you know.
Don't get me wrong here; I love BSODs. BSODs are a blessing from God.
That's because BSODs are just so easy to fix. You should love BSODs
too, at least those that come from the ubCore drivers and especially
those that are easily reproducible.
It is the slow and painful death of the OS that you should be afraid
of. When my code does something wrong and the OS does not crash
immediately then I have no idea what might have gone wrong, when and
where.
Thank God, I get those very very rarely! This is one of those cases:
http://groups.google.gr/group/FireAPI/browse_thread/thread/1d9046de8be090fa/2d93f30a54c4d135#2d93f30a54c4d135
Anyway, a BSOD caused by a breakpoint is not necessarily evil. The code
that we write has several "sanity" checks that do just that; Check
for things that violate the rules. Like an ack_complete acknowledge to
a read transaction request.
All the above mean that whenever you want to try things out with the
debug version of the drivers, you better boot your machine with the
/DEBUG option. Windows XP and 2003 have a nice tool for editing
BOOT.INI. It's called BOOTCFG.EXE.
The debug version of UBOHCI.SYS is heavily into debug breakpoints,
because we really want to get immediately informed when the hardware
goes awry. So when you use that, you are bound to get several
breakpoints hit.
The release versions of the drivers are not supposed to have hardcoded
breakpoints, but no one is perfect, so don't get too surprised if
that happens. You can check if a SYS executable you are using is using
debug breakpoints by using the Dependency Walker
(http://www.dependencywalker.com).
Open up the SYS with DEPENDS.EXE (drag'n'drop works fine) and on the
left pane locate and click on NTOSKRNL.EXE. On the right pane you will
see a list of functions that the SYS is importing from the NT Kernel
(the items with the green box containing a capital C letter). These are
usually alphabetically sorted. If you see DbgBreakPoint in the list
then this SYS has hardcoded breakpoints.
However a device driver can do breakpoints without calling
DbgBreakPoint on x86 machines. There are several ways to do it and they
don't end up calling DbgBreakPoint, so you can't see it on
Dependency Walker.
To the best of my knowledge the release build of ubCore drivers does
not contain embedded breakpoints.
How can you identify that your BSOD is caused by a breakpoint in the
driver?
The BugCheck code is 1000008E (on Windows 2003 at least).
This is what WinDbg has to say about this situation:
=================================================
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address
pinpoints the driver/function that caused the problem. Always note
this address as well as the link date of the driver/image that contains
this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never
have hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the system is
booted /DEBUG. This will let us see why this breakpoint is happening.
=================================================
Dimitris Staikos
Unibrain
BruteForce
is a "bug". Now it is documented someplace, but the user has no idea
about it and the BSOD can't tell the user "Hey pal, don't worry this is
a documented crash"!
Since it is my principle to make a feature out of every "bug", even if
it is a documented behavior, we will soon update ubCore 5.x so that
these debug breakpoints are by default inactive and only get enabled if
the user enters the appropriate registry entries with UBTWEAK.
I'll keep you posted when this becomes available.
Dimitris Staikos
Unibrain