Resolve INACCESSIBLE_BOOT_DEVICE when no controller change or clone explains it

Windows Boot Manager finds the installation and begins kernel startup, but Windows then loses access to the system partition and stops with INACCESSIBLE_BOOT_DEVICE. In this writeup there is no demonstrated SATA/controller-mode change, clone, disk move, motherboard migration, RAID/VMD change, or locked BitLocker volume to explain the failure.

The remaining common mechanisms include a failed update, logical file-system corruption, a missing or misconfigured inbox boot-critical service, a proven third-party storage filter, or failing storage hardware. 0x7B is a kernel/storage-path stop code. It is not, by itself, evidence that BCD should be rebuilt.

Searchable Windows error codes and exact messages

Record the complete bug-check display, any parameters, named driver, preceding update, and every I/O status or event. Do not combine codes observed on different machines.

Use this procedure when Windows explicitly displays INACCESSIBLE_BOOT_DEVICE or bug check 0x0000007B, the Windows disk is consistently visible in firmware and WinRE, and no controller setting, clone, disk transfer, motherboard migration, or specialist storage configuration explains the timing.

Do not use this generic procedure after a SATA/AHCI/controller-mode change, clone, restored image, port/slot move, motherboard replacement, or migration to RAID, SCSI, VMD/IRST, Storage Spaces, a virtual storage layer, or another specialist stack. Do not use it when the disk is absent, intermittent, RAW, or returning continuing I/O errors; stabilize or image the device first. If the displayed code is a BCD/Boot Manager status rather than 0x7B, use the boot-loader writeup.

The exact Windows build and the original cause may remain unknown when no update- or driver-specific action is required. The displayed stop code, physical Windows disk, offline Windows volume, disk stability, recent change history, active offline control set, and involvement of specialist storage may not remain unknown.

• Windows Recovery Environment or a working Windows 10/11 installation USB
• A consistently readable Windows disk
• A verified data or system-image backup before any corrective write
• A detected writable backup location for logs and registry exports
• Administrator access if Safe Mode starts
• Exact product and driver identity before removing a third-party storage filter or package

Remove unrelated external storage. Record firmware settings but do not change controller mode, UEFI/legacy mode, Secure Boot, or disk layout. In WinRE, detect drive letters; this procedure uses W: only for the verified offline Windows volume and R: only for a verified external backup volume. Prove each proposed letter is unused before assignment; if it is occupied, choose another unused letter and substitute it consistently. Stop when an assignment fails or its content check identifies the wrong volume.

1. Record the exact line Stop code: INACCESSIBLE_BOOT_DEVICE, the numeric 0x0000007B value if shown, and all displayed parameters or named files.

2. Confirm the history. If the failure immediately followed a controller setting change, clone, disk move, port change, or motherboard replacement, stop this article and use the corresponding writeup.

3. In firmware, confirm that the Windows disk is present with its expected model and capacity.

4. In WinRE Command Prompt, inspect disks and volumes:

   diskpart
   list disk
   list volume
   

5. Identify the Windows volume. Assign W only if necessary:

   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   detail volume
   exit
   

   Confirm that the second detail display still identifies the intended Windows volume and now shows the chosen letter.

6. Verify both the offline registry and an inbox storage driver:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\drivers\disk.sys
   

7. If the OS disk is absent, the volume is RAW, reads fail, or the disk changes identity or capacity between starts, stop. Do not run CHKDSK, SFC, DISM, or registry edits against an unstable device.

8. Query the offline System log for storage and file-system evidence:

   wevtutil qe W:\Windows\System32\winevt\Logs\System.evtx /lf:true /q:"*[System[(EventID=7 or EventID=11 or EventID=15 or EventID=55 or EventID=98 or EventID=129 or EventID=153 or EventID=157)]]" /rd:true /f:text /c:50
   

9. Run a read-only file-system check:

   chkdsk W:
   

10. Check for a servicing trigger without changing it:

    dism /Image:W:\ /Get-Packages /Format:Table
    

    Record packages whose state is Install Pending or Uninstall Pending, but do not assume that any pending package caused the stop.

11. Detect and map the boot layout on the verified Windows disk. A GPT asterisk with an existing FAT32 EFI System Partition indicates UEFI/GPT; an MBR disk with an active NTFS system partition indicates BIOS/MBR:

    diskpart
    select volume <Windows-volume-number>
    detail volume
    select disk <Windows-disk-number>
    detail disk
    list partition
    select partition <system-partition-number>
    detail partition
    list volume
    exit
    

    Require the system partition to be on the verified Windows disk and its type/active state to match the detected architecture. Stop when multiple ESPs cannot be attributed. On BIOS/MBR, if the active system partition is the Windows volume itself, do not assign S:; substitute W: for BIOS BCD paths and use W: as the boot volume below.

    Otherwise, prove S: is unused, then map the separate system partition and confirm it again:

    diskpart
    select disk <Windows-disk-number>
    select partition <system-partition-number>
    detail partition
    assign letter=S
    detail partition
    exit
    

    Stop if assignment fails or the second detail display does not identify the same verified system partition.

12. Inspect, but do not rebuild, the existing BCD. Preserve the store.

    UEFI/GPT:

    md W:\BootRepairBackup
    copy S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\BCD-before-generic-0x7B
    bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v > W:\BootRepairBackup\bcd-before-generic-0x7B.txt
    

    BIOS/MBR:

    md W:\BootRepairBackup
    copy S:\Boot\BCD W:\BootRepairBackup\BCD-before-generic-0x7B
    bcdedit /store S:\Boot\BCD /enum all /v > W:\BootRepairBackup\bcd-before-generic-0x7B.txt
    

13. In a multiboot store, do not assume {default} is this Windows installation. Identify the loader referenced by {bootmgr} and its menu whose device and osdevice resolve to the verified Windows volume. Confirm its path is \Windows\System32\winload.efi on UEFI or \Windows\System32\winload.exe on BIOS and systemroot is \Windows. Correlate the BCD device identity with the detected volume; do not require the literal WinRE letter W: to appear. If those objects and files are correct, stop modifying BCD. If they are wrong or the store cannot be opened, route to FIX-031; that is a separate boot-path defect.

14. Try nonpersistent Safe Mode: Troubleshoot > Advanced options > Startup Settings > Restart > Enable Safe Mode. Do not create a persistent safeboot BCD setting.

15. Interpret the result:

    • If Safe Mode and then two normal starts work, Windows successfully re-enumerated its core path; continue verification.
    • If Safe Mode works but normal mode returns 0x7B, a non-core driver, service, or filter is more likely. Use Branch D.
    • If Safe Mode also returns 0x7B, use the update, file-system, or boot-critical service branch supported by the evidence.

Branch A — The failure immediately followed a Windows update

1. In WinRE, select Troubleshoot > Advanced options > Uninstall Updates.

2. Select Uninstall latest quality update when the failure followed a monthly/cumulative update. Select Uninstall latest feature update only when a feature-version change is the demonstrated trigger.

3. Restart once and record the result.

4. If the interface cannot complete, return to Command Prompt and capture servicing evidence:

   md W:\BootRepairBackup
   copy W:\Windows\Logs\DISM\dism.log W:\BootRepairBackup\dism-before-revert.log
   copy W:\Windows\Logs\CBS\CBS.log W:\BootRepairBackup\cbs-before-revert.log
   dism /Image:W:\ /Get-Packages /Format:Table > W:\BootRepairBackup\packages-before-revert.txt
   

5. Proceed only if the timing matches a failed update and DISM shows an Install Pending or Uninstall Pending package. Revert incomplete offline servicing:

   dism /Image:W:\ /Cleanup-Image /RevertPendingActions
   

6. Restart once. If the same 0x7B remains, do not rename pending.xml, delete servicing registry values, or mass-remove packages under this general procedure. Use System Restore or a verified system image.

Branch B — A stable volume has demonstrated logical file-system corruption

1. Confirm that the disk is consistently detected, important data is backed up, and no timeout, surprise-removal, CRC, bad-block, or I/O-error evidence is continuing.

2. Run a corrective pass only because the read-only check reported logical errors:

   chkdsk W: /f
   

3. Set <boot-volume> to the detected boot partition: S for a separate UEFI ESP or BIOS system partition, or W when the BIOS active system volume is the Windows volume. Verify protected files without repairing them first:

   sfc /verifyonly /offbootdir=<boot-volume>:\ /offwindir=W:\Windows /offlogfile=R:\sfc-verify-0x7B.txt
   

4. If SFC confirms integrity violations and the storage path remains stable, repair them:

   sfc /scannow /offbootdir=<boot-volume>:\ /offwindir=W:\Windows /offlogfile=R:\sfc-repair-0x7B.txt
   

5. Restart twice. Do not start with chkdsk /r on a disk that might be failing; it reads the entire device and is not the first data-preservation action.

Branch C — An inbox boot-critical service has a demonstrated incorrect Start value

Microsoft expects the offline ACPI, DISK, VOLMGR, PARTMGR, VOLSNAP, and VOLUME service keys to exist and have Start=0 in the control set used for startup.

1. Confirm that R: is the verified external backup volume, then copy the complete offline SYSTEM hive before loading it:

   dir R:\
   md R:\BootRepairBackup
   copy /v W:\Windows\System32\Config\SYSTEM R:\BootRepairBackup\SYSTEM-before-generic-0x7B
   

2. Load the hive and find its default startup control set:

   reg load HKLM\OfflineSystem W:\Windows\System32\Config\SYSTEM
   reg query HKLM\OfflineSystem\Select /v Default
   

   From this point, if any registry command fails, more than one service value is abnormal, or the next action is to stop, run reg unload HKLM\OfflineSystem. Do not restart until that unload succeeds.

3. Convert the result to the matching name: 0x1 means ControlSet001, 0x2 means ControlSet002, and so on. Substitute that exact name for <ControlSet00n> below.

4. Inspect all six required keys:

   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\ACPI /v Start
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\DISK /v Start
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\VOLMGR /v Start
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\PARTMGR /v Start
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\VOLSNAP /v Start
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\VOLUME /v Start
   

5. If all return REG_DWORD 0x0, make no change and unload the hive:

   reg unload HKLM\OfflineSystem
   

6. If exactly one existing inbox service has a demonstrated wrong value, export only that service key to the external volume, correct only its Start value, query it again, and unload the hive. This example uses DISK; replace it only with the specifically incorrect inbox service:

   reg export HKLM\OfflineSystem\<ControlSet00n>\Services\DISK R:\BootRepairBackup\DISK-service-before.reg /y
   reg add HKLM\OfflineSystem\<ControlSet00n>\Services\DISK /v Start /t REG_DWORD /d 0 /f
   reg query HKLM\OfflineSystem\<ControlSet00n>\Services\DISK /v Start
   reg unload HKLM\OfflineSystem
   

7. Restart only after the verification query reports REG_DWORD 0x0 and the unload succeeds. If a required service key is missing rather than merely misconfigured, unload and stop. Do not synthesize it and do not replace SYSTEM with an unverified RegBack copy.

Branch D — An exact third-party boot or storage filter is demonstrated

Use this branch only when Safe Mode works or the timing, dump, service name, and product identity all identify a specific recently installed, updated, or partly removed backup, imaging, security, encryption, or disk utility.

1. Prefer System Restore to a restore point immediately before the product or driver change.

2. If Safe Mode starts, create an inventory:

   md "%SystemDrive%\BootRepairBackup"
   pnputil /enum-drivers > "%SystemDrive%\BootRepairBackup\third-party-drivers-before.txt"
   pnputil /enum-devices /problem > "%SystemDrive%\BootRepairBackup\problem-devices-before.txt"
   pnputil /? | findstr /i "/files"
   

   Run pnputil /enum-drivers /files only when the help output lists /files; that option is not available on every supported Windows 10 build.

3. Uninstall the exact product normally from Settings > Apps when it supplies the filter. Restart and verify before deleting a driver package.

4. If the product is gone but its exact published driver package remains, create a package-specific directory, export that package, and verify the exported INF before removal:

   md "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>"
   pnputil /export-driver <oem-number.inf> "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>"
   dir "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>\*.inf"
   pnputil /delete-driver <oem-number.inf> /uninstall
   

   Record the exact exported INF filename as <exported-driver.inf>. Hard-stop before deletion if export fails or the package-specific directory does not contain its INF.

5. If Windows cannot start in Safe Mode, or the repair would require editing offline UpperFilters or LowerFilters, stop this general article and use FIX-027. That dedicated procedure establishes the exact filter, external hive backup, class-key export, unload behavior, and rollback.

6. Do not disable a filter service while leaving its filter registration present; that mismatched state can itself produce 0x7B.

7. If the exact filter, service, product, and rollback package cannot all be demonstrated, use System Restore or image recovery instead of guessing.

Branch E — The disk is unstable or absent

1. Stop all corrective writes.

2. Power down and verify the physical connection only if that can be done safely and without changing controller mode or disk order.

3. If the disk becomes readable, capture or image irreplaceable data before CHKDSK, SFC, DISM, driver removal, or registry repair.

4. If the device remains absent, times out, reports bad blocks, or disappears again, use device/OEM diagnostics and a data-recovery or replacement path. A Windows command is not an 80%-certainty solution for failing media.

• Safe Mode followed by two normal starts succeeds: The minimal boot allowed Windows to enumerate a usable path. Continue log and disk verification.
• Removing or reverting the demonstrated update resolves the stop: Record the KB/package and investigate that update before reinstalling it.
• CHKDSK repairs logical errors and normal startup succeeds: The file-system defect was causal or blocking. Continuing I/O events mean the underlying device still needs attention.
• Correcting one demonstrated inbox service Start value resolves the stop: Preserve the before/after registry evidence; do not change the other services.
• Removing the exact third-party filter resolves normal boot: Update, replace, or retire that product before reinstalling it.
• The code changes to 0xc000000e, 0xc000000f, or 0xc0000225: Windows is now failing earlier. Use the boot-path evidence and FIX-031 instead of continuing generic 0x7B repairs.
• The disk reports new timeouts, CRC errors, retries, or surprise removal: Stop. The risk has shifted from logical startup repair to data preservation and hardware diagnosis.

• Do not rebuild BCD merely because the stop code is 0x7B.
• Do not change SATA/AHCI/controller mode to see whether the code changes.
• Do not run chkdsk /f /r as the first action on an unstable HDD or SSD.
• Do not mass-remove updates, drivers, services, or filter entries.
• Do not delete an entire UpperFilters or LowerFilters value when only one proven third-party line is at fault.
• Do not disable a filter's service while leaving that filter registered.
• Do not copy SYSTEM from RegBack unless it is a verified backup made from this installation; automatic RegBack population is disabled by default on modern Windows 10/11.
• Do not initialize, clean, convert, format, or repartition the Windows disk.

System Restore is the preferred rollback for driver, filter, and update branches. A RevertPendingActions, CHKDSK correction, or SFC repair has no simple command that restores every changed byte; require a verified backup or image before those writes.

To reverse a specific offline service edit, load the same hive name, import its external export, verify the restored value, and unload it:

reg load HKLM\OfflineSystem W:\Windows\System32\Config\SYSTEM
reg import R:\BootRepairBackup\<exported-key>.reg
reg query HKLM\OfflineSystem\<ControlSet00n>\Services\<service-name> /v Start
reg unload HKLM\OfflineSystem

If the import or verification query fails, still unload the hive. Do not restart until reg unload succeeds.

If the hive cannot be loaded after an edit, restore the complete saved hive from WinRE:

copy /v /y R:\BootRepairBackup\SYSTEM-before-generic-0x7B W:\Windows\System32\Config\SYSTEM

If an exact third-party driver package must be restored after Windows starts, use its exported INF package:

pnputil /add-driver "%SystemDrive%\BootRepairBackup\DriverRollback\<oem-number>\<exported-driver.inf>" /install

Do not restore a package that recreates the original 0x7B without first obtaining a corrected version.

• Windows reaches sign-in after two consecutive normal restarts and one full shutdown/cold start.
• The physical Windows disk remains present with the expected identity and capacity.
• No new System events 7, 11, 15, 55, 98, 129, 153, or 157 appear.
• Online chkdsk %SystemDrive% /scan reports no new file-system corruption after Windows starts.
• If SFC repaired files, online sfc /verifyonly reports no remaining integrity violation.
• Any reverted update, corrected service, or removed filter is recorded by exact KB, service, product, and driver package.
• BCD was left unchanged unless a separate, demonstrated boot-path defect was repaired.

Confidence is high when a demonstrated pending update, logical file-system defect, incorrect inbox service value, or exact third-party filter can be reversed and the machine then passes repeated boots. Confidence is moderate when 0x7B is confirmed but no branch has corroborating evidence. Stop if the disk is absent, RAW, intermittent, or returning 0xc000009c, 0xc000009d, 0xc00000b5, 0xc0000185, repeated I/O events, or bad-block reports; if the active control set or exact filter is unknown; if a required service key is missing; if data is not backed up before writes; or if RAID, SCSI, VMD/IRST, Storage Spaces, controller change, clone, or migration is discovered.