Debugging techniques

Jul 17, 2008 16:31 GMT  ·  By

Unfortunately for Microsoft, one of the aspects of its proprietary operating system that has grown to become associated by default with the Windows brand is the Blue Screen of Death. BSOD, for short, is the result of a critical system error that will stop the operating system dead in its tracks and lead to a reboot. In the NT corner of the universe, blue is by no means a welcomed color, and the BSOD even managed to span a cousin after the launch of Windows Vista. The Black Screen of Death was used to refer to systems thrown into Reduced Functionality Mode, scenarios far less severe than a critical system crash, of course depending on perspective.

The video embedded at the bottom of this article, courtesy of Channel 9, featuring Daniel Pearson, Windows Product Support Lead, deals with debugging a Windows Blue Screen of Death. For the average user the BSOD is nothing short of incomprehensible, but for Windows Support, as well as for developers and IT professionals, it represents an excellent resource to understand what went wrong and to resolve the cause of the critical error.

"The most common problem [and cause for Blue Screens of Death], is an unhandled exception in the device driver. Normally, in user mode you'll see these as an access violation. In Windows, because user mode processes are separated, if an application or process goes in access violation, it only takes out itself, it doesn't take out the rest of the operating system. In kernel mode, rules are completely different. So we have device driver running there, these are trusted components, they have access to the full address range, of the system," Pearson revealed.

The video features a complete demonstration of how to debug and diagnose a device driver unhandled exception which causes a BSOD. Of course, the content is aimed at professional performing debugging tasks, and not at the general public.

Daniel Pearson: Debugging a Windows Blue Screen of Death