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.

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.

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.

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.

Before you start:

  • 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

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.

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.

Stop without a cloned target, supported boot-capable adapter, exact driver, or responsible SAN administrator.

Check the cause

  1. Record whether preboot obtains an address, downloads the boot program, logs into the target, and exposes the correct LUN.

  2. If failure occurs before the Windows logo, fix preboot network/target configuration first.

  3. 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.

  4. Boot recovery media with the exact adapter drivers and load them temporarily with drvload. Confirm both the network adapter and SAN disk become accessible.

  5. Inspect the offline Windows driver inventory:

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

  6. Check whether a recently installed NDIS lightweight filter, endpoint agent, backup filter, or NIC package coincides with the failure. Do not disable arbitrary services.

  7. Validate that the NIC/driver family supports iSCSI boot and paging I/O. Ordinary network connectivity after Windows starts is not sufficient evidence.

Repair steps

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

  2. 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

  3. 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.

  4. Restore the exact initiator/target/VLAN configuration from the known-good record.

  5. Boot one isolated test client and capture the full transition.

  6. Promote the corrected image only after two cold boots and a restart succeed on representative hardware.

Check the result

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.

  • 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.

To undo the change:

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.