How to Diagnose BSODs (Blue Screen)

[ionbasa]

How to Diagnose BSODs (Blue Screen)

 

 

 
Introduction:
BSODs appear when Microsoft Windows encounters a critical error it can’t recover from, requiring a reboot and possibly resulting in lost work. A BSOD is the result of low-level software crashing — or faulty hardware. BSODs are rarely caused by Windows itself unless the operating system files were tampered and altered by malware. Some malware can even purposely cause BSODs. Blue screens are thus usually caused by hardware problems and / or issues with low-level software running in the Windows kernel possibly because of drivers. A blue screen occurs when Windows encounters a “STOP Error.” This critical failure causes Windows to crash and stop working. When a blue screen occurs, Windows automatically creates a minidump file that contains information about the crash and saves it to your disk.

 

---

Forum Specific Instructions for the Troubleshooting Sub-Forum:
If you are encountering BSODs and are asking for help in the troubleshooting sub forum here in LTT, there are some things we need you to do to help us help you!
First, we need the dump files produced by Windows at the time of the blue screen. The dump files contain information about what possibly caused the BSOD and also contains debugging information.
 
To obtain these file(s) follow the procedure below:
First, begin by listing the following information:

· OS - Windows 8.1, 8, 7, Vista ?· x86 (32-bit) or x64 ?· What OS was originaly installed on the system?· Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from a retailer)?· Age of system (hardware)· Age of OS installation - have you re-installed the OS?· CPU model· Video Card model· MotherBoard - (if NOT a laptop)· Power Supply - brand & wattage (if laptop, skip this)· System Manufacturer · Exact model number (if OEM or laptop)· Laptop or Desktop?

Next, choose your preferred method below:

The following "tool" (Sysnative BSOD Dump + System File Collection App) is not my own, nor does it have any association with LTT or the LTT STAFF. Therefore it has to marked as an UNOFFICIAL LTT app.

Method A has been adapted by myself (@ionbasa) from the Sysnative forum thread here: http://www.sysnative.com/forums/bsod-crashes-kernel-debugging/68-blue-screen-of-death-bsod-posting-instructions-windows-10-8-1-8-7-vista.html

 

The tool is working property of Sysnative and its authors:

jcgriff2 - J. C. Griffith, Microsoft MVP
TheOutcaste - Jerry Wines
Patrick - Patrick Barker, Microsoft MVP
niemiro - Richard
Tekno Venus - Stephen
©  http://www.sysnative.com/
©  sysnative.com - MVP
© 2008 - 2014 sysnative.com
New Jersey, USA; Oregon, USA; New York, USA
ALL RIGHTS RESERVED

 

If you have any objections to using the aforementioned app, there are instructions below on how to alternatively grab the needed files manually.

1. Download the Sysnative BSOD Dump + System File Collection App here: http://www.sysnative.com/apps/SysnativeBSODCollectionApp.exe
2. Run the app - Double-click on the downloaded application file. Give the application ample time to collect the necessary files and system information, this may take up to 10-15 minutes, please be patient! Here is a screenshot showing the utility in action:
   • ​​​
3. Once the tool finishes, bring up an elevated administrative CMD prompt:
   • Windows 7 & Vista - START | type cmd.exe into the start search box | right-click on cmd.exe | select "Run as Administrator"
   • Windows 8.1 & 8 - Press WIN +X keys | select "Command Prompt (Admin)"
4. Run the following command: 

   perfmon /report

5. This should bring up the Resource and Performance Monitor, as follows:
   • ​​​​
6. Once PERFMON has finished collecting data for 60 seconds, save the output by selecting: File | Save As | Save as: (Report Files) HTML
7. Zip up the PERFMON output; create a new thread HERE.
8. Unfortunately, the forum currently forbids that .zip files be uploaded to your post. Therefore an alternate method has to be used to share your two zip files. You will have to use an online file service such as: Dropbox, Mega, OneDrive, Google Drive, etc. to share your two zip files. In your post, include a link to the two zip files.

NOTE:

The app auto-zips the SysnativeFileCollectionApp output folder. It is located in your Documents folder. Windows Explorer should open and highlight the zipped folder.
Please do not modify the output files! 

 

INFO:

The Sysnative BSOD Dump + System File Collection App does not get installed (it is a stand-alone EXE) nor does it make any changes to the registry. It only creates the SysnativeFileCollectionApp output folder + a zipped version - both located in Documents folder. You can delete them at any time, but we suggest that you wait until our work together is completed before doing so.

This Method involves manually copying the dump files.

1. Start by opening Explorer
2. In the address bar at the top, enter the following folder structure: "%SystemRoot%\Minidump\".
   • You should see one or more dump files. If there are none, or the folder cannot be found, then a dump file was not created when Windows blue screened.
3. Select all the dump files and copy them.
4. Create a new zip folder on the Desktop and paste the dump files in the zipped folder.
   • NOTE: You cannot move the files nor can you use the context menu to "send to zip' or 'send to desktop'! The files have to be manually coppied over.
5. Next, bring up an elevated administrative CMD prompt:
   • Windows 7 & Vista - START | type cmd.exe into the start search box | right-click on cmd.exe | select "Run as Administrator"
   • Windows 8.1 & 8 - Press WIN +X keys | select "Command Prompt (Admin)"
6. Run the following command: 

   perfmon /report

7. This should bring up the Resource and Performance Monitor, as follows:​​​​
   • ​​
8. Once PERFMON has finished collecting data for 60 seconds, save the output by selecting: File | Save As | Save as: (Report Files) HTML
9. Zip up the PERFMON output; create a new thread HERE.
10. Unfortunately, the forum currently forbids that .zip files be uploaded to your post. Therefore an alternate method has to be used to share your two zip files. You will have to use an online file service such as: Dropbox, Mega, OneDrive, Google Drive, etc. to share your two zip files. In your post, include a link to the two zip files.

---

There are 4 types of dump file: A Small Memory Dump, a Kernel Memory Dump, a Complete Memory Dump, and a Automatic Memory Dump (Windows 8+).

1. A Small Memory Dump has the following properties:
   • The Stop message, its parameters and other data
   • A list of loaded drivers
   • The processor context (PRCB) for the processor that stopped
   • The process information and kernel context (EPROCESS) for the process that stopped
   • The process information and kernel context (ETHREAD) for the thread that stopped
   • The Kernel-mode call stack for the thread that stopped
   • A Small Memory Dump is exactly 64 KB in size, and requires only 64 KB of pagefile space on the boot drive. This kind of dump file can be useful when space is greatly limited. However, due to the limited amount of information included, errors that were not directly caused by the thread executing at time of crash may not be discovered.
   • The bug check message and parameters, as well as other blue-screen data.
   • The processor context (PRCB) for the processor that crashed.
   • The process information and kernel context (EPROCESS) for the process that crashed.
   • The thread information and kernel context (ETHREAD) for the thread that crashed.
   • The kernel-mode call stack for the thread that crashed. If this is longer than 16 KB, only the topmost 16 KB will be included.
   • A list of loaded drivers.
   • A list of loaded modules and unloaded modules.
   • The debugger data block. This contains basic debugging information about the system.
   • Any additional memory pages that Windows identifies as being useful in debugging failures. This includes the data pages that the registers were pointing to when the crash occurred, and other pages specifically requested by the faulting component.
   • The Windows SKU -- for example, "Professional" or "Server".
2. A Kernel Memory Dump contains all the memory in use by the kernel at the time of the crash. This dump file will not include: unallocated memory, or any memory allocated to user-mode applications. For most purposes, this crash dump is the most useful. It is significantly smaller than the Complete Memory Dump, but it only omits those portions of memory that are unlikely to have been involved in the crash.
3. A Complete Memory Dump is the largest kernel-mode dump file. This file includes all of the physical memory that is used by Windows. A complete memory dump does not, by default, include physical memory that is used by the platform firmware. This dump file requires a pagefile on your boot drive that is at least as large as your system memory; it should be able to hold a file whose size equals your entire RAM plus 1 Mb.
   • Note: If a second bug check occurs and another Complete Memory Dump (or Kernel Memory Dump) is created, the previous file will be overwritten.
4. An Automatic Memory Dump contains the same information as a Kernel Memory Dump. The difference between the two is not in the dump file itself, but in the way that Windows sets the size of the system paging file.The Automatic Memory Dump file is written to "%SystemRoot%\Memory.dmp" by default. The Automatic Memory Dump is available in Windows 8 and later.

Small Memory Dump files are written in the directory "%SystemRoot%\Minidump\". The dump file should have a similar syntax to: "mini022900-01.dmp". Any additional minidump files created will be given a unique name, which contains the date of the crash in the file name. The previous file will be preserved.

 

The Kernel Memory Dump file is written to "%SystemRoot%\Memory.dmp" by default. If a second bug check occurs and another Kernel Memory Dump (or Complete Memory Dump) is created, the previous file will be overwritten.

 

The Complete Memory Dump file is written to "%SystemRoot%\Memory.dmp" by default. If a second bug check occurs and another Complete Memory Dump (or Kernel Memory Dump) is created, the previous file will be overwritten.

 

The Automatic Memory Dump file is written to "%SystemRoot%\Memory.dmp" by default. If a second bug check occurs and another Automatic Memory Dump is created, the previous file will be overwritten.

To configure the type of dump file to be created on a BSOD:

1. Press the "Win" and the "R" keys at the same time - then type in "sysdm.cpl" (without the quotes) and press Enter
2. Click the Advanced tab, and then click Settings under "Startup and Recovery"
   • ​​
3. Optionally, you may want that "Automatically restart" is unchecked
   • ​
4. Then continue below:

1. Under the Write Debugging Information header choose: "Small memory dump (### kB)"
2. Ensure that the Small Dump Directory is listed as "%systemroot%\Minidump" (without the quotes)
3. Click OK twice to exit the dialog boxes, then reboot for the changes to take effect

 

1. Under the Write Debugging Information header choose: "Kernel memory dump"
2. Ensure that the Dump Directory is listed as "%systemroot%\Memory.dmp" (without the quotes)
3. Click OK twice to exit the dialog boxes, then reboot for the changes to take effect

 

1. Under the Write Debugging Information header choose: "Kernel memory dump"
2. Ensure that the Dump Directory is listed as "%systemroot%\Memory.dmp" (without the quotes)
3. Click OK twice to exit the dialog boxes, then reboot for the changes to take effect

 

1. Under the Write Debugging Information header choose: "Automatic memory dump".
2. Ensure that the Dump Directory is listed as "%systemroot%\Memory.dmp" (without the quotes).
3. Click OK twice to exit the dialog boxes, then reboot for the changes to take effect.

1. Start by downloading the Windows SDK from: http://msdn.microsoft.com/en-US/windows/desktop/bg162891
2. Accept the default install directory, unless you want to install to another drive or directory.
   • ​​
3. During the install, select the Debugging Tools for Windows box and clear all the other boxes.
   • ​
4. Once installed run the following command in an Elevated Command Prompt to associate files to the Windows Debugger.  For 64 bit systems: 

5. "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\windbg.exe" -IA

    For 32 bit systems: 
   

   "C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\windbg.exe" -IA

   Note: "-IA" is case sensitive.
   • ​
6. Create a folder on the root of your "C:\" drive, or another drive.
7. Start Windbg, you can find it in the start menu under: All Programs > Windows Kits > Debugging Tools for x64 > WinDBG (x64). The go to File > Symbol file path, and copy/paste: 
   

   SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

   and then click ok. Note: Replace "c:\symbols" with the path of the directory you created earlier.
   • ​
8. Save your setting by clicking: File > Save Workspace
9. Exit. Now all dump files will be associated with the Windows Debugger. Just double click a dump file to open it in WinDbg.

After opening a dump file your screen should look similar:

• If a driver or program is the cause of the BSODs, it will usually show up in the Probably Caused By line.
• You can research offending drivers here: http://sysnative.com/drivers/
• To get a list of running drivers when the BSOD happened, execute the following in WinBbg: 
  

  lmntsm

• To display the Stop error code, aka bug check code, and its parameters, execute the following in WinBbg: 
  

  !analyze -show

• To display a verbose output, execute the following in WinBbg: 
  

  !analyze -v

  PROCESS_NAME shows which process was running at the time of the crash, but not enough to jump to conclusions. FAILURE_BUCKET_ID and BUCKET ID can sometimes reveal culprit drivers that are not blamed in the Probably Caused By line.
• To find out information about the motherboard and OEM, execute the following in WinBbg: 
  

  !sysinfo machineid

• To see all available comands for reserching system information, run the following in WinDbg: 
  

  !sysinfo

The rest is usually taking the output from the aforementioned commands and just using logic and Google. You'd be amazed at what you can find out could be the culprit to the BSODs.
 
Also use http://www.carrona.org/bsodindx.html as a reference on what usually causes BSODs and what each STOP code means.

1. Open WinDbg and go to Help and then Contents.
   • ​
2. Expand Debugger Reference, and then expand the Debugger Commands.
   • ​​
3. Expand General Extension Commands and Kernel-Mode Extension Commands, and then click which command/extension you would like to view for detailed information about that extension/command.
   • ​​​​

• If a Windows/system driver is blamed, it's most likely not the real problem. Maybe if 'tcpip.sys' is blamed, perhaps the network adapter drivers are at fault?
• If 'Verifier_Enabled' dumps continue to point to system drivers, unstable hardware is likely the culprit. The most common cause is due to RAM and CPU overclocking, followed by: motherboard, PSU, video card, and storage drives can cause issues if memory is not being properly allocated, or unstable drivers are used.
• If your computer cannot boot normally you may be able to get the files by booting into safe mode.
• If you are overclocking (pushing the components beyond their design) you should revert to default at least until the crashing is solved.

 

Relevant Videos:

This video in specific can show you how to use the event log in general to diagnose a BSOD. Wendel also lightly touches on WinDbg, and how to quickly check a dump file. While this video doesn't cover everything on the event log, it does help novices get started into debugging. 

 

http://carrona.org/
http://support.microsoft.com/kb/254649
http://support.microsoft.com/kb/315263
http://support.kaspersky.com/1771

Add 3rd party BSOD analysis tools
Using the Event Viewer to debug problems
Scanning for malware
Purposefully cause a BSOD to be used in debugging
Using Driver verifier to capture at fault 3rd party drivers
Add video tutorials
Add advanced commands to be used in WinDbg

 
Please leave any comments and feedback on what you would want to see.

[piplupgao]

Pretty useful but it usually isn't hard to guess the cause

[ionbasa]

Pretty useful but it usually isn't hard to guess the cause

Sometimes errors could be more intricate, and guessing doesn't solve the problem.

 

An example I can provide is that at my intern job, an windows server kept crashing, even after clean re-installs of the OS. And everything passed on Memtest86++. It turned out to be the actual memory controller on the motherboard was dying. We wouldn't have figured that out without the WinDbg tool.

[meneervent]

Pretty useful but it usually isn't hard to guess the cause

It is very usefull to know the cause of the BSOD, imagine you are overclocking and are having some faulty software that keeps BSODing. Not very pleasant to assume it is the overclock don't you think?

[piplupgao]

It is very usefull to know the cause of the BSOD, imagine you are overclocking and are having some faulty software that keeps BSODing. Not very pleasant to assume it is the overclock don't you think?

As far as my experiences go all my BSODs have been easily diagnosed sure there are some exceptions, but I imagine most BSODs are caused by things like over clocking or a virus or something similar.

[Guest]

Props!!

It learned something new and now I am no more guessing what causes the BSOD

Thanks

[ionbasa]

Props!!

It learned something new and now I am no more guessing what causes the BSOD

Thanks

No problem. Glad I could shed some light on the dreaded blues screens.

[ttam]

Easiest thing to do - Download "WhoCrashed"

Run it, scan. And it tells you what the cause was.

Takes 2 minutes.

[ionbasa]

Easiest thing to do - Download "WhoCrashed"

Run it, scan. And it tells you what the cause was.

Takes 2 minutes.

Yes, although that type of tool would be for the "novice". With the Windows Debugger there are a plethora of commands someone can run. From checking the bios/acpi tables to even checking the cpu speed/model/ microcode. You can also know what type of memory module is used on an actual DIMM of memory.

 

WinDbd isn't meant for a quick and dirty approach to looking at the "Possibly Caused by xxxx driver" as even that is sometimes wrong, why? Because sometimes system drivers or files could be corrupted by some malware, leaving behind false positives to purposefully trick people that something else caused the crash.

 

Here is another counterpoint to that program: What if it tells you that the kernel caused the crash. That almost never happens in real life. Most of the time it is other bad drivers that cause a kernel to crash.

 

Don't get me wrong it's a neat utility, but it isn't meant for the advanced power users who needs to troubleshoot others problems remotely.

[colonel_mortis]

http://msdn.microsoft.com/en-us/library/hh994433%28v=vs.85%29.aspx is a good resource for more details on different stop codes.

When I'm feeling in a helpful mood and try to solve some of the BSODs on the troubleshooting section, I generally do !analyse -v (you can just click it) and it often has enough information there to suggest the cause to a reasonable degree. eg. a recent post had a whole load of WHEA_UNCORRECTABLE_HARDWARE_ERRORs with the failure bucket ID of intel processor cache so it is a fairly reasonable assumption to make that it's either a bad cpu or overclock. You can also get a whole variety of memory-related errors, which all suggest that the ram is at fault.

Just how I do debugging, but the commands in this post will make it a lot easier to pin down the cause in the more obscure cases.

[JustAGuy]

Good Guide 

[ttam]

Yes, although that type of tool would be for the "novice". With the Windows Debugger there are a plethora of commands someone can run. From checking the bios/acpi tables to even checking the cpu speed/model/ microcode. You can also know what type of memory module is used on an actual DIMM of memory.

 

WinDbd isn't meant for a quick and dirty approach to looking at the "Possibly Caused by xxxx driver" as even that is sometimes wrong, why? Because sometimes system drivers or files could be corrupted by some malware, leaving behind false positives to purposefully trick people that something else caused the crash.

 

Here is another counterpoint to that program: What if it tells you that the kernel caused the crash. That almost never happens in real life. Most of the time it is other bad drivers that cause a kernel to crash.

 

Don't get me wrong it's a neat utility, but it isn't meant for the advanced power users who needs to troubleshoot others problems remotely.

As an advanced user (and someone who has spent 6 years running his own shop) I've dealt with a lot of bsod's.

 

The program does tell you exactly what the cause was and with the 5000 or so computers that have hit my shop this past year, it's worked well for all my techs and myself

[ionbasa]

As an advanced user (and someone who has spent 6 years running his own shop) I've dealt with a lot of bsod's.

 

The program does tell you exactly what the cause was and with the 5000 or so computers that have hit my shop this past year, it's worked well for all my techs and myself

I'm not saying it is bad product. If it worked you you, great. I just like using the original tool MS lets devs. and coders, and bug-fixers use. Also I will agree with you that 99% of the time a 3rd party tool can be good. But as someone who sometimes needs the advanced functionality, it can be limiting.

 

Also, this guide is a WIP. I am going to take a look at the program in depth, and ill make sure to add it to the 3rd party tools section which is coming soon.

 

Also check out this other utility that you may like: http://www.osronline.com/page.cfm?name=analyze

It is provided by OSR Online, probably one of the better windows driver development websites out on the net. I highly recommend them.

[Mistgrim]

Thanks for this, will come in handy

[ionbasa]

Thanks for this, will come in handy

No problem. More content is slated to come on Friday.

[ygohome]

awesome.  My dad's workstation laptop sometimes blue screens about once a month or so.  Next time it happens I'll follow this guide.

[ionbasa]

Added instructions on how to configure specific dump types.

 

Next I might add some video tutorials on how to use the MD debugging tools, that is if I can find some that are fairly good and accurate.

[MG2R]

Thanks for this, it will serve useful to lots of people! I'm keeping this one bookmarked for later reference.

 

EDIT: would it be possible to change the blue you use for BSODs to another shade of blue, this one, for example? The current shade is VERY hard to read for night theme users.

[ionbasa]

Thanks for this, it will serve useful to lots of people! I'm keeping this one bookmarked for later reference.

 

EDIT: would it be possible to change the blue you use for BSODs to another shade of blue, this one, for example? The current shade is VERY hard to read for night theme users.

Done, forgot about night users, sorry. 

[MG2R]

Done, forgot about night users, sorry. 

No biggie, thanks!

[Jaybird]

Why is this not pinned? Any who I discovered my problem but i have yet to find a solution to the problem. Thanks for the post.

[ionbasa]

Why is this not pinned? Any who I discovered my problem but i have yet to find a solution to the problem. Thanks for the post.

If you send me the dump file I can try to see what the issue could be. Most of the time I find that unstable OCs causes software to crash erratically.

[Jaybird]

If you send me the dump file I can try to see what the issue could be. Most of the time I find that unstable OCs causes software to crash erratically.

I have already created a thread. I am at work right now so I can not share the file at the moment. but I have listed some data already. cpu is overclocked to 4.2 using asus boost. but ive been running that for over several months. Ill also post a history report when I get home. 

 

http://linustechtips.com/main/topic/138214-bsod-help-needed/

[cesrai]

Thanks, great topic m8, I apprci8 the effort.

[ionbasa]

Just wanted to mention that some changes have been made in the OP. In specific:

• Added a relevant videos subsection, and added one of Wendel's videos on the event log. 
• Fixed formatting issues, made text automatic in color.
• Added forum specific instructions for posting dump files.
• Added information on the "automatic memory dump' option present in Windows 8+.
• Added some more screenshots under some subsections.
• Added a 'more commands and extensions' subsection.

There will definitely be more to come. I just need to sift through my never ending bookmarks of useful resources. As always, I hope this helps anyone who wants to try and troubleshoot or help others here on the forum.