Blue Screens of Death
How to diagnose and fix blue screens, in laymens terms.
So you're in the middle of a match. Your army is maxed, you're sitting on 3 bases, you've just taken out your opponents third, a big chunk of his army, and you are about to march into his base and collect your victory. All of sudden, your screen flickers, turns blue, and barfs a bunch of code in your face. You have just encountered...
THE BLUE SCREEN OF DEATH.
Why did this happen? What does this mean? Why is your computer assaulting you with strings of letters and numbers?
You have just encountered what we call a STOP code. The computer has detected a problem from which it cannot recover, and therefore must restart.
The Blue Screen of Death (also known as the BSOD) is a screen that Windows shows you when it shuts down your computer in order to prevent damage to it. It's also known as a STOP error or as a BugCheck Code. It is a hardware error by definition - but this doesn't mean that it's caused by faulty hardware. Viruses, corrupt drivers, and even poorly written programs can cause it.
Let's take a second to analyze what's on the screen. Please note, if the screen only stays at the STOP screen for a few seconds before rebooting, go to Control Panel > System & Security > System > Advanced System Properties > Startup and Recovery Settings > untick "Automatically restart".
Anatomy of a Blue Screen of Death
+ Show Spoiler +
A note on shorthand; A STOP 0x0000007a error is referred to (in shorthand) as a STOP 0x7a error. It's just a way of not having to write all them zero's out each time that you refer to it.
These types of errors generally happen because of two things*;
1. Driver issues
2. Viruses/Malware
3. Hardware Issues
*These are not the sole reasons for a blue screen, but in my experience are the most common.
Driver Issues
Drivers are a set of instructions you feed your computer that tell your computer how to talk to the devices you have installed. For example, your video card speaks Japanese, and your processor speaks Spanish. A driver tells both the devices how to speak english. If there is a problem with the driver, both the video card and CPU hit a language barrier, and if the computer can't find a way around it, you get a STOP code.
Memory Issues
Memory is the middle man between the hard drive and the processor. All the programs that you have opened are loaded into the memory. If we think of it in terms of a human head, the hard drive represents your memories, the processor represents the prefrontal cortex (the part of your brain responsible for processing concious thought), and the memory IS your concious thought. It's whatever your brain is thinking about RIGHT NOW. When the processor in your computer reads a bad string of data in the memory, it interrupts the concious thought process and you get a STOP code.
Diagnosing the problem
+ Show Spoiler +
To diagnose and repair the problem, we need to discover where the problem lies.
The first thing we need to do is record the STOP code, or error number.
1. The first place to get the information is from the Blue Screen itself. Write down all of the long numbers, the description that's in all Caps with underscores ( _ ) between the words, and any file names that may be mentioned
2.The next place to find the information is in the Event Viewer.
3.The last place to find the information is on your hard drive. Search your hard drive for files ending in .dmp and .mdmp. You're looking for the most recent file (or the one closest to the last BSOD that you experienced). Once you find it, we can perform an analysis of the memory dump, which I will explain in a later section.
4.Sometimes, when Error Reporting is enabled, the dump files will be stored temporarily on your system and are erased once the report is sent. To save this info, you'll have to copy the dump file before sending the report. To do this, just click on the "Details" link in the error report and you'll see some file locations listed. Choose the one that ends in .dmp or .mdmp, locate it in Windows Explorer, and copy it to your Desktop (you'll have to enable viewing of hidden files to do this). Here's an example of the Details:
The first thing we need to do is record the STOP code, or error number.
1. The first place to get the information is from the Blue Screen itself. Write down all of the long numbers, the description that's in all Caps with underscores ( _ ) between the words, and any file names that may be mentioned
2.The next place to find the information is in the Event Viewer.
3.The last place to find the information is on your hard drive. Search your hard drive for files ending in .dmp and .mdmp. You're looking for the most recent file (or the one closest to the last BSOD that you experienced). Once you find it, we can perform an analysis of the memory dump, which I will explain in a later section.
4.Sometimes, when Error Reporting is enabled, the dump files will be stored temporarily on your system and are erased once the report is sent. To save this info, you'll have to copy the dump file before sending the report. To do this, just click on the "Details" link in the error report and you'll see some file locations listed. Choose the one that ends in .dmp or .mdmp, locate it in Windows Explorer, and copy it to your Desktop (you'll have to enable viewing of hidden files to do this). Here's an example of the Details:
Further diagnosing memory
+ Show Spoiler +
If we suspect that the memory is the cause of our BSOD, head to http://www.memtest86.com, and follow the directions to download and burn the image. Run the program for at least 12 hours if you want a thorough test. It basically passes information to and from the memory repeatedly. Additionally, if you are a bit more tech savvy, you can open up your computer and remove one stick at a time from the motherboard. Try to reproduce the problem. If you still get a BSOD, replace the stick you removed, and remove another one. No more blue screens? Congratulations, you have found your sick stick and are one step closer to fixing the problem.
Further diagnosing drivers
+ Show Spoiler +
If we determine that a driver is to blame for the problems, we then need to determine WHICH driver is the guilty party. There are hundreds of drivers in your system. The easiest way, aside from analyzing the dump file, to find out which driver is to follow this simple troubleshooting model:
How long have the blue screens been happening?
Any new software (programs) or hardware (physical components) installed on the system?
Once you establish how long this has been happening, you have two options: Windows System Restore (rolls your computer back to a specific date), or Device Driver Rollback*. I recommend using System Restore if you don't have the slightest clue as to which driver is causing problems, but if you have pinpointed the faulty driver correctly, the Device Driver Rollback can be used.
*For further information on Windows System Restore or Device Driver Rollback, consult http://support.microsoft.com, and search for either of the aforementioned services.
How long have the blue screens been happening?
Any new software (programs) or hardware (physical components) installed on the system?
Once you establish how long this has been happening, you have two options: Windows System Restore (rolls your computer back to a specific date), or Device Driver Rollback*. I recommend using System Restore if you don't have the slightest clue as to which driver is causing problems, but if you have pinpointed the faulty driver correctly, the Device Driver Rollback can be used.
*For further information on Windows System Restore or Device Driver Rollback, consult http://support.microsoft.com, and search for either of the aforementioned services.
Dump files, and how to analyze them
+ Show Spoiler +
Please note that though this process may appear long and daunting, it has been explained in such a way so that the steps will be easy to follow.
A memory dump is what happens when Windows crashes. The memory is dumped into the pagefile and saved for the next reboot. Once Windows reboots, it reclaims the memory dump data from the pagefile and saves it to a file, which usually ends with the .dmp extension. Analyzing these dump files can help to figure out what's causing your system to crash. While they don't offer a "sure" fix, they provide clues to the cause of a crash so that we can work on fixing them. In my experience most system crashes are caused by faulty/corrupted drivers, malware, or hardware failures (in that order). Following the steps below will help us determine what may be causing your computer to Blue Screen, or crash.
The first thing to do when your system crashes is to reboot. Doing so will create the memory dump file so it's able to be accessed. Windows may also ask permission to send the file for online analysis. I suggest that you always allow it to be sent. Most times you won't get anything back, but occasionally it will point out the problem and save you a lot of work trying to determine it on your own. Also, quite often the first crash is the only crash as Windows will fix the problem when it reboots, so there's no need to worry unless Windows crashes repeatedly.
The next thing to do is to ensure that you are free of malware. If malware is present on your computer, it may have corrupted your installation, and be the cause of your crashes. I suggest you perform one of the free online scans that can be found at the following links:
http://housecall.trendmicro.com
http://www.pandasecurity.com/homeusers/solutions/activescan/
http://www.kaspersky.com/virusscanner Scan Only - no removal
http://www.bitdefender.com/scan8/ie.html
http://support.f-secure.com/enu/home/ols.shtml
http://us.mcafee.com/root/mfs/default.asp
http://onlinescan.avast.com/
http://ca.com/us/securityadvisor/virusinfo/scan.aspx
http://www.eset.com/onlinescan/
ADVISORY: Some or any of the above listed scanners will pick up items listed as "in quarantine" from other anti-virus programs. Therefore review your results carefully:
Once you have completed an online scan, or two, please search your hard drive for files ending with the .dmp extension. There are several types of memory dumps that Windows may create. These are distinguished below:1. A complete memory dump or a kernel memory dump that are usually saved in the C:\Windows directory and named MEMORY.DMP.
2. A small memory dump, aka a minidump, which are usually saved in the C:\Windows\Minidump directory. These are named Miniwwxxyy-zz.dmp, where the ww is the number of the month, the xx is the number of the day, the yy is the number of the year, and the zz is the number of the crash dump that day. For example, a minidump with the name of Mini070108-03.dmp is the 3rd minidump generated on July 1, 2008.
On some systems the directories where the dump files are stored are protected by being Hidden and System files.
To show Hidden and System files in Windows Explorer, click on the Start button, then select All Programs, then select Accessories, and finally select Windows Explorer.1. Once opened, select the Tools menu and then select the File Options menu item. In Vista you may have to press and hold the Alt key to view this menu.
2. Then go to the View tab and check the box labeled Show Hidden Files and Folders and uncheck Hide Protected Operating System Files
3. You will now be at a dialog that asks you if you're sure you want to do this. Click on the Yes button to allow the change to take place.
4. Then click the OK buttons at the prompts to exit the dialog. You will now be able to view hidden and system directories.
Warning - These files are hidden for a reason and messing with some of them may cause problems with your system.
Once you've located the memory dump file(s), then you'll have to get a debugger to analyze them. The one that I'm familiar with is the free Microsoft Debugging Tools for Windows. Download the version, 32 or 64 bit, that's appropriate for the operating system that you'll be running the debugger on. The debugger can be found at the following link: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Once it's downloaded, double click on it to install it. Once it's installed, open the debugger by doing the following:1. Click on the Start Menu.
2. Click on the All Programs menu.
3. Select the Debugging Tools for Windows program folder.
4. Click on the WinDbg icon to start the program.
Once you've opened the program, click on the File menu item, then on Symbol File Path.
In the window that opens, insert the exact text on the next line in the Symbol File Path box. This is a critical step, and if done incorrectly you'll end up with symbol errors:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
The easiest thing to do is copy the above bolded text and then paste it into the box. Once that is done, click on OK to exit the dialog. Next, click on File menu and then select the Save Workspace menu option. This will save the symbol path for future use.
NOTE: You MUST be connected to the internet in order to use the Symbol server listed above.
Next, click on the File menu and select the Open Crash Dump option. When the dialog box opens, click on the Browse button and browse to the location of the memory dump file and then double-click on it to load it into the Debugger. You may be prompted to save the workspace again, but just click on the No button. A window will now open and the dump file text will fill the debugging screen.
Here's an example of of an analysis report from a Minidump file. If this was a complete or kernel dump, it would be much larger.
+ Show Spoiler +
The next step is to click on the !analyze -v link that's highlighted in blue in the report above. This will generate more information, which would look something like this:
+ Show Spoiler +
Once this is done, we want to copy the text of the dump file analysis report. To do this, select the Edit menu item in the Debugging Tools window and then select Copy Window Text to Clipboard. Feel free to PM me with it and I'll have a look.
A memory dump is what happens when Windows crashes. The memory is dumped into the pagefile and saved for the next reboot. Once Windows reboots, it reclaims the memory dump data from the pagefile and saves it to a file, which usually ends with the .dmp extension. Analyzing these dump files can help to figure out what's causing your system to crash. While they don't offer a "sure" fix, they provide clues to the cause of a crash so that we can work on fixing them. In my experience most system crashes are caused by faulty/corrupted drivers, malware, or hardware failures (in that order). Following the steps below will help us determine what may be causing your computer to Blue Screen, or crash.
The first thing to do when your system crashes is to reboot. Doing so will create the memory dump file so it's able to be accessed. Windows may also ask permission to send the file for online analysis. I suggest that you always allow it to be sent. Most times you won't get anything back, but occasionally it will point out the problem and save you a lot of work trying to determine it on your own. Also, quite often the first crash is the only crash as Windows will fix the problem when it reboots, so there's no need to worry unless Windows crashes repeatedly.
The next thing to do is to ensure that you are free of malware. If malware is present on your computer, it may have corrupted your installation, and be the cause of your crashes. I suggest you perform one of the free online scans that can be found at the following links:
http://housecall.trendmicro.com
http://www.pandasecurity.com/homeusers/solutions/activescan/
http://www.kaspersky.com/virusscanner Scan Only - no removal
http://www.bitdefender.com/scan8/ie.html
http://support.f-secure.com/enu/home/ols.shtml
http://us.mcafee.com/root/mfs/default.asp
http://onlinescan.avast.com/
http://ca.com/us/securityadvisor/virusinfo/scan.aspx
http://www.eset.com/onlinescan/
ADVISORY: Some or any of the above listed scanners will pick up items listed as "in quarantine" from other anti-virus programs. Therefore review your results carefully:
Once you have completed an online scan, or two, please search your hard drive for files ending with the .dmp extension. There are several types of memory dumps that Windows may create. These are distinguished below:1. A complete memory dump or a kernel memory dump that are usually saved in the C:\Windows directory and named MEMORY.DMP.
2. A small memory dump, aka a minidump, which are usually saved in the C:\Windows\Minidump directory. These are named Miniwwxxyy-zz.dmp, where the ww is the number of the month, the xx is the number of the day, the yy is the number of the year, and the zz is the number of the crash dump that day. For example, a minidump with the name of Mini070108-03.dmp is the 3rd minidump generated on July 1, 2008.
On some systems the directories where the dump files are stored are protected by being Hidden and System files.
To show Hidden and System files in Windows Explorer, click on the Start button, then select All Programs, then select Accessories, and finally select Windows Explorer.1. Once opened, select the Tools menu and then select the File Options menu item. In Vista you may have to press and hold the Alt key to view this menu.
2. Then go to the View tab and check the box labeled Show Hidden Files and Folders and uncheck Hide Protected Operating System Files
3. You will now be at a dialog that asks you if you're sure you want to do this. Click on the Yes button to allow the change to take place.
4. Then click the OK buttons at the prompts to exit the dialog. You will now be able to view hidden and system directories.
Warning - These files are hidden for a reason and messing with some of them may cause problems with your system.
Once you've located the memory dump file(s), then you'll have to get a debugger to analyze them. The one that I'm familiar with is the free Microsoft Debugging Tools for Windows. Download the version, 32 or 64 bit, that's appropriate for the operating system that you'll be running the debugger on. The debugger can be found at the following link: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Once it's downloaded, double click on it to install it. Once it's installed, open the debugger by doing the following:1. Click on the Start Menu.
2. Click on the All Programs menu.
3. Select the Debugging Tools for Windows program folder.
4. Click on the WinDbg icon to start the program.
Once you've opened the program, click on the File menu item, then on Symbol File Path.
In the window that opens, insert the exact text on the next line in the Symbol File Path box. This is a critical step, and if done incorrectly you'll end up with symbol errors:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
The easiest thing to do is copy the above bolded text and then paste it into the box. Once that is done, click on OK to exit the dialog. Next, click on File menu and then select the Save Workspace menu option. This will save the symbol path for future use.
NOTE: You MUST be connected to the internet in order to use the Symbol server listed above.
Next, click on the File menu and select the Open Crash Dump option. When the dialog box opens, click on the Browse button and browse to the location of the memory dump file and then double-click on it to load it into the Debugger. You may be prompted to save the workspace again, but just click on the No button. A window will now open and the dump file text will fill the debugging screen.
Here's an example of of an analysis report from a Minidump file. If this was a complete or kernel dump, it would be much larger.
+ Show Spoiler +
Microsoft ® Windows Debugger Version 6.8.0004.0 AMD64
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
System Uptime: 0 days 0:04:00.921
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
System Uptime: 0 days 0:04:00.921
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
The next step is to click on the !analyze -v link that's highlighted in blue in the report above. This will generate more information, which would look something like this:
+ Show Spoiler +
Microsoft ® Windows Debugger Version 6.8.0004.0 AMD64
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
System Uptime: 0 days 0:04:00.921
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 84c64731, The address that the exception occurred at
Arg3: f4fecc3c, Trap Frame
Arg4: 00000000
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
FAULTING_IP:
+ffffffff84c64731
84c64731 ?? ???
TRAP_FRAME: f4fecc3c -- (.trap 0xfffffffff4fecc3c)
Unable to read trap frame at f4fecc3c
CUSTOMER_CRASH_COUNT: 3
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
LAST_CONTROL_TRANSFER: from 00000000 to 84c64731
STACK_TEXT:
f4feccac 00000000 00000000 01790000 00000000 0x84c64731
STACK_COMMAND: .trap 0xfffffffff4fecc3c ; kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE
BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE
Followup: MachineOwner
---------
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\FUBAR\Desktop\Mini070108-03.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805624a0
Debug session time: Tue Jul 1 16:28:22.439 2008 (GMT-4)
System Uptime: 0 days 0:04:00.921
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 84c64731, f4fecc3c, 0}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 84c64731, The address that the exception occurred at
Arg3: f4fecc3c, Trap Frame
Arg4: 00000000
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
FAULTING_IP:
+ffffffff84c64731
84c64731 ?? ???
TRAP_FRAME: f4fecc3c -- (.trap 0xfffffffff4fecc3c)
Unable to read trap frame at f4fecc3c
CUSTOMER_CRASH_COUNT: 3
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
LAST_CONTROL_TRANSFER: from 00000000 to 84c64731
STACK_TEXT:
f4feccac 00000000 00000000 01790000 00000000 0x84c64731
STACK_COMMAND: .trap 0xfffffffff4fecc3c ; kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE
BUCKET_ID: 0x8E_ANALYSIS_INCONCLUSIVE
Followup: MachineOwner
---------
Once this is done, we want to copy the text of the dump file analysis report. To do this, select the Edit menu item in the Debugging Tools window and then select Copy Window Text to Clipboard. Feel free to PM me with it and I'll have a look.
TL;DR: If you are looking for some common causes of BSOD's, here is a short list.
Memory - Check how it's sitting in the slot, change the slots up, and run memtest86 (link above)
Drivers - Update or rolling back can fix issues that have popped up out of the blue
AntiVirus - Running more than one AV program will cause major system instability, including blue screens.
Files - Defrag and Chkdsk at least once a month to keep your file structure in good shape.
If you are still suffering from BSODs and this information hasn't helped you to resolve it, please feel free to PM me, I'm A+ certified and happy to give any help I can. I will be updating this post with information as needed, so if you have something to contribute, please make a post!
Edit: added section for accessing and analyzing dump files