How to Fix a Windows Blue Screen of Death (BSOD)

Few things are more frustrating. You’re in the middle of working on a project, reaching a major milestone in a game or maybe just booting up your Windows 10 computer and, just like that, the entire OS crashes and presents you with a Blue Screen of Death, usually for no immediately apparent reason.

In Windows-speak, the term “Blue Screen of Death” is usually abbreviated as BSOD. It describes an error of some kind that hits the operating system hard enough that it’s forced to quit. Microsoft itself labels such errors with  “stopcodes.” Thus these errors may also be generically named “stop errors.”  Here’s an example that shows what a BSOD sometimes looks like:

Understanding the BSOD Screen

The screen starts with an old-fashioned unhappy face emoticon “ 🙁 “ (a colon, followed by an open parenthesis). Next, you see a brief explanation that “Your PC ran into a problem and needs to restart.” Windows writes one or more log files when a stop error occurs, so you see language about “collecting some error info” and a counter that keeps track while it’s writing that data (shows as “25% complete) above.

Microsoft provides a scannable QR code in modern BSODs (lower left) that you can scan with a smartphone and look up that way. The message also provides a lookup URL for stopcodes, where you can enter a numeric stopcode (and where you’ll see most common stopcodes, including the one shown above). The most common stop codes include:

• CRITICAL_PROCESS_DIED
• SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
• IRQL_NOT_LESS_OR_EQUAL
• VIDEO_TDR_TIMEOUT_DETECTED
• PAGE_FAULT_IN_NONPAGED_AREA
• SYSTEM_SERVICE_EXCEPTION
• DPC_WATCHDOG_VIOLATION

You can also download the Microsoft Error Lookup Tool (current version: Err_6.4.5.exe) to look up numeric error codes at a command prompt or in PowerShell, if you prefer.

In Windows 10, BSODs Aren’t Always Blue

Before Windows 8 came along in October 2012, BSODs always appeared on dark blue screens. These were chock-full of text and instructions (see below). With Windows 8, Microsoft switched to a kinder, gentler format shown in the preceding screencap. They also whittled down the information that appears on screen. In fact, the background color in Windows 10 is sometimes green, which is why you may see some of them called GSODs (“Green Screens of Death”). Here’s an example of an old-fashioned, pre-Windows-8 BSOD to put this information into historical context:

Making Sense of BSOD Data

Though nobody wants to see a BSOD on a Windows PC, they do occur from time to time. In the vast majority of cases, the PC will restart itself automatically after an error log, called a crash dump or  a dump file (extension .dmp) is created. By default, Windows 10 stores dump files in one of two locations.

You can manage crash dumps through Advanced System Settings in Windows 10 (type “Advanced System Settings” into the search box, then click “Settings” in the Startup and Recovery pane). You can also choose to toggle “Automatic restart” to off here, if you would prefer that any future BSODs stay on the screen until you get a chance to see them and write down (or take pic of) any relevant data.

If you select “Small memory dump” as the option for saving crash dumps, such files show up as Minidump.dmp files. For all other selections, the crash dump is named Memory.dmp. Crash dumps get written to the %SystemRoot% folder, which usually expands to C:\Windows. By design, small memory dump files are limited to 256KB in size. Other memory dumps will vary in size up to the size of memory on the PC where the dump is collected. Thus, on a PC with 16 GB of RAM, a Complete memory dump file will always be 16 GB in size (and other dump files, except for the small memory dumps, can be as large as 16 GB, but will often be smaller).

Examining a crash dump file can be helpful when troubleshooting related causes. For more details, see our story on how to use a minidump file to fix your Windows BSOD. That said, many users simply search on the stopcode and/or the numeric error code when seeking remediation advice. (Note that Microsoft calls that numeric code a “bug check code” or “bug check string.”

What To Do When Troubleshooting a BSOD

The immediate tendency following a BSOD is to get right into fix-it mode, start looking things up, and attempting repairs. Not so fast! Microsoft explains the entire troubleshooting process in its “Troubleshoot blue screen errors” tutorial. While you can – and probably should – read the Microsoft advice in its entirety, here’s a summary of key recommendations:

1. Shut down the Windows PC that experienced the BSOD
2. Disconnect all USB-attached devices except for mouse and keyboard (or wireless dongles).
3. Reboot your system into safe mode from the Windows Recovery Environment (WinRE)
4. If you recently installed new software, uninstall that software.
5. If you recently installed a new device driver (or your BSOD info points to a driver or device), uninstall or roll back that driver (if you don’t really need the device you can disable it temporarily instead)
6. Restart the PC, and see if the BSOD recurs. If not, you’ve probably isolated the cause and can start researching some kind of fix.

If the BSOD recurs despite the items taken out of the picture by removing, disabling or uninstalling them, whatever’s still left in the picture remains problematic. At this point you want to reboot into safe mode once again, and open an administrative command prompt or PowerShell session. From the command line, enter these commands, one at a time:

1. DISM /Online /Cleanup-image /Restorehealth
2. SFC /scannow

The first of these two commands finds and replaces any damaged operating system components in the side-by-side filestore (aka WinSxS). The second of these commands runs the System File Checker (SFC) and will repair any damaged files it finds.

Note that if SFC finds and fixes anything, you should run the command until it comes back with a clean bill of health (in some cases, I’ve had to run it two or three times before it came back clean). Note further that running either or both of these commands can take some time to complete, especially if one or both find items in need of fixing. Here’s what you want to see after your final SFC run:

Try NirSoft’s BlueScreenView Tool

There’s a complete BSOD handling infrastructure available from Microsoft, built around a tool called the Windows Debugger (aka WinDBG). You can download it as part of Microsoft’s free Windows Developer Kit if you really want to dig into the gory details. There are a lot of details to learn about, and minutiae to address, if you want to put this tool to work on crash dumps. For non-IT professionals or non-developers, I recommend Nir Sofer’s excellent BlueScreenView utility instead. It’s set up to automatically load the symbol tables it needs to resolve error codes, and it knows where to find crash dumps in need of analysis. It also presents crash dump data in a highly-readable form.

As an illustration, I forced one of my test laptops (a Lenovo ThinkPad X390 Yoga) to blue screen at an administrative command line. There, I entered the string taskkill /im svchost.exe /f. Warning: typing this string into an administrative command prompt or PowerShell session will crash the PC immediately. That’s because it kills a key program named svchost.exe (Service Host) that supports DLLs in the Windows runtime environment. Because most (if not all) Windows programs use one or more DLLs this basically makes Windows inoperable. Thus, it causes an immediate BSOD with the CRITICAL_PROCESS_DIED stopcode (shown in the lead-in graphic for this very story).

When I fired up BlueScreenView on that PC, it found the Memory.dmp file that this BSOD created during its post-crash cleanup phase. Here’s what the application looks like:

The top pane of the window shows all the crash dumps it finds on the target PC. Because there’s only one in this case, I shrunk it down to show as many details from the bottom pane as possible. Even so, the data in the top pane is important, with information in certain columns of special interest. Column 1 shows the name of the dump file. Column 3 shows the stopcode, which it labels “Bug Check String.” Column 3 shows the associated hexadecimal error code, 0x000000ef, which it labels “Bug Check Code.”

For most genuine BSODs (remember, I forced this one to happen) the stopcode and the error code will often help affected users zero in on causes and potential cures for their woes. In my experience, at least 90% of BSODs become fixable simply based on this information. That’s because it will often be solved by disconnecting, disabling, or uninstalling related devices, drivers, applications, or updates – just as Microsoft recommends, and I summarized in the previous section.

What About that Other Problematic 10% of BSODs?

Some BSODs won’t be amenable to quick and easy fixes. When they come up, as they sometimes will, it’s time to ask for help in getting things figured out. I can recommend two terrific sources of troubleshooting assistance available online, each with its own dedicated user forum specifically focused on solving BSOD issues. Likewise, each one stipulates certain requirements on users seeking BSOD help.

Source number one comes from TenForums.com (key disclosures: I am a VIP member of this community; I contribute input and suggestions to its members daily). The TenForums venue is in its BSOD Crashes and Debugging forum. Posting instructions are explicitly provided, along with a collection of BSOD tutorials, including those on WinDBG Basics,and  how to Install and Configure WinDBG for BSOD Analysis, Run BSOD Error Troubleshooter in Windows 10, and Enable or Disable BSOD Automatic Restart in Windows 10.

Source number two comes from British PC security and troubleshooting site BleepingComputer.com. They operate a user forum named Windows Crashes and Blue Screen of Death (BSOD) Help and Support. There, you’ll find pinned threads for the following topics (all of which are worth reading through):

• Sysnative Blue Screen of Death (BSOD) Academy: A series of detailed questions readers should answer to ask the experts at Sysnative for help with BSOD issues.
• BSOD Posting instructions: what information users should gather (based on downloading and running a Sysnative app) to obtain necessary dump files and content.
• BSODs but no Dump Files: instructions on how to configure a Windows PC to produce dump files whenever a BSOD occurs. Essential to know because diagnosis without dumps is nearly impossible.

Thus, you’ll have to read up a bit, download some tools, run some scripts and/or collect some logs that you’ll submit to make a semi-formal request for BSOD help. This will take one or more hours and force you to do some homework before such help becomes available. It may also involve numerous back-and-forth communications, where you’re asked to run additional diagnostic tools and collect additional logs and data to shed more light on your situation. Trust me: these guys know what they’re doing. I’ve seen only a handful of issues where users did everything asked of them where the BSOD experts couldn’t help them get things fixed.

Ultimately, where there’s enough will to get a Windows BSOD fixed, there’s a way to make that happen. Keep at it, and you’ll learn this for yourself.

Source: tomshardware.com