As system admins we’ve all encountered a BSOD (Blue Screen Of Death) at least once during our careers, but I often find that the tools and techniques you can use to find out what actually caused a BSOD are not common knowledge for a lot of admins. So I thought I would make a quick video showing how easy it is to diagnose them in a lot of cases.
I tried to keep it short as the idea is to show that for the majority of BSODs it only takes a couple of minutes (if that) to find out which driver/component caused it, which then means you can search for updated versions or workarounds from the creators of that component and stop the BSOD from happening.
Here’s the video, I’d love to hear if it helped you out (you’ll need to watch in HD and full screen to be able to see the text clearly): http://vimeo.com/68497309
To download the tool used in the video (WinDbg) you need to download the Debugging Tools For Windows, from here: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx (you have to download the Windows SDK, then during installation just select to install the Debugging Tools only).
Let me know what you think
Thanks
Chris
Cjwdev 
Hi Chris,
Nice video – couple of points i wanted to make:
1. If you open a dump file in WinDBG, you need to stop debugging before you reopen a new one. Debug – Stop Debugging (or Shift F5) will allow you to open a new dump.
2. If you work for a company and they have a Microsoft Enterprise Agreement with MDOP, i strongly suggest using Diagnostics and Recovery Toolkit (DaRT). Its a wizard based tool that does exactly what you do, in about 10 seconds with no config or setup. Very handly but not everyone has access to it: http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/mdop/dart.aspx
3. As you have noted already, the symbol file path to use is: SRV*C:\Symbols*msdl.microsoft.com/download/symbols
Reading these memory dumps are easy once you know the simple steps. The moment you want to do more than this, you need experince to get useful information.
Cheers,
Ivan
Ah thanks for the tip about the stop debugging thing, I’ve never really needed to open another crash dump in the same session of the program before so I’d not come across that. I’ve also not heard of the DaRT before (probably because I’ve not worked anywhere that has had access to it), sounds quite handy and its a shame they don’t offer it to everyone.