共用方式為

Troubleshooting a Stop 0x7B in Windows

  • 發行項

The purpose of this blog is to provide information about the common Stop 0x7B bugcheck/Reboot Loop issue, and the best methods available to resolve it.
We will discuss the main components involved in this type of bugcheck/crash, what can affect them, and not only troubleshooting steps to perform, but also steps to resolve the issue.

Basic Information

A Stop 0x7B bugcheck has this error:

INACCESSIBLE_BOOT_DEVICE

So, what does that mean, exactly?

I realize that not everybody is familiar with the boot process, and the files needed to boot to Windows, but that is another topic altogether; so I’ll just outline the basics:

When a PC that uses a BIOS (Basic Input/Output System) boots from a hard disk that has a volume/partition formatted as a Master Boot Record (MBR), it searches the MBR for information about where the Windows directory is located.  Before we can boot Windows, we have to load some storage controller drivers.  Windows has the standard ones already “in the box”, but sometimes newer chipsets require updated drivers before Windows will be able to boot, and those are generally added during the Windows setup process.

So, when the boot process searches for a bootable device, if the correct driver is not loaded, we will see this issue occur.  Additionally, there several other factors that could cause this type of issue to occur besides a problem storage controller driver, including (but not limited to):

• We may actually have missing or corrupt storage controller drivers
• We may have missing or corrupt Filter Drivers related to the storage stack, or in some cases, misbehaving Filter Drivers
• We may have file system corruption
• The storage controller mode or settings in the BIOS may have been changed
• A different storage controller may be in use than the one used when Windows was installed, or the disk may have been moved to a different machine with a different controller
• There may be a problem with the hardware—the motherboard or storage controller may be faulty

There are essentially two different “Branches” or types of cases where a Stop 0x7B can occur—cases where the machine was running fine and then the issue appeared, or cases where a Windows is being deployed to a machine; we will discuss the former type of issue first.

So, what do we do when we engage on a case where the machine was working fine, and suddenly is now in a “Reboot Loop” caused by a Stop 0x7B bug check? 
Well, there is a sequence that we should follow:

First—and this is important—find out everything you can about the circumstances of the issue—i.e.: any recent updates or new software installations, the last time the machine was booted, why the machine was booted (was it due to problems with the OS?), etc.  This will help guide the troubleshooting path. 

The steps below outline the order in which we should proceed, assuming that there are no hardware problems:

Troubleshooting step 1 if machine was previously was booting properly:

In nearly every single case, we should always run chkdsk /f on the volume holding the Windows directory first.  In some, or perhaps many cases, this alone may resolve the issue. If we run chkdsk on the volume, and it finds errors, we should run it again, until there are no more errors present.  If we find errors and fix them, or if we do not find any errors, and the issue still exists, then we need to move to the next step in the sequence

Troubleshooting step 2 if machine was previously was booting properly:

If we know what the second parameter of the bugcheck is, and it is a 0x34 , and running chkdsk did not resolve the issue, then we may have a filter driver that is corrupt or missing, or misbehaving, so we would either need to boot to WinPE and load the system hive file. 

To do this, we would boot to WinPE or WinRE (using a Windows Vista / Windows Server 2008 / Windows 7 / Windows Server 2008 R2 DVD).  Once there, use Regedit.exe to load the “SYSTEM” registry hive file.  Once booted, follow these steps to load the hive file:

  1. Type “regedit.exe” into the cmd window, and press enter
  2. Within Regedit, highlight the HKEY_USERS branch on the left pane

3. Highlight the ControlSet00x identified in the “Select” key from the previous step, and expand it out

4. Highlight the “Control” folder on the left and expand it out

We are looking for any UpperFilters or LowerFilters entries, but mainly as it relates to storage; we can compare to another, working machine’s registry entries so we know what would normally appear there, and if there are entries that don’t appear to be standard, we can remove them. 

Here are some (but probably not all) of the different registry entries where we may find these filter drivers (located under the ControlSet designated as “Default”):

\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}
\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}
\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}
\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F}

If an UpperFilters or LowerFilters entry appears that is non-standard (i.e.: not a Windows default Filter Driver in these keys, such as PartMgr), we would remove the entry by double-clicking on it in the right pane, and deleting only that entry (there may be multiple entries).

The reason that these entries may affect us is because in the “Services” branch, there may be an entry with a START type set to “0” or “1” (indicting it is loaded at the “Boot” or “System” portion of the boot process), and either the file referred to is missing, corrupt, or it may be named differently than what is listed in the entry.  It is important to note that if there indeed is a service set to “0” or “1” that corresponds to an UpperFilters or LowerFilters entry, Setting the service to disabled in the Services branch without removing the Filter Driver entry will cause the machine to crash with a 0x7b!

If we find a Filter Driver entry that is not related to a storage component, such as the network stack, it is still possible that this may be related, if the machine is booting from SAN, and is using iSCSI to connect to that SAN.

Troubleshooting step 3 if machine was previously was booting properly:

Assuming that the second parameter of the bug check is not 0x34 (such as 0xC102), and running chkdsk did not find any problems, or found problems and fixed them, but the issue still exists, then, depending on the OS, we would perform different actions:

  • If the OS is Vista/Windows Server 2008 or higher, we could boot to WinPE/WinRE and run SFC /scannow in Offline mode; to do this, we would run this command: “sfc.exe /scannow /OffBootDir=C: /OffWinDir=C:\Windows”, where “C:\” is the volume that contains the Windows directory.  If SFC finds errors and fixes them, we should run it again, but if it is unable to fix the errors, we may not have many options left aside from rebuilding/restoring from backup.  If it finds no errors, then we may have other issues going on.
  • If the OS is Windows XP/Windows Server 2003, we can try to perform a Repair Install/In-Place Upgrade.

Troubleshooting step 4 if machine was previously was booting properly:

If running chkdsk and SFC /scannow on Windows Vista/Windows Server 2008 or higher does not resolve the issue, it is possible that the BCD has become corrupt; you can use the bootrec /rebuildbcd command to rebuild the BCD; Best Practice dictates creating a copy of the BCD before performing these steps, and Method 2 in KB927391 provides the commands to perform this action. 

As it relates to Legacy OS’s (Windows XP and Windows Server 2003), aside from the steps outlined in Troubleshooting Step 3 above, the only options available if those do not resolve the issue would be to restore the machine from backup (if one is available) or rebuild the machine.
Likewise—if SFC /scannow finds problems, but is unable to fix them, or if rebuilding the BCD outlined in Troubleshooting Step 4 above does not resolve the issue, we will probably need to restore from backup or rebuild the machine.

Keep in mind that when we say, “rebuild the machine”, what we are essentially doing is re-installing the OS and any applications previously installed on the machine; any data on the machine on other drives should be unaffected (unless there is file system and file corruption on the drive, and the data is located on the same drive as the OS, where some of the data may also be corrupted), and we would just need to re-install any applications using that data after the OS is re-installed (Exchange, SQL, etc.).

Troubleshooting when the issue occurs during deployment:

If the issue is occurring when deploying an image, this generally means we do not have the drivers needed for the specific controller (and the mode it is operating in) loaded, or they are not loaded properly.

When we are experiencing this type of issue, we need to check the BIOS settings and the driver being used to make sure that the correct mode and driver for that mode is being used (they must match, such as AHCI or RAID controller driver needed if the controller is configured in this mode). 

If this is a standalone machine, where the machine is booting from CD/DVD and simply running Windows Setup, make sure that the (correct) drivers are entered using the “F6” prompt while booting (for XP/W2K3), or the add drivers button within Setup for Vista/W2K8 and above.

If a custom image is being deployed  to a machine (a .WIM file) and we are seeing these issues, the first thing to check would be the controller installed on the machine, it’s settings, and make sure the controller and the settings for it matches the driver that is injected into the image.

If the controller and the driver injected into an image don’t match, of course we will need to obtain the correct drivers and inject them into the image; I won’t go into those details, because there are many articles that describe how to do that, and performing those actions are beyond the scope of this blog.

To eliminate issues that may be caused by hardware, we can try performing the installation/image deployment on another identical machine that has the same settings as the original target machine.

Perry Johnson
Senior Support Escalation Engineer
Microsoft Support

Comments

  • Anonymous
    August 06, 2013
    A very useful and informative blog for system admins. to handle server crash issues.
  • Anonymous
    October 31, 2013
    This is really a nice Blog Perry!
  • Anonymous
    November 09, 2013
    Very informative and useful article, though i believe a correction is needed - SYSTEM hive to be loaded under HKLM instead of HKU, in troubleshooting step 2.
  • Anonymous
    November 19, 2013
    @Prabhash : I am sure you have successfully tried Step 2 above on several machines........@Perry : Great work at summarizing the entire TS for 0x7B. (Only other scenario I can think of is the 0xC10 for SW RAID 1 configurations....which probably is a bit complex for this one article)
  • Anonymous
    March 31, 2015
    Excelente!, Me fue de total ayuda la información! Me solucionó el problema en mi server, en especial la parte del BCD. Muchas Gracias! (Y)