Issue
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.
Searchable Windows error codes and exact messages
| Displayed identifier | Windows name or exact message | When it can apply |
|---|---|---|
0x0000007B | INACCESSIBLE_BOOT_DEVICE | Windows reached kernel startup but lost access to the system partition. Missing storage drivers are one possible cause. |
0xc000000e | STATUS_NO_SUCH_DEVICE; often A required device isn't connected or can't be accessed | Boot Manager cannot resolve the device that holds Windows or its loader. |
0xc0000225 | STATUS_NOT_FOUND; often A required device isn't connected or can't be accessed | A required device, file, or BCD object cannot be found. |
| No numeric code | We couldn't find any drives. To get a storage driver, click Load driver. | Windows Setup or recovery media cannot see disks behind the controller. |
| No numeric code | No signed device drivers were found. Make sure that the installation media contains the correct drivers, and then click OK. | The selected folder has no driver accepted for this environment, architecture, or hardware. |
0x80070002 | The system cannot find the file specified | DISM or another servicing command was given an invalid image, INF, or source path. It does not identify a storage-driver defect by itself. |
| No numeric code | The operation completed successfully. | Expected DISM result after a driver package is staged; still verify the package and a successful boot. |
Applies when
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.
Does not apply when
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.
Information that may remain unknown
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.
Requirements
- 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
Starting position
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.
Confirm the diagnosis
-
Record the full blue-screen or recovery message and the change immediately before it.
-
In DiskPart, capture current visibility:
diskpart list disk list volume rescan list disk exit -
If the expected disk is missing, locate the extracted driver folder:
dir D:\ /s /b *.inf -
Load only the exact controller INF into the current WinRE/WinPE session:
drvload "D:\Drivers\<exact-folder>\<driver.inf>" -
Rescan:
diskpart rescan list disk list volume -
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.
-
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 -
Verify it:
dir W:\Windows\System32\Config\SYSTEM dir W:\Windows\System32\drivers -
Check the volume without repair switches:
chkdsk W:Stop for RAW, I/O errors, or unstable detection.
Resolution steps
-
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.
-
Inventory third-party drivers already staged in offline Windows:
dism /Image:W:\ /Get-Drivers /Format:Table -
Add the verified package:
dism /Image:W:\ /Add-Driver /Driver:"D:\Drivers\<exact-folder>\<driver.inf>"Use
/Recurseonly 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 -
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 -
Do not change BCD merely because Windows displayed
0x7B. If BCD was independently implicated and remains readable, export it before any separate BCD repair. -
Close Command Prompt, remove only the driver USB and recovery media, and boot once with the original controller setting.
-
If Windows starts, install the current complete OEM storage package inside Windows, restart, and verify the controller and disk in Device Manager.
Expected results and branches
- 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.
Do not do this
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.
Rollback
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.
Verification
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.
Confidence and stop conditions
Confidence is about 80% when the disk is absent before drvload, appears immediately after loading the exact hardware-matched INF, the same package is staged offline, and repeated boots succeed. 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.