John Carrona - BSOD analyst

I have the Knack: sound byte here

"How I do it" - BSOD analysis for Users RSS Feed Subscribe to the RSS feed Last updated:  23 Jan 2013
Added check for BIOS date in systeminfo.txt

I originally posted this link for how to do BSOD troubleshooting for users:
I've changed a lot of things that I do over the last few years and decided to have a completely new page describing the steps that I take.

First, I get the reports from the jcgriff2 app posted here:
Things are a bit different over at Microsoft Answers, but I'm starting to ask for the above info there also.

I immediately start the memory dumps running, as they take the longest.  If there are no memory dumps we've gotta start looking for causes (see,, and Windows Internals, Chapter 13 and 14

I next look at the perfmon /report.  I look for Errors, Warnings, and Information that might apply to the current situation.

I next look at systeminfo.txt.  I check SP level, installation date, amount of memory used and available (both RAM and Virtual Memory), BIOS date, Windows Updates (number on the system), and the networking devices (mostly looking for USB networking devices in Win7).

Next I look at MSINFO32.  If it's corrupted I will ask for the text version (the xml version isn't very easy to read).
- System Summary - I look for Service Pack level and generally check the amount of memory and how much is being used.

- Components...Network...Adapter - here I look for different adapters that may be causing issues (USB devices in Win7, other network devices installed by software programs)
- Components...Storage...Drives - here I check to see how much free space is available on each drive
- Components...Storage...Disks - here I look for hard drive type (?SSD) and how full the hdd is/are
- Components...Problem Devices - here I look for any problem devices

- Software Environment...Windows Error Reporting - here I look for errors that might indicate problems.  Also I look for patterns in the BSOD's displayed here.  This is a good place to check for BSOD's if there are no memory dumps in the uploaded files
- Software Environment...Startup Programs - I look here for known problem programs starting with Windows
- Software Environment...Program Groups - I look here for known problem programs that are installed.
- Other sections of the MSINFO32 report are used as they become necessary.

Then I look at the memory dumps (more info on WinDbg here: ):
- first I look to see what drivers are present that aren't in the Driver Reference Table
- then I look to see if there's any pattern to the memory dumps (BSOD error codes and causes blamed)
- then I look to see if there's any other patterns in select information from the memory dumps
- I also check to see if there's older BIOS and overclocking (if the memory dump provides that info)
- I also determine if there's sufficient cause to believe that Driver Verifier may provide more info.

Then I check the drivers.
- I rule out the Windows drivers
- I rule out drivers from 2009 or later (except for security software and video drivers) (for Win7 - older OS's required different date adjustments)
- I check for any known problem drivers
- I also look for patterns in the 3rd party drivers that showed up in the memory dumps
- if all that doesn't work, then I start on updating the 2009 drivers

Somewhere in here I may run Driver Verifier to rule out 3rd party drivers

If all the 3rd party drivers have been accounted for/ruled out - then it's gotta be either hardware or Windows.
Hardware errors are generally random, while Windows errors should refer to the same problem over and over.
At that point I either begin hardware testing
Or I start throwing the few Windows tools at the problems.

More info on the details of this in the BSOD How-To for Users page ( ) and the Hardware Stripdown Troubleshooting page ( )

© 2017 - John D. Carrona
Forum screen name: usasma