Recover INACCESSIBLE_BOOT_DEVICE on a Windows SAN or iSCSI network-boot installation

Issue

A diskless or SAN-boot Windows client can start through iPXE, UEFI iSCSI, an iSCSI HBA, or another preboot path and then stop when Windows takes control because the network and storage path is not available as a boot-critical paging path. This is a specialist deployment problem, not ordinary PXE installation and not consumer Wi-Fi boot.

Searchable Windows error codes and exact messages

Identifier	Name or message	When it can apply
`0x0000007B`	`INACCESSIBLE_BOOT_DEVICE`	Windows lost the SAN/iSCSI system volume during kernel startup.
`0xc000000e`	`STATUS_NO_SUCH_DEVICE`	Boot Manager cannot resolve the network-backed system device.
`0xc0000225`	`STATUS_NOT_FOUND`	A boot device, file, or BCD object cannot be found.
No Windows code	`PXE-E53: No boot filename received`, `PXE-M0F: Exiting PXE ROM`, or an iPXE/UEFI network error	These are firmware/network-loader messages, not Windows error codes; repair DHCP/TFTP/iPXE before Windows.
`0x0000007B` after an NDIS filter change	`INACCESSIBLE_BOOT_DEVICE`	A non-boot-start or paging-I/O-incompatible network filter can break an iSCSI boot adapter.

Applies when

Use only when the Windows 10/11 installation was intentionally deployed for native network/SAN boot, the same target previously booted, and the failure occurs during the transition from preboot networking to Windows storage/network drivers.

Does not apply when

Do not use for ordinary PXE deployment media, local disks, USB disks, cloud VMs, Wi-Fi-only clients, or Windows Server unless a separate Server procedure is intended. Do not retrofit a consumer PC into SAN boot from this article.

Information that may remain unknown

The exact failing packet may remain unknown initially. The initiator identity, target/LUN, VLAN/IP configuration, boot-capable adapter, driver versions, iBFT or HBA configuration, and last known-good image may not remain unknown.

Requirements

Administrator responsible for the SAN/iSCSI environment
Recoverable clone/snapshot of the client image and target
Out-of-band access or local recovery media with the exact NIC/HBA/storage drivers
Known-good comparable client or previous driver inventory
Network capture and target logs when available

Starting position

Freeze changes to the target image, switch, DHCP/iPXE configuration, NIC firmware, and client simultaneously. Select one known failed client and one known-good comparison. Do not edit production LUNs directly.

Confirm the diagnosis

Record whether preboot obtains an address, downloads the boot program, logs into the target, and exposes the correct LUN.
If failure occurs before the Windows logo, fix preboot network/target configuration first.
If Windows starts loading and then displays 0x7B, compare failed and working clients for NIC/HBA hardware ID, firmware, driver, VLAN, initiator name, target portal, LUN, and image version.
Boot recovery media with the exact adapter drivers and load them temporarily with drvload. Confirm both the network adapter and SAN disk become accessible.
Inspect the offline Windows driver inventory:
```
dism /Image:W:\ /Get-Drivers /Format:Table
```
Check whether a recently installed NDIS lightweight filter, endpoint agent, backup filter, or NIC package coincides with the failure. Do not disable arbitrary services.
Validate that the NIC/driver family supports iSCSI boot and paging I/O. Ordinary network connectivity after Windows starts is not sufficient evidence.

Resolution steps

Prefer rollback to the known-good client image or exact driver/filter set. Test the clone, not the only production target.

If the exact missing boot-capable package is proven, add it to the offline clone:

dism /Image:W:\ /Add-Driver /Driver:"D:\Drivers\<exact-package>" /Recurse
dism /Image:W:\ /Get-Drivers /Format:Table

If a specific NDIS filter caused the failure and the vendor confirms it is not iSCSI-boot/paging compatible, remove or update that exact product in the image using its supported offline or vendor method. Do not delete filter registry entries ad hoc.
Restore the exact initiator/target/VLAN configuration from the known-good record.
Boot one isolated test client and capture the full transition.
Promote the corrected image only after two cold boots and a restart succeed on representative hardware.

Expected results and branches

Preboot cannot reach target: network/firmware path, not Windows.
Target is exposed but Windows 0x7B follows: boot-critical NIC/storage/filter path.
Exact driver restores boot: package mismatch was causal.
Only one client fails with identical image: adapter firmware, hardware, cable, switch port, or initiator configuration is more likely.

Do not do this

Do not change production LUN contents without a clone, bind arbitrary filters, convert the target disk, edit guessed service start values, or treat normal iSCSI Initiator service startup as proof of boot-path readiness.

Rollback

Return the test client to the known-good image, driver set, adapter firmware, and initiator/target record. Remove only the package added during this test, using its recorded published name.

Verification

Verify preboot authentication, target/LUN identity, Windows startup, paging, network continuity, and repeated cold boots. Review client and target logs for reconnects, resets, or path loss.

Confidence and stop conditions

Confidence is about 80% only when a controlled comparison isolates one package, filter, or configuration and reversing it changes the boot result. Stop without a cloned target, supported boot-capable adapter, exact driver, or responsible SAN administrator.