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:
- 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
The directory in which the Mindumps are stored is:
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:
- 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 is
10.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:
Symbol files have the
.pdb file extension and used by WinDbg to translate memory addresses and structures in memory to meaningful text which a human could understand. More Information on Symbol Files, I would suggest reading the following article –
Symbol Files (Windows)
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
Most websites now support HTML 5 and therefore Flash Player is no longer needed at all; there are many open source alternatives to Adobe Reader and the Java runtime (if needed) can be disabled from running in your browser, thereby preventing any malicious applets from being run.
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.
The common problem I often notice when people first begin to debug, that they assume that the “Probably caused by:” is absolutely correct and points directly to the exact cause of the BSOD. In some circumstances this is true, however, often this often not the case since the “Probably caused by:” line tends to point to either a Microsoft system file or the last module which called in the stack. The “Probably caused by:” provides a rough indication of the cause and helps to provide some context.
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 )
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.
Another common misconception I often see, and this is similar to the first issue, is that beginners often assume that the last running process is possibly the process which caused the system to crash, while again, this may be true it is not often the case. The last running process simply indicates the last active process at the time of the crash, it can in some cases be useful, but usually is something which can be ignored.
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
{...}
I have seen many tutorials and blogs state that
!analyze -v is the definite output which WinDbg produces, and this extension will provide you with all the answers to debugging a BSOD. The !analyze -v extension is designed to give a quick summary analysis of the crash, such as the call stack, bugcheck parameters and some general hardware information (Windows 10 WinDbg builds). It is good practice to delve deeper into BSODs to gather as much information as you can about the system, although, there are numerous debugging commands/extensions you will learn these with time.
- Debugging is difficult/Debugging is easy
There is some truth in this, but debugging isn’t as difficult to learn if you have some patience and dedication. It can be tiresome and laborious task to learn C, x86-x64 Assembly and operating system architecture, but once you have mastered these topics then debugging can become a fun process. On the other hand, I have also seen the opposite, many users believe – mostly from ignorance – that debugging is something which doesn’t take a long time and can be learned within a few weeks; this simply isn’t the case, and the reason why many have started but do not finish.
A large number of BSODs are caused by third-party drivers and malicious software. I often see many blogs accuse Windows of being unstable and prone to producing BSODs due to poor development; this is simply untrue, nonfactual and non-existent. Only a small number of BSODs are produced by Windows itself, and these bugs are usually reported and resolved quickly by Microsoft via Windows Update. As stated beforehand, a vast majority of these bugs are caused by third-party drivers, a list of common BSOD-related drivers is provided here –
https://www.sysnative.com/drivers/bsod_drivers.php
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:
Other Websites:
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!
