Many IT professionals and developers are surprised to find out that A BSOD doesn't "just happen" but is the result of an intentional call from a kernel level programmer to a system call. There is nothing coincidental or surprising in a BSOD.
There are two system calls used to create a BSOD: KeBugCheck and KeBugCheckEx (surprisingly enough these calls don’t return any value).
The purpose of these calls is to shut down the computer as fast as possible leaving enough evidence to enable you to get the precise state of the operating system at the time of the call. Considering the purpose of the call, you can conclude that if you got a blue screen then the call functioned according to the specification and it's actually solid proof that your computer is functioning properly.
There are many reasons for calling these subroutines and they are all documented in the WDK and WinDbg documentation. The common denominator of all these calls, is when a kernel programmer discovers a problem, which is so critical, that leaving the operating system running in this state, might cause critical damage to the system or to the data. In this case, all that's left to do is to push the red button, activate the air bags and halt the system ASAP.
This strategy is called "falling to a safe place" and is used by everyone dealing with emergencies. It's the ABC of mitigation and contingency planning.
This year I am going to attend WinHec 2007, I decided, it’s about time to go and learn what's new in the Windows Internals/Windows Device Driver development arena.
The introduction of WDF to the Device Driver Development world has had the same revolutionary effect as the introduction of MFC had on the traditional C++ programming world (for good and for bad).
Things have changed a lot in the old WDM DDK world with the introduction of WDK and WDF and there isn't a better place to get the information than WinHec.
C U there.