Windows can lose access to its system volume during startup when that volume sits behind a storage controller whose boot-critical driver is absent, disabled, damaged, or replaced with an incompatible version. Common examples are Intel Volume Management Device (VMD), Intel Rapid Storage Technology (IRST/RST), and OEM RAID controllers.

This condition is about the controller path, not whether the drive is an HDD or SSD. A SATA HDD, SATA SSD, or NVMe SSD can all be hidden behind a controller that requires a specific driver. It is also not the same as changing AHCI/RAID/VMD mode in firmware: if a setting was changed immediately before failure, restoring the recorded original setting is safer than injecting a driver.

Use this procedure when firmware consistently detects the physical system drive, WinRE or Setup cannot see it until a particular OEM storage driver is loaded, and the controller hardware ID and driver package match. It also applies when an update or image deployment removed the required boot-critical package and comparative evidence shows the disk becomes visible after drvload.

Do not use it when the drive is absent in firmware, intermittently disappears, reports hardware errors, or became unbootable immediately after a known firmware controller-mode change that can safely be reversed. Do not use a VMD/IRST package merely because the computer has an Intel processor. AMD RAID, Microsoft inbox AHCI/NVMe, and OEM add-in controllers require different evidence.

It does not apply to a corrupt file system, wrong BCD device reference, deleted EFI partition, USB-attached ordinary Windows installation, or a network/SAN boot path.

The exact Windows build and the event that removed the driver may remain unknown during diagnosis. Before adding anything, the controller vendor, hardware ID, processor architecture, offline Windows volume, and exact INF package must be known. The package must come from the system or controller manufacturer for the exact model or hardware ID.

Related cases:

  • Make Windows Setup detect an NVMe or SSD by loading the correct VMD/IRST storage driver

Before you start:

  • Current Windows 10/11 installation or recovery media
  • The extracted OEM storage-driver folder containing .inf, .sys, and catalog files
  • A separate USB drive if the recovery media does not contain the driver
  • A backup of important data
  • Administrative Command Prompt
  • The original firmware storage setting recorded and left unchanged

Boot the recovery or installation media, choose Repair your computer > Troubleshoot > Advanced options > Command Prompt, and disconnect unrelated external storage. Keep the system disk, recovery media, and driver USB connected.

Do not switch AHCI, RAID, or VMD settings while diagnosing. Use D: for the driver USB and W: for offline Windows only after those letters have been detected as free and assigned to the correct volumes.

Do not disable VMD/RAID blindly, install a driver for a similar model, use /ForceUnsigned, change registry Start values for guessed services, run clean, or reinstall Windows before preserving data. Do not assume an NVMe SSD always uses Microsoft’s inbox NVMe path.

Stop for ambiguous hardware IDs, unsigned packages, intermittent firmware detection, I/O errors, or an enterprise-managed RAID image whose recovery procedure is not authorized.

Check the cause

  1. Record the full blue-screen or recovery message and the change immediately before it.

  2. In DiskPart, capture current visibility:

    diskpart
    list disk
    list volume
    rescan
    list disk
    exit
    
  3. If the expected disk is missing, locate the extracted driver folder:

    dir D:\ /s /b *.inf
    
  4. Load only the exact controller INF into the current WinRE/WinPE session:

    drvload "D:\Drivers\<exact-folder>\<driver.inf>"
    
  5. Rescan:

    diskpart
    rescan
    list disk
    list volume
    
  6. The diagnosis is supported only if the expected physical disk appears after the matching driver loads. Stop if the disk remains absent; do not try random INFs.

  7. Identify the existing Windows volume from size, contents, and physical-disk mapping. Assign an unused letter:

    select volume <Windows-volume-number>
    detail volume
    assign letter=W
    exit
    
  8. Verify it:

    dir W:\Windows\System32\Config\SYSTEM
    dir W:\Windows\System32\drivers
    
  9. Check the volume without repair switches:

    chkdsk W:
    

    Stop for RAW, I/O errors, or unstable detection.

Repair steps

Loading the matched storage driver does not require generic Secure Boot disablement or erasing the Windows disk. Those unrelated source branches are excluded from this guide.

  1. Copy the exact driver package to a stable local or USB folder. Do not point DISM at a directory containing unrelated model packages when an exact INF is known.

  2. Inventory third-party drivers already staged in offline Windows:

    dism /Image:W:\ /Get-Drivers /Format:Table
    
  3. Add the verified package:

    dism /Image:W:\ /Add-Driver /Driver:"D:\Drivers\<exact-folder>\<driver.inf>"
    

    Use /Recurse only when the OEM package explicitly requires several related INFs in a clean, model-specific folder:

    dism /Image:W:\ /Add-Driver /Driver:"D:\Drivers\<model-folder>" /Recurse
    
  4. Record the published name returned by DISM and verify it:

    dism /Image:W:\ /Get-Drivers /Format:Table
    dism /Image:W:\ /Get-DriverInfo /Driver:<oem-number>.inf
    
  5. Do not change BCD merely because Windows displayed 0x7B. If BCD was independently implicated and remains readable, export it before any separate BCD repair.

  6. Close Command Prompt, remove only the driver USB and recovery media, and boot once with the original controller setting.

  7. If Windows starts, install the current complete OEM storage package inside Windows, restart, and verify the controller and disk in Device Manager.

Verify the result

Verify three cold starts and one restart. Confirm the system disk remains visible, no INACCESSIBLE_BOOT_DEVICE recurs, Device Manager shows the expected controller without an error, and storage events do not show new resets or timeouts. Retain the exact package and the before/after DISM inventories.

  • Disk appears after drvload, DISM succeeds, and Windows boots: the missing package was a strong causal match.
  • Disk appears in WinRE but Windows still stops with 0x7B: the package may not match the installed controller instance, another boot-critical filter may be involved, or the file system/storage is damaged. Preserve logs and stop random injection.
  • Disk never appears after the exact package loads: investigate firmware detection, cabling/power, hardware, controller configuration, or a different driver family.
  • DISM says the package is already installed: compare version, provider, hardware ID, and service state; do not repeatedly add it.

Undo the change if needed

If Windows becomes less bootable after injection, return to WinRE, identify the newly added published name from the recorded DISM output, and remove only that package:

dism /Image:W:\ /Remove-Driver /Driver:<oem-number>.inf

Do not remove a package that existed before this procedure. If a full image backup was made, restoring it is the preferred rollback for a complex storage stack.