Recover INACCESSIBLE_BOOT_DEVICE after a SATA controller-mode change

Windows begins loading and then stops with INACCESSIBLE_BOOT_DEVICE because the firmware's SATA controller mode no longer matches the storage-driver path Windows was prepared to use. This can affect any SATA system disk—hard disk or solid-state drive. The media type is incidental; the controller presentation and boot-critical driver are what changed.

This writeup uses controller mode to mean a setting such as AHCI, IDE/compatibility, or a vendor RAID mode. It does not mean changing the computer between UEFI and legacy BIOS boot. UEFI versus BIOS is separately detected from the disk and system-partition layout when boot repair depends on it.

Searchable Windows error codes and exact messages

Search the complete stop code plus the motherboard or computer model and the exact controller setting that changed. Do not treat 0x7B alone as proof of an AHCI problem; missing boot-start drivers, corrupt storage filters, cloning, and failing hardware can produce the same code.

Use this procedure when the Windows disk remains consistently visible and the failure began immediately after a firmware reset, BIOS update, CMOS reset, motherboard setting change, or intentional change among AHCI, compatibility, and vendor controller modes. The strongest confirmation is that restoring the recorded previous mode makes Windows boot again.

Do not use the migration branch when the previous mode is unknown, the disk disappears, diagnostics report a disk fault, or the machine uses a RAID array, Intel VMD/IRST, enterprise HBA, SCSI, or another specialist storage stack. Restore the known working setting if possible and use the device or platform documentation. Do not use this procedure merely because the boot disk is an SSD.

The exact Windows build, disk media type, and reason the firmware setting changed may remain unknown. The current setting, the last known working setting, whether the disk is consistently detected, and whether RAID/VMD is involved may not remain unknown.

• Access to firmware setup and the ability to record settings before changing them
• Windows Recovery Environment or installation media
• A consistently detected Windows disk
• Administrator access if Windows can start under the old mode
• A BCD backup before setting a persistent Safe Mode option
• The platform's storage driver available if this is an intentional supported migration

First record the current controller setting with a photograph. If the prior setting is known, restore that exact setting before attempting Windows repairs. Do not rotate through every available mode to see what happens.

1. Record the stop code and all four parameters if displayed.

2. In firmware setup, confirm that the correct physical disk is visible with the expected model and capacity.

3. Record, without changing, the SATA/controller setting. Common labels include SATA Mode, Configure SATA as, Storage Controller Mode, AHCI, IDE, Compatibility, RAID, and vendor-specific VMD/IRST controls.

4. If the last working setting is known, select it, save, and restart once.

5. Interpret the result:

   • If Windows starts under the old mode and fails with 0x7B under the new mode, the diagnosis is confirmed.
   • If neither mode starts and the disk is readable in WinRE, inspect BCD and the file system; another boot failure may coexist.
   • If the disk disappears or changes identity, stop. Firmware mode is not a repair for an unstable device, connector, slot, cable, or power path.

6. If Windows starts under the old mode, preserve BCD from an elevated Command Prompt:

   md C:\BootRepairBackup
   bcdedit /export C:\BootRepairBackup\BCD-before-controller-change
   

7. Confirm the current loader before modifying it:

   bcdedit /enum {current} /v
   

Branch A — The change was accidental

1. Leave the controller in the last known working mode.

2. Start Windows twice.

3. Check the System event log for storage events 11, 15, 129, and 153 during the failed and successful starts.

4. If no further errors occur, document the required firmware setting. No registry edit, BCD rebuild, or storage-driver replacement is necessary.

5. If a firmware update or CMOS reset repeatedly changes the setting, update the firmware configuration deliberately and save a firmware profile if the platform supports one.

Branch B — Intentionally migrate a non-RAID SATA installation to AHCI

Use this branch only when the old mode still boots, the target mode is standard AHCI, no RAID array or VMD/IRST dependency exists, and the hardware vendor supports the change.

1. Boot Windows under the known working controller mode.

2. Create the BCD backup shown in section 7.

3. From an elevated Command Prompt, force the next Windows start into minimal Safe Mode:

   bcdedit /set {current} safeboot minimal
   

4. Verify that safeboot now appears:

   bcdedit /enum {current}
   

5. Restart directly into firmware setup. Do not let Windows complete another normal start under the old mode.

6. Change only the intended SATA controller setting to AHCI. Do not change UEFI/legacy boot mode, Secure Boot keys, partition settings, or boot-disk order at the same time.

7. Save and start Windows. It should enter Safe Mode and enumerate the AHCI path.

8. In Safe Mode, open an elevated Command Prompt and remove the persistent Safe Mode option:

   bcdedit /deletevalue {current} safeboot
   

9. Confirm that safeboot is absent:

   bcdedit /enum {current}
   

10. Restart normally twice.

11. Open Device Manager and confirm that the storage controller has no warning icon. Use the computer or motherboard vendor's supported driver when Windows identifies a device problem; do not install a random storage package based only on a similar controller name.

• Restoring the old mode boots Windows: The mode mismatch is resolved. Leave it there unless a supported migration has a concrete benefit.
• Safe Mode starts after changing to AHCI and normal mode then starts: Windows successfully enumerated the new controller path.
• Safe Mode also stops with 0x7B: Immediately restore the old mode. The required target driver may be absent or the platform may use a vendor storage stack.
• The code changes to 0xc000000f, 0xc0000225, or 0xc0000098: Inspect the boot store and detected system partition. Do not assume the new code is still a controller problem.
• Storage events continue after returning to the working mode: Investigate disk health, cabling, slot, power, firmware, and the controller driver.
• RAID, VMD, or IRST is discovered: Stop this general procedure. Retain the working setting and move to the specialist branch in the catalog.

• Do not cycle through controller modes without recording the original.
• Do not use storahci registry edits copied from an unrelated guide as the first repair.
• Do not switch UEFI/legacy boot mode while changing the SATA mode.
• Do not rebuild BCD merely because the stop code is 0x7B.
• Do not disable VMD/IRST on a system that depends on it without a prepared migration and recovery path.
• Do not call this an SSD-specific failure; SATA HDDs are affected the same way.

If the AHCI migration fails, return firmware to the recorded working controller mode. If Windows then enters Safe Mode because the BCD option remains, sign in and run:

bcdedit /deletevalue {current} safeboot

The controller migration changes only the safeboot value; deleting that value is the preferred rollback. If Windows boots under the restored old mode but its BCD store was separately damaged, import the saved store from an elevated prompt in that running Windows installation:

bcdedit /import C:\BootRepairBackup\BCD-before-controller-change

• Windows starts normally twice under the intended controller mode.
• The system disk remains present with the expected model and capacity.
• bcdedit /enum {current} contains no unintended safeboot value.
• Device Manager shows no storage-controller problem.
• System event logs show no recurring controller resets or I/O retries.
• A cold start, not just Restart, also succeeds.

Confidence is high when the failure can be switched on and off solely by selecting the old versus new controller setting. Confidence is moderate when timing suggests a firmware reset but the old setting is not documented. Stop if the disk disappears, the prior mode is unknown, Safe Mode still produces 0x7B, a RAID/VMD dependency appears, or hardware diagnostics fail.