Blue screen INACCESSIBLE_BOOT_DEVICE (stop code 0x7B): Windows cannot reach its own disk

The PC powers on, shows the manufacturer logo and the spinning dots, and then drops to a blue screen. It restarts, tries Automatic Repair, and does it again. The screen says:

Your PC ran into a problem and needs to restart.

Stop code: INACCESSIBLE BOOT DEVICE

This is bug check 0x0000007B. It happens early in start-up, before Windows has loaded its normal tools, so the event logs are often empty and there is little to look at. That is why the diagnosis here is about what changed, not about error messages.

This is an advanced repair on a machine that will not start. Most of the causes are harmless, and the first checks below change nothing. But some steps edit the boot configuration or the offline registry, and a wrong move can leave the PC unbootable. Before anything else: have the BitLocker recovery key to hand, and make a copy of any data you cannot replace. Details are in the first diagnosis step.

Applies to: Windows 10, Windows 11 and Windows Server on a PC, a server or a virtual machine. Microsoft’s detailed procedure is written for Windows 10. The storage and boot design is the same on Windows 11 and recent Server versions, but Microsoft does not restate it for them, so treat the exact screens as Windows 10 wording.

What is going on

During start-up the Windows kernel has to take over the disk from the firmware. It does this with a storage driver loaded early in the boot, for example the standard SATA (AHCI) driver, the NVMe driver, or a vendor driver such as an Intel RAID or VMD driver. If the driver Windows expects is missing or not set to load at boot, or the disk is now behind a different controller than the one Windows was installed on, Windows cannot mount the system volume. It stops with 0x7B instead of risking damage to the disk.

Microsoft lists the usual causes: damaged or misbehaving storage filter drivers, file system corruption, a changed controller mode in the BIOS, a different storage controller from the one Windows was installed with, a disk moved to a different computer, faulty hardware, a Windows update that failed to commit because of component store corruption, damaged files on the boot partition, and a blank GPT entry in front of the boot partition.

Diagnosis

1. Make it safe to touch

• BitLocker recovery key. If the drive is encrypted, firmware changes and boot repairs can make BitLocker ask for the 48-digit recovery key, and the recovery command prompt cannot read a locked drive. Find it before you start. It is usually in the Microsoft account (account.microsoft.com/devices), the work or school account, Active Directory or Entra ID, or on a printout or USB stick from when BitLocker was turned on. Without it, a locked drive cannot be read. If you cannot find it, stop here.
• A copy of the data. If anything on the disk is not backed up elsewhere, image or copy the disk from another PC or from a bootable tool before editing the boot configuration or the registry.
• A way into the recovery environment. Windows can start its Recovery Environment (WinRE, a small repair copy of Windows) by itself after two failed boots. If it does not, boot from Windows installation media for the same version, choose Next > Repair your computer, then Troubleshoot > Advanced options.

2. What changed?

Almost every 0x7B has a trigger. Ask which of these happened just before it began:

• A BIOS/UEFI update, or a reset of the firmware to defaults (which often changes the storage mode).
• Someone changed the SATA or NVMe setting: AHCI, RAID, Intel RST, Intel VMD (Volume Management Device).
• The disk was cloned, moved to another PC, or a disk image was deployed to different hardware.
• A new disk, a RAID or HBA card, or a driver for one, was installed.
• A Windows update was installing when the machine restarted.

3. Look at the storage mode in UEFI/BIOS setup

Restart and open UEFI/BIOS setup (usually Del, F2, F10 or Esc, but it varies by maker). Find the SATA or storage setting. If it says RAID, Intel RST or VMD and Windows was installed with AHCI, or the other way round, put it back to what it was. Microsoft’s bug check page says to revert any recent hardware or UEFI changes, naming a controller mode change as an example. If the PC boots, you are done. Leave the setting alone and plan any real change as a controlled migration.

BitLocker and firmware changes: changing the storage mode or updating firmware can make BitLocker ask for the recovery key on the next boot. That is BitLocker doing its job. Have the key ready before you restart.

4. If Windows can start: Safe Mode and back

If you can reach the recovery menu, go to Troubleshoot > Advanced options > Startup Settings > Restart, then press 4 for Safe Mode. Microsoft notes that Safe Mode loads a core set of storage drivers, so after a Safe Mode boot, a normal restart sometimes works. This is worth one attempt, and it changes nothing. If Safe Mode also blue-screens, carry on.

5. In the recovery command prompt: can Windows see the disk?

Open Troubleshoot > Advanced options > Command Prompt. In the recovery environment, drive letters are often not what they are in Windows, so find the real one first.

diskpart
list disk
list vol
exit

list disk should show the system disk. On a UEFI PC there is an asterisk in the Gpt column. list vol shows the volumes: a large NTFS one that holds Windows (the “OSDisk” or similar), and a small FAT32 volume labelled SYSTEM, the EFI system partition. Note the letter of the Windows volume. This article uses D: as the example. Check with dir D:\ that it has a Windows folder.

If the disk is missing from the list, Windows is not the problem. Microsoft says to engage the PC maker or virtualisation vendor. Check cables and controller mode, and consider failing hardware. If the volume shows as locked or does not list a file system, unlock it with the recovery key, then look again:

manage-bde -unlock D: -recoverypassword 111111-222222-333333-444444-555555-666666-777777-888888

6. Check the boot entries

Run bcdedit. Under Windows Boot Manager, the device and path must point at a real device and boot file. On a UEFI PC the path is \EFI\Microsoft\Boot\bootmgfw.efi. Under the Windows Boot Loader with identifier {default}, check device, path, osdevice and systemroot. On UEFI the loader path ends in .efi.

7. If the blue screen began after a Windows update

List the packages in the offline image and look for any that show as Install Pending or Uninstall Pending:

dism /Image:D:\ /Get-Packages

Root cause

Windows cannot load or start the storage driver for the controller that now sits in front of its system disk. It comes down to one of four things: the controller or its mode has changed, a boot-critical driver or service is missing, disabled or blocked by a bad filter driver, the boot files or boot entries are damaged, or an update left the system half-changed. The checks above tell you which, in order from least to most invasive.