Daniel Pearson: Debugging a Windows Blue Screen of Death

Posted By: Dan Fernandez | Jul 16th, 2008 @ 12:22 PM | 89,297 Views | 16 Comments
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.
Rating:
4
0
#Jul 16th, 2008 @ 2:02 PM
Chadk
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.
#Jul 16th, 2008 @ 3:08 PM
stevo_
stevo_
Human after all
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)?
#Jul 16th, 2008 @ 3:14 PM
Charles
Charles
Welcome Change
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
#Jul 16th, 2008 @ 4:16 PM
PerfectPhase
PerfectPhase
"This is not war, this is pest control!" - Dalek to Cyberman

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

#Jul 17th, 2008 @ 2:21 AM
karnokd
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.)
#Jul 17th, 2008 @ 2:45 AM
dot_tom
dot_tom
Hardcore! Smiley Nice to see some close to the metal stuff in with all the managed goodness. Helps keep us honest as developers Wink
#Jul 17th, 2008 @ 11:49 AM
stevo_
stevo_
Human after all

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

#Jul 18th, 2008 @ 5:17 AM
littleguru
littleguru
<3 Seattle
Probably you get a freeze. A complete halt with the most current video buffer re-drawn over and over again.
#Jul 18th, 2008 @ 11:08 AM
Charles
Charles
Welcome Change
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
Microsoft Communities