INACCESSIBLE_BOOT_DEVICE: Windows cannot reach the disk it boots from

What Stop 0x7B tells you

This error means Windows got far enough to start its kernel and then could not reach the disk it was booting from. That is a narrower failure than it looks: the firmware worked, the boot manager worked, and the loader worked. What broke is the path between the kernel and the storage device.

Microsoft's list of causes reflects that. It names missing, corrupted or misbehaving filter drivers related to the storage stack; file system corruption; changes to the storage controller mode or settings in the BIOS; using a different storage controller from the one used when Windows was installed; moving the hard disk to a different computer with a different controller; faulty hardware; and, in unusual cases, the TrustedInstaller service failing to commit newly installed updates because of component store corruption.

Microsoft also notes this error might occur after some changes are made to the computer, or immediately after Windows is deployed. That is the single most useful diagnostic question here: what changed? A BIOS setting, a disk moved between machines, a storage driver, or an update that half-installed will each account for it, and each has a different remedy.

The change that most often causes it

Two of Microsoft's causes are the same story told twice: the storage controller is not presenting itself the way Windows expects. Changing the SATA mode in the BIOS between AHCI, IDE and RAID does exactly that, and it is a setting people alter while chasing something else entirely, or that a firmware update resets on their behalf.

So before opening a command prompt, put the setting back. If the error started after a BIOS update, a CMOS reset or a deliberate change to the storage mode, reversing that change is faster than any repair and it does not risk your data.

The same logic covers a disk moved into a different machine. Windows installed on one controller will not necessarily start on another, and the fix there is not repair but returning the disk to the machine it was installed on, or reinstalling on the new one.

Confirming the disk is visible at all

Microsoft's first checks in the recovery environment establish whether the disk is even present. Start the system from the installation media for your version of Windows, choose Repair your computer, and open a Command Prompt. Then run diskpart and list disk.

An asterisk in the Gpt column means the machine uses UEFI; no asterisk means BIOS. If the OS disk is listed correctly, run list vol, which shows the volumes with their labels and status — typically a Windows RE volume, the OS volume marked Boot, and a SYSTEM volume marked System.

Microsoft is explicit about what it means when that fails: if the disk that contains the OS is not listed in the output, you have to engage the manufacturer. At that point the problem is hardware or firmware rather than anything a command can repair, and continuing to run repair tools is wasted effort.

Checking the boot configuration

Run bcdedit at the recovery prompt and read two sections. Under Windows Boot Manager, with the {bootmgr} identifier, the device and path entries should point at the right device and boot loader file — on UEFI that path ends in bootmgfw.efi. Under Windows Boot Loader, with the {default} identifier, device, path, osdevice and systemroot should point at the right partition, winload file, OS partition and OS folder.

Back up before changing anything. Microsoft's command is bcdedit /export C:\temp\bcdbackup, which can be restored later with bcdedit /import C:\temp\bcdbackup. Individual values are then set with bcdedit /set, as in bcdedit /set {default} device partition=C: when the device entry is wrong or missing.

If the store cannot be opened at all, or you want to rebuild it outright, Microsoft's instruction is bootrec /rebuildbcd. Where the boot files themselves are missing, bcdboot recreates them — for example Bcdboot D:\windows /s R: /f ALL, where D is the Windows drive and R the system partition. The ALL parameter writes both UEFI and BIOS boot files to their respective locations.

When it started after a Windows update

This has its own procedure, and it is worth trying before anything involving the registry. Run Dism /Image:C: /Get-packages against the OS drive to list packages, which shows any marked Install pending or Uninstall pending. Then run dism /Image:C:\ /Cleanup-Image /RevertPendingActions, substituting your system partition.

Microsoft's follow-up is to check for a pending.xml file under Windows\WinSxS on the OS drive and, if it exists, rename it to pending.xml.old. Together those two steps undo an update that was committed halfway and left the machine unable to start.

Beyond that the article goes into loading offline registry hives to remove PendingXmlIdentifier and PendingFileRenameOperations values, and to check that the boot-critical services ACPI, DISK, VOLMGR, PARTMGR, VOLSNAP and VOLUME each have a Start value of 0. That is genuinely advanced work with real potential to make things worse, and it is where handing the machine to someone who does this routinely becomes the sensible choice.

The last two commands

If the computer still will not start, Microsoft's closing steps are a disk check and an offline system file check, both from the recovery command prompt: chkdsk /f /r on the OS drive, then sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows, substituting your drive letter.

Run them in that order and expect chkdsk /r to take a long time on a large or failing disk — hours rather than minutes. It is reading every sector, which is the point, and interrupting it is worse than leaving it alone.

If chkdsk reports significant bad sectors, treat that as the answer rather than a step. A disk producing read errors will keep causing this stop code no matter how many times the boot configuration is repaired, and the next move is a backup and a replacement rather than another repair.

Sources and review notes

Checked on September 8, 2026. Based on Microsoft's advanced troubleshooting article for Stop error 7B and its Windows startup issues article, both written for support agents and IT professionals. The advice to reverse a BIOS change first, and the reading of chkdsk bad-sector results as a replacement signal, are editorial. The registry procedures referenced in section 5 can leave a machine unbootable if done wrongly — read Microsoft's article in full before attempting them. Glitchary is independent of Microsoft.

• Microsoft: Stop error 7B or Inaccessible_Boot_Device troubleshooting
• Microsoft: Windows startup issues troubleshooting