Daniel Pearson: Debugging a Windows Blue Screen of Death

Posted By: Dan Fernandez | Jul 16th @ 12:22 PM

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:

Views (66,298)

Comments (18)

Downloads

Chadk

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_

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

In reply to stevo_

#Jul 16th @ 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

In reply to Chadk

#Jul 16th @ 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_

In reply to Charles

#Jul 16th @ 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