This thread was originally posted in November 2015 in sysnative.com/blogs. This has been moved over to the main forum as part of a software migration.
Note: Before I start, I should mention that this guide will not cover every aspect of a BSOD or every situation which can occur within a dump file, I feel this expectation should be addressed beforehand to inform you that BSOD debugging is a fairly complex and time consuming process. I will not promise that this guide this will solve your BSOD pandemic, nonetheless, it will give a solid understanding of how a BSOD works and how to provide useful debugging information to assist us within the debugging process.
1. Introduction – What is a BSOD?
A BSOD/BSoD (Blue Screen of Death) is a form of crash which occurs on the Windows operating system. A similar crash additionally occurs on Linux systems, and is known as a Kernel Panic. It is caused by an error within the Windows Kernel, an integral part of the operating system. The BSOD, is often misunderstood and tarnished as an hindrance to the user; true, this may be, but the BSOD is actually extremely useful to the user and the debugger. It provides notification to the user that a serious error has happened, and provides the option of enabling the debugger to investigate the problem and find the root cause. I’ve provided an example of the latest BSOD screen provided by Microsoft below:
By reading this guide, I hope you will gain a greater insight into the importance of a BSOD and thus a greater appreciation to how useful a BSOD can be when your system is experiencing problems.
1.1 Where do I locate the dump files?
Once you have experienced a BSOD, then hopefully a dump file will be created. A dump file is a snapshot of the system’s memory at the time of the crash. The dump file will have a file extension called .DMP, and there is three different dump file types which you should know:
The Kernel Memory Dump and the Full Memory Dump files are located in the following directory path:
These files can opened with a special debugging program called WinDbg (Windows Debugger). I will introduce WinDbg shortly, but please note that mastery of WinDbg takes time and great technical knowledge.
1.2 – How do I configure my dump file settings?
The dump file settings dictate the behavior of how Windows decides on which dump file type it should create, and the number of dump files which are created. The default settings will be suffice, since they create both a Minidump and a Kernel Memory Dump, although, if you have changed these settings in the past or someone else has changed the settings for you, then I will briefly show you how to reset the settings to default.
Windows Vista & Windows 7:
You will need to change the settings so they correspond to the values given in the image below:
I usually configure the settings so no existing Kernel Memory dump files are overwritten, this provides continuity when troubleshooting the issue at hand and more importantly means that no crashes are missed from being debugged.
Windows 8 & Windows 10:
The same instructions apply as with the Windows Vista and Windows 7 builds, the following has been added for consistency:
The dump file settings vary very slightly between Windows 8 and Windows 10, the first image is Windows 8 and the second image corresponds to Windows 10, I recommend you set the dump file settings to the settings shown in the two images accordingly:
Windows 8:
Windows 10:
2. Recommended Software – Which programs should I use to view the dump files?
There is a few programs which are able to view dump files, although, the industry standard is to use WinDbg since this program has been specifically developed by Microsoft to view dump files with. You may use BlueScreenView and WhoCrashed but those programs do not provide the amount of detail or depth which is required to accurately debug a BSOD.
In addition to WinDbg, the Sysnative BSOD Processing App may also be interest to anyone which wishes to have a quick and dirty analysis of several dump files.
2.1 How do I install WinDbg?
WinDbg is part of the SDK (Software Development Kit), the latest build of WinDbg is supported from Windows 7 to Windows 10; the build number is10.0.10240.9. You will need to select the Debugging Tools for Windows option – should be default – when using the SDK installation wizard, the most up to date download link can be found here – https://msdn.microsoft.com/en-us/win…/dn913721.aspx
Once you have successfully installed WinDbg, then you will to ensure that symbols have been configured to the Microsoft Public Symbol Server and the dump files have been associated to WinDbg. Please find the two necessary tutorials for configuring WinDbg correctly:
3. What are the common causes of BSODs and how can I prevent them?
BSODs are largely unpredictable and can be produced in a wide variety of circumstances, the purpose of this section is to outline some of the common causes of BSODs and enable you as the user to prevent BSODs from being produced to begin with.
3.1 Common Causes of BSODs
Cause: Outdated or incompatible device drivers
Prevention: It is vitally important to ensure that you have the latest drivers for your hardware devices, these updates provide compatibility and stability updates which help prevent drivers from malfunctioning. However, I highly recommend you do not use tools like DriverMax or similar programs to check for driver updates, these programs largely use outdated databases which contain false information and poorly written drivers. You use only update drivers from the official manufacturer page and check that the driver version you are installing corresponds to the device which uses it, fortunately some manufacturers provide an automatic detection tool which can find the correct drivers for you.
If you would like to find more information about a driver, then I would recommend using the Driver Reference Table (DRT) –Driver Reference Table (DRT)
Cause: Deletion or modification of important system files
Prevention: You should never delete or modify any system settings/files unless you have absolute certainty about the purpose of the said setting or file. There is immense amounts of bad advice on forums and blogs suggesting the modification of any system files or settings to “improve” performance and to prevent system crashes; much of this advice is unfounded and simply untrue. The Windows operating system is becoming increasingly more robust in terms of security and performance, there is no need to alter such settings unless there is good reason to do so. I would strongly suggest you do not installprograms which claim to be able to remove unused/unimportant files, remove registry keys for performance and improve system security with their scanning tools. The advice provided by helpers on Sysnative comes from many experienced experts who have great breadth of the Windows operating system and other areas of computing, please ask us if you have any questions about performance or security.
Cause: Malicious Software and lack of security
Prevention: Malware might not be a direct cause of BSODs in most cases, however, it can certainly help trigger BSODs by modifying system files and inviting other malicious software to corrupt the system. It is strongly advised to ensure that you install all important Windows Updates, update AV database definitions for programs such as Malwarebytes and remove any software which is known to have vulnerabilities. The most commonly exploited programs are:
To keep updated with new vulnerabilities and patch releases, then I suggest you our General Windows Information section –https://www.sysnative.com/forums/gene…d-information/
Cause: Poorly developed software, multiple AV programs and bloatware
Prevention: I’ve seen many poorly developed programs cause BSODs, and thus it is highly recommended that you install software which is reputable and take some considerable time researching the program before installation. This will also help to prevent malicious software from installed too. I would avoid software mirrors like Softpedia, CNET and FileHippo. Further to the above, you never run two real-time anti-virus programs one system, this leads to serious conflicts and crashes which usually result in a BSOD. Typically, it is recommended to have one real-time anti-virus program and several different on-demand scanners.
4. Common BSOD Misconceptions – What are they?
There is some very common misconceptions and myths surrounding BSODs and debugging BSODs. In this section I hope to address some of these issues and provide the correct answers.
For example, netio.sys may be blamed as the cause of the crash, although, since Microsoft system components are rarely the issue, we can assume that WinDbg isn’t revealing the true cause, and therefore will need to investigate further. On the other hand, netio.sys provides us with an indication that the crash was related to some networking aspect of the operating system, and thus we should begin to investigate any network adapter drivers or similar components.
5. Far and Beyond – Reference Material for Debugging BSODs
At Sysnative, we have written many useful tutorials which can be used to assist yourself with your debugging efforts, however, there is a few debugging blogs and websites which you may find useful.
Sysnative:
Sysnative BSOD Tutorial Index
Other:
Blogs:
6. Having BSOD Issues?
If you’re experiencing issues with BSODs or require any assistance with debugging your own, then please start a new thread in the BSOD, Crashes, Kernel Debugging section of our forum using the BSOD Posting Instructions.
Happy Debugging!
Note: Before I start, I should mention that this guide will not cover every aspect of a BSOD or every situation which can occur within a dump file, I feel this expectation should be addressed beforehand to inform you that BSOD debugging is a fairly complex and time consuming process. I will not promise that this guide this will solve your BSOD pandemic, nonetheless, it will give a solid understanding of how a BSOD works and how to provide useful debugging information to assist us within the debugging process.
1. Introduction – What is a BSOD?
A BSOD/BSoD (Blue Screen of Death) is a form of crash which occurs on the Windows operating system. A similar crash additionally occurs on Linux systems, and is known as a Kernel Panic. It is caused by an error within the Windows Kernel, an integral part of the operating system. The BSOD, is often misunderstood and tarnished as an hindrance to the user; true, this may be, but the BSOD is actually extremely useful to the user and the debugger. It provides notification to the user that a serious error has happened, and provides the option of enabling the debugger to investigate the problem and find the root cause. I’ve provided an example of the latest BSOD screen provided by Microsoft below:
By reading this guide, I hope you will gain a greater insight into the importance of a BSOD and thus a greater appreciation to how useful a BSOD can be when your system is experiencing problems.
1.1 Where do I locate the dump files?
Once you have experienced a BSOD, then hopefully a dump file will be created. A dump file is a snapshot of the system’s memory at the time of the crash. The dump file will have a file extension called .DMP, and there is three different dump file types which you should know:
- Minidump – this contains a snapshot of the Kernel address space at the time of the crash
- Kernel Memory dump – this contains the entire Kernel address space at the time of the crash
- Full Memory Dump – this contains the entire address space of the system at the time of the crash
Code:
%systemroot%\Minidump
Code:
%systemroot%\MEMORY.DMP1.2 – How do I configure my dump file settings?
The dump file settings dictate the behavior of how Windows decides on which dump file type it should create, and the number of dump files which are created. The default settings will be suffice, since they create both a Minidump and a Kernel Memory Dump, although, if you have changed these settings in the past or someone else has changed the settings for you, then I will briefly show you how to reset the settings to default.
Windows Vista & Windows 7:
- Open Computer (Start > Computer)
- Select System Properties
- Select Advanced System Settings
- Select Settings from Startup and Recovery (see image)
You will need to change the settings so they correspond to the values given in the image below:
I usually configure the settings so no existing Kernel Memory dump files are overwritten, this provides continuity when troubleshooting the issue at hand and more importantly means that no crashes are missed from being debugged.
Windows 8 & Windows 10:
The same instructions apply as with the Windows Vista and Windows 7 builds, the following has been added for consistency:
The dump file settings vary very slightly between Windows 8 and Windows 10, the first image is Windows 8 and the second image corresponds to Windows 10, I recommend you set the dump file settings to the settings shown in the two images accordingly:
Windows 8:
Windows 10:
2. Recommended Software – Which programs should I use to view the dump files?
There is a few programs which are able to view dump files, although, the industry standard is to use WinDbg since this program has been specifically developed by Microsoft to view dump files with. You may use BlueScreenView and WhoCrashed but those programs do not provide the amount of detail or depth which is required to accurately debug a BSOD.
In addition to WinDbg, the Sysnative BSOD Processing App may also be interest to anyone which wishes to have a quick and dirty analysis of several dump files.
2.1 How do I install WinDbg?
WinDbg is part of the SDK (Software Development Kit), the latest build of WinDbg is supported from Windows 7 to Windows 10; the build number is10.0.10240.9. You will need to select the Debugging Tools for Windows option – should be default – when using the SDK installation wizard, the most up to date download link can be found here – https://msdn.microsoft.com/en-us/win…/dn913721.aspx
Once you have successfully installed WinDbg, then you will to ensure that symbols have been configured to the Microsoft Public Symbol Server and the dump files have been associated to WinDbg. Please find the two necessary tutorials for configuring WinDbg correctly:
- Windows Kernel Debugging Setup + Windbg SYMBOL Setup
- Register Windbg for dump files (File Associations)
3. What are the common causes of BSODs and how can I prevent them?
BSODs are largely unpredictable and can be produced in a wide variety of circumstances, the purpose of this section is to outline some of the common causes of BSODs and enable you as the user to prevent BSODs from being produced to begin with.
3.1 Common Causes of BSODs
Cause: Outdated or incompatible device drivers
Prevention: It is vitally important to ensure that you have the latest drivers for your hardware devices, these updates provide compatibility and stability updates which help prevent drivers from malfunctioning. However, I highly recommend you do not use tools like DriverMax or similar programs to check for driver updates, these programs largely use outdated databases which contain false information and poorly written drivers. You use only update drivers from the official manufacturer page and check that the driver version you are installing corresponds to the device which uses it, fortunately some manufacturers provide an automatic detection tool which can find the correct drivers for you.
If you would like to find more information about a driver, then I would recommend using the Driver Reference Table (DRT) –Driver Reference Table (DRT)
Cause: Deletion or modification of important system files
Prevention: You should never delete or modify any system settings/files unless you have absolute certainty about the purpose of the said setting or file. There is immense amounts of bad advice on forums and blogs suggesting the modification of any system files or settings to “improve” performance and to prevent system crashes; much of this advice is unfounded and simply untrue. The Windows operating system is becoming increasingly more robust in terms of security and performance, there is no need to alter such settings unless there is good reason to do so. I would strongly suggest you do not installprograms which claim to be able to remove unused/unimportant files, remove registry keys for performance and improve system security with their scanning tools. The advice provided by helpers on Sysnative comes from many experienced experts who have great breadth of the Windows operating system and other areas of computing, please ask us if you have any questions about performance or security.
Cause: Malicious Software and lack of security
Prevention: Malware might not be a direct cause of BSODs in most cases, however, it can certainly help trigger BSODs by modifying system files and inviting other malicious software to corrupt the system. It is strongly advised to ensure that you install all important Windows Updates, update AV database definitions for programs such as Malwarebytes and remove any software which is known to have vulnerabilities. The most commonly exploited programs are:
- Adobe Flash Player
- Adobe PDF Reader
- Java Runtime
To keep updated with new vulnerabilities and patch releases, then I suggest you our General Windows Information section –https://www.sysnative.com/forums/gene…d-information/
Cause: Poorly developed software, multiple AV programs and bloatware
Prevention: I’ve seen many poorly developed programs cause BSODs, and thus it is highly recommended that you install software which is reputable and take some considerable time researching the program before installation. This will also help to prevent malicious software from installed too. I would avoid software mirrors like Softpedia, CNET and FileHippo. Further to the above, you never run two real-time anti-virus programs one system, this leads to serious conflicts and crashes which usually result in a BSOD. Typically, it is recommended to have one real-time anti-virus program and several different on-demand scanners.
4. Common BSOD Misconceptions – What are they?
There is some very common misconceptions and myths surrounding BSODs and debugging BSODs. In this section I hope to address some of these issues and provide the correct answers.
- Probably Caused by:
Code:
BugCheck 139, {21, fffff80060cda320, fffff80060cda278, 0}
*** WARNING: Unable to verify timestamp for Qcamain10x64.sys
*** ERROR: Module load completed but symbols could not be loaded for Qcamain10x64.sys
Probably caused by : Qcamain10x64.sys ( Qcamain10x64+1daf1 )- Last Running Process
Code:
{...}
CPU_COUNT: 8
CPU_MHZ: 9c3
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3c
CPU_STEPPING: 3
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: STACK_BUFFER_OVERRUN
PROCESS_NAME: System
{...}- !analyze -v
- Debugging is difficult/Debugging is easy
- Windows and BSODs
5. Far and Beyond – Reference Material for Debugging BSODs
At Sysnative, we have written many useful tutorials which can be used to assist yourself with your debugging efforts, however, there is a few debugging blogs and websites which you may find useful.
Sysnative:
Sysnative BSOD Tutorial Index
Other:
Blogs:
- Machines Can Think
- Debugging and Reverse Engineering
- bsoddebugging | Debugging and Mathematics
- OMG Debugging!
- ntdebugging | MSDN Blogs
- The Old New Thing | MSDN Blogs
- Nynaeve
6. Having BSOD Issues?
If you’re experiencing issues with BSODs or require any assistance with debugging your own, then please start a new thread in the BSOD, Crashes, Kernel Debugging section of our forum using the BSOD Posting Instructions.
Happy Debugging!