Daniel Pearson: Debugging a Windows Blue Screen of Death

Posted By: Dan Fernandez | Jul 16th, 2008 @ 12:22 PM | 85,615 Views | 16 Comments

Formats:

Daniel goes through the four key reasons why BSODs happen, how Windows allocates memory and how developers need to be careful when setting kernel mode memory. Daniel then goes through a real-world example of a faulty device driver and how to debug and diagnose issues. Daniel also shows how to read and write data to an application process, like Notepad using WinDbg.

Tags: Debugging, Windows

Rating:

Chadk
excuse me - do you has a flavor?

This is awesome. I would love to see much more like this.

It was interesting how to see how you could find information from the memory dump.

stevo_
Maim that tune

I was just wondering today, what would happen if the 'code' that handles the bsod.. crashed? like, what if my processor was on last legs and caused an execution fault?

Let me guess, something really boring like everything going blank, or my computer restarting (or not)?

Charles
Welcome Change

In reply to stevo_

#Jul 16th, 2008 @ 3:08 PM

I've had something like this happen to my machine twice in the last two days. There's some sort of kernel crash that causes the system to reboot - with no telemetry whatsoever. Certainly a critical system failure, but the system is unable to record any data before restarting.

C

PerfectPhase
"This is not war, this is pest control!" - Dalek to Cyberman

In reply to Chadk

#Jul 16th, 2008 @ 2:02 PM

If this sort of thing is of intreast to you, this is a must see Sysinternals Video Library

karnokd

Nice video. However, I never understood why there aren't any minidump created in case the swap file is moved to a differend partition/hard disk in WinXP? (In my case, I play 3D games and the videocard driver sometimes crashes my system and I cannot hope to send that crash dump to its manufacturer.)

dot_tom

Hardcore!

Nice to see some close to the metal stuff in with all the managed goodness. Helps keep us honest as developers Wink

stevo_
Maim that tune

In reply to Charles

#Jul 16th, 2008 @ 3:14 PM

That doesn't sound good charles Wink .. I was interested because.. if theres no one "there" ie, the kernel itself doing its bugcheck code has crashed out due to a hardware fault.. does my system just sit there... I assume I'd still have display because the gpu would just be outputting the last buffer it was given?

But I've watched the video now, really cool, loved the idea of trapping a driver by putting it on a "known offenders" list, and luring into doing something it will get caught red handed for.. Big Smile

littleguru
summer time! aperol spritz dreaming...

In reply to stevo_

#Jul 17th, 2008 @ 11:49 AM

Probably you get a freeze. A complete halt with the most current video buffer re-drawn over and over again.

Charles
Welcome Change

In reply to littleguru

#Jul 18th, 2008 @ 5:17 AM

Unhandled exceptions in kernel mode lead to reboot by policy (or if you're lucky a bluescreen with data capture for debugging purposes). Anytime something goes wrong in kernel world the system must commit temporary suicide (or start the reincarnation process, to be more positive in tone Smiley

). There's too much weird and invalid state to deal with when this happens and typically and it's not worth it (the insuing instability and total strangeness that user mode gets to experience as a result)...

This keeps happening on my machine and there's no way for me to debug given that no data on the fault is preserved (or even captured). Clearly, it's a device driver malfunction. I suspect it's a driver that's not Vista Ready... Smiley

What's one to do in this case, Daniel?
C