Interpreting a Bug Check Code

When Microsoft Windows encounters a condition that compromises safe system operation, the system halts. This condition is called a bug check. It is also commonly referred to as a system crash, a kernel error, a Stop error, or BSOD. A hardware device, its driver, or related software might have caused this error.

If crash dumps are enabled on the system, a crash dump file is created.

If a kernel debugger is attached and active, the system causes a break so the debugger can be used to investigate the crash.

If no debugger is attached, a blue text screen appears with information about the error. This screen is called a blue screen, a bug check screen, a Stop screen, or BSOD.

Interpreting bug check code tools

The exact appearance of the bug check screen depends on the cause of the error. The following is an example of one possible bug check screen:

On the other hand, some blue screens look like this:

Data tools

The hexadecimal number following the word «STOP» is called the bug check code or Stop code. This is the most important item on the screen.

Each bug check code has four associated parameters. In the first blue screen shown here, all four parameters are displayed after the bug check code. However, in the second kind of blue screen, these parameters have been rearranged within the explanatory text. Regardless of the amount of rearrangement, they will always appear sequentially. If fewer than four parameters appear, the remaining parameters can be assumed to be zero.

The remainder of the text on the blue screen gives additional information. For some bug checks, this may be an explanation of what happened or suggestions for how you can deal with the problem. If a kernel-mode dump file has been written, this will usually be indicated as well.

Under some conditions, Windows will display only the first line of the blue screen. This can occur if the vital services needed for the display have been affected by the error.

Bug Check Symbolic Names

Each bug check code also has an associated symbolic name. These names usually do not appear on the blue screen. In these examples, the first screen shows bug check 0x79 (MISMATCHED_HAL), while the second shows bug check 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED).

You can deliberately cause a bug check from a kernel-mode driver by passing the bug check’s symbolic name to KeBugCheck or KeBugCheckEx. This should only be done in circumstances where no other option is available.

Reading Bug Check Information from the Debugger

If a debugger is attached, a bug check will cause the target computer to break into the debugger. In this case, the blue screen may not appear, or may appear with less text; the full details on this crash will be sent to the debugger and appear in the debugger window. For more information, see Using a Debugger.

This reference section for the bug check codes can be found as part of Windows Debugging. See Bug Check Code Reference for descriptions of the bug checks and parameters. Each reference page lists the bug check code, the text string, and the four additional parameters which are displayed with each bug check. It also describes how you can diagnose the fault that led to the bug check, and possible ways to deal with the error.

For a full list of bug check codes, see the Bugcodes.h file. This file can be found in the inc directory of the Microsoft Windows Driver Kit (WDK).

Tools Included in Debugging Tools for Windows

Debugging Tools for Windows includes several tools in addition to the debugging engine and the Debugging Environments. The tools are in the installation directory of Debugging Tools for Windows.

DumpChk
Validate a memory dump file.

GFlags
Control registry keys and other settings.

Kill
Terminate a process.

Logger and LogViewer
Record and display function calls and other actions of a program.

PLMDebug
Use the Windows debugger to debug Windows app, which run under Process Lifecycle Management (PLM). With PLMDebug, you can take manual control of suspending, resuming, and terminating a Windows app.

Remote Tool
Remotely control any console program, including KD, CDB, and NTSD. See Remote Debugging Through Remote.exe.

TList
List all running processes.

UMDH
Analyze heap allocations.

USBView
Display USB host controllers and connected devices.

DbgRpc (Dbgrpc.exe)
Display Microsoft Remote Procedure Call (RPC) state information. See RPC Debugging and Using the DbgRpc Tool.

KDbgCtrl (Kernel Debugging Control, Kdbgctrl.exe)
Control and configure the kernel debugging connection. See Using KDbgCtrl.

SrcSrv
A source server that can be used to deliver source files while debugging.

SymSrv
A symbol server that the debugger can use to connect to a symbol store.

SymProxy
Create a single HTTP symbol server on your network that all your debuggers can point to. This has the benefit of pointing to multiple symbol servers (both internal and external) with a single symbol path, handling all authentication, and increasing performance via symbol caching. Symproxy.dll is in the SymProxy folder in the installation directory.

SymChk
Compare executable files to symbol files to verify that the correct symbols are available.

AgeStore
Removes old entries in the downstream store of a symbol server or a source server.

DBH
Display information about the contents of a symbol file.

PDBCopy
Remove private symbol information from a symbol file, and control which public symbols are included in the file.

DbgSrv
A process server used for remote debugging. See Process Servers (User Mode).

KdSrv
A KD connection server used for remote debugging.See KD Connection Servers (Kernel Mode).

DbEngPrx
A repeater (small proxy server) used for remote debugging. See Repeaters.

Breakin (Breakin.exe)
Causes a user-mode break to occur in a process. For help, open a Command Prompt window, navigate to the installation directory, and enter breakin /?.

List (File List Utility) (List.exe)
For help, open a Command Prompt window, navigate to the installation directory, and enter list /?.

RTList (Remote Task List Viewer) (Rtlist.exe)
List running processes via a DbgSrv process server. For help, open a Command Prompt window, navigate to the installation directory, and enter rtlist /?.

Installation Directory

The default installation directory for 64 bit OS installs for the debugging tools is C:\Program Files (x86)\Windows Kits\10\Debuggers\. If you have a 32-bit OS, you can find the Windows Kits folder under C:\Program Files. To determine if you should use the 32 bit or 64 bit tools, see Choosing the 32-Bit or 64-Bit Debugging Tools.

Bug Check 0x7B: INACCESSIBLE_BOOT_DEVICE

The INACCESSIBLE_BOOT_DEVICE bug check has a value of 0x0000007B. This bug check indicates that the Microsoft Windows operating system has lost access to the system partition during startup.

This topic is for programmers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.

INACCESSIBLE_BOOT_DEVICE Parameters

The address of a UNICODE_STRING structure, or the address of the device object that could not be mounted

To determine the meaning of Parameter 1, look at the data that it points to. If the first word (USHORT) at this address is even, Parameter 1 is the beginning of a Unicode string. If the first word (USHORT) at this address is 0x3, Parameter 1 is the first field (Type) of a device object.

If this parameter points to a device object, the file system that was supposed to read the boot device failed to initialize or simply did not recognize the data on the boot device as a file system structure. In this situation, the specified device object is the object that could not be mounted.

If this parameter points to a Unicode string, you must read the first 8 bytes at this address. These bytes form the UNICODE_STRING structure, which is defined as follows:

The Length field gives the actual length of the string. The Buffer field points to the beginning of the string (Buffer is always be at least 0x80000000.)

The actual string contains the Advanced RISC Computing (ARC) specification name of the device that the boot was being attempted from. ARC names are a generic way to identify devices in the ARC environment.

Cause

The INACCESSIBLE_BOOT_DEVICE bug check frequently occurs because of a boot device failure. During I/O system initialization, the boot device driver might have failed to initialize the boot device (typically a hard disk).

File system initialization might have failed because it did not recognize the data on the boot device. Also, repartitioning the system partition, changing the BIOS configuration, or installing a disk controller might induce this error.

This error can also occur because of incompatible disk hardware. If the error occurred at the initial setup of the system, the system might have been installed on an unsupported disk controller. Some disk controllers require additional drivers to be present when Windows starts.

Resolution

This error always occurs while the system is starting. This error frequently occurs before the debugger connection is established, so debugging can be difficult. In addition, the OS may not be accessible and the error logs may be empty as the OS has not booted far enough to start those sub-systems.

If you are unable to boot Windows

If you receive this stop code and Windows doesn’t boot forward into the OS, try the following:

Revert any recent hardware changes

Remove any recently added hardware, especially hard disk drives or controllers, to see if the error is resolved. If the problematic hardware is a hard disk drive, the disk firmware version might be incompatible with your version of the Windows operating system. Contact the manufacturer for updates. If you removed another piece of hardware and the error is resolved, IRQ or I/O port conflicts may exist. Reconfigure the new device according to the manufacturer’s instructions.

If you have recently made changes to BIOS settings, such as changing the controller mode from legacy to AHCI in the BIOS, revert those changes. For more information, see https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface

Check for storage device compatibility

Confirm that all hard disk drivers, hard disk controllers, and any other storage adapters are compatible with the installed version of Windows. For example, you can get information about compatibility at Windows 10 Specifications.

Update BIOS and Firmware

Check the availability of updates for the system BIOS and storage controller firmware.

Use the Media Creation Tool to create a bootable USB thumb drive or DVD

Use Media Creation Tool, using another computer to create a bootable USB thumb drive or DVD. Use it to perform a clean install, by selecting the setup file or booting from the USB.

For more information, see Get Windows 10.

Be aware that you may need to disable features, such as quick BIOS boot, or you may not be able to reach the boot device priority menu. Change your boot sequence priority in the BIOS menu to boot from FDD (FlashDiskDrive) or DVD instead of HDD.

Common Boot Menu Keys

The boot menu key varies per manufacturer, these keys are commonly used. Check the system documentation to determine what boot key is used.

F12 ESC F9 F10 F8 Common BIOS Setup Keys

The BIOS setup key varies per manufacturer, these keys are commonly used. Check the system documentation to determine what setup key is used.

If you can boot Windows

Boot to Safe Mode and then Boot Normally

Complete the following steps to boot into Safe Mode. Booting into safe mode loads a core set of storage drivers that may allow for the storage system to be accessed once again.

To enter Safe Mode, use Update and Security in Settings. Select Recovery->Advanced startup to boot to maintenance mode. At the resulting menu, choose Troubleshoot-> Advanced Options -> Startup Settings -> Restart. After Windows restarts to the Startup Settings screen, select option, 4, 5 or 6 to boot to Safe Mode.

Once Windows is loaded in Safe Mode, restart your PC to see if the proper storage drivers will be loaded and that the storage device is recognized.

Safe Mode may also be available by pressing a function key on boot, for example F8. Refer to information from the system manufacturer for specific startup options.

Use the scan disk utility to confirm that there are no file system errors. Select and hold (or right-click) on the drive you want to scan and select Properties. Select Tools. Select the Check now button.

Run a virus detection program. Viruses can infect all types of hard disks formatted for Windows, and resulting disk corruption can generate system bug check codes. Make sure the virus detection program checks the Master Boot Record for infections.

For IDE devices, define the onboard IDE port as Primary only. Also check each IDE device for the proper master/subordinate/stand alone setting. Try removing all IDE devices except for hard disks. Finally, check the System Log in Event Viewer for additional error messages that might help identify the device or driver that is causing the error.

Confirm that there is sufficient free space on the hard drive. The operating system and some applications require sufficient free space to create swap files and for other functions. Based on the system configuration, the exact requirement varies, but it is normally a good idea to have 10% to 15% free space available.

Look in Device Manager to see if any devices are marked with the exclamation point (!). Review the events log displayed in driver properties for any faulting driver. Try updating the related driver.

Check the System Log in Event Viewer for additional error messages that might help pinpoint the device or driver that is causing the error. For more information, see Open Event Viewer. Look for critical errors in the system log that occurred in the same time window as the blue screen.

You can try running the hardware diagnostics supplied by the system manufacturer.

Use the System File Checker tool to repair missing or corrupted system files. The System File Checker is a utility in Windows that allows users to scan for corruptions in Windows system files and restore corrupted files. Use the following command to run the System File Checker tool (SFC.exe).

After automatic repair, on the Choose an option screen, select Troubleshoot > Advanced options > System Restore. This option takes your PC back to an earlier point in time, called a system restore point. Restore points are generated when you install a new app, driver, update, or when you create a restore point manually. Choose a restore point before you experienced the error.

Use the kernel debugger to attach to the system and further analyze the failure as described in remarks.

Remarks

Investigating the storage system configuration

It is helpful to know as much as possible about the boot device that Windows is installed on. For example, you can investigate the following items:

Find out what type of controller the boot device is connected to (SATA, IDE, etc). If you can boot the system, you can use device manager to examine the controller and disk driver properties and see the associated driver file as well as error events.

Indicate if other devices are attached to the same controller that the boot device is on (SSD, DVD, and so on).

Note the file system that is used on the drive, typically NTFS.

To analyze this error using the kernel debugger: Run an lm (List Loaded Modules) command in the debugger to see which modules are loaded to attempt to isolate the specific driver. Verify that the following drivers were loaded.

Also make sure your controller drivers are loaded. For example for a SATA RAID Controller, this might be the iaStorA.Sys driver, or it could be the EhStorClass driver.

List the drivers that contain «stor», storahci, may be present.

Booting with a debugger attached

If you can boot the target system with a debugger connected, issue !devnode 0 1 when the bugcheck occurs. You’ll see which device lacks a driver or could not start, and the reason for not starting may be apparent.

One cause, might be that Plug and Play cannot assign resources to the boot device. You can verify this restriction by finding an entry for the service. If the status flags include DNF_INSUFFICIENT_RESOURCES or do not include DNF_STARTED or DNF_ENUMERATED, you may have located the problem. Try !devnode 0 1 storahci to save some time, instead of dumping the whole device tree.