Fix 0X000009C7 Boot Failure: PXE vs BIOS Conflict
Your PC won't boot due to a network boot order conflict. The fix is disabling PXE in BIOS or fixing the boot device list. Here's how.
Cause 1: Network Boot (PXE) Runs Before Local Drive
This is the most common trigger. 0X000009C7 appears after a BIOS update, drive replacement, or CMOS reset. What's actually happening here is the system's boot order changed. It now tries to boot from the network (PXE) before checking your SSD or HDD. The workstation fails because no PXE server exists on your network to deliver an OS image.
I see this constantly on HP Z-series workstations and Dell Precision models after a BIOS update. The BIOS resets to defaults, and those defaults often enable network boot as the first option. The error code itself is a hardware-specific halt – the system found a network controller, attempted PXE, found no DHCP offer, then panicked instead of falling back to the next boot device.
The Fix: Disable PXE or Change Boot Order
- Reboot and mash F2, F10, F12, or Del (depends on your motherboard). On HP it's usually F10, on Dell it's F2.
- Navigate to Boot Order or Boot Sequence.
- If you see Network Boot or PXE Boot at position 1, move it to the bottom. Set your OS drive (Windows Boot Manager or the SSD/HDD) as first.
- Save and exit. Reboot.
If the error persists, go back and disable PXE entirely:
- HP BIOS: Advanced → Built-in Device Options → Disable Network (PXE) Boot.
- Dell BIOS: System Configuration → Integrated NIC → Set to Disabled or PXE Off.
- Lenovo ThinkStation: Devices → Network Setup → Disable Pxe Boot to LAN.
The reason step 3 works is it forces the firmware to skip the network controller entirely. PXE is a legacy feature from the era when IT departments booted diskless workstations from a central server. You don't need it unless you're doing enterprise imaging.
Cause 2: Corrupted or Disconnected Boot Drive
If PXE is already disabled and you still get 0X000009C7, the system can't find a bootable drive. This happens after a failed Windows update, a sudden power loss during boot, or a loose SATA/NVMe cable. The error code then means: firmware finished hardware POST, found no bootable device, and threw this specific halt.
I've also seen this on systems where the OS drive was replaced but the BIOS still points to the old drive's signature. The boot device list in NVRAM is stale.
The Fix: Check Physical Connection and Boot Configuration
- Power down, unplug the power cord, open the case. Reseat the SATA cable on both ends (drive and motherboard) or the NVMe SSD. If it's a SATA drive, swap the cable with a known good one. I've fixed three machines this year alone with a loose cable – the error code was exactly this.
- Reboot and enter BIOS. Check if the drive appears under Storage or Drives. If it doesn't, the drive is dead or the motherboard port is bad. Try a different SATA port.
- If the drive appears, go to Boot Override or Boot Menu and manually select the Windows Boot Manager entry (not the drive name).
- If Windows Boot Manager is missing, you need to rebuild the boot sector. Boot from a Windows installation USB, open Command Prompt (Shift+F10), and run:
bootrec /fixmbr bootrec /fixboot bootrec /rebuildbcd - If
/fixbootgives Access Denied, run this first:bootsect /nt60 SYS
The real fix here is /rebuildbcd. It scans all drives for Windows installations and rebuilds the Boot Configuration Data. This is what actually resolves the stale boot signature issue.
Cause 3: UEFI vs Legacy Boot Mode Mismatch
This one trips up people who swap drives between systems. Your OS was installed in UEFI mode (GPT partition table), but the BIOS is set to Legacy (CSM) mode. Or vice versa. The firmware finds the drive, sees the partition table doesn't match the boot mode, and halts with 0X000009C7.
I've encountered this most often when someone takes a drive from a newer Dell and puts it in an older HP. The older BIOS defaults to Legacy/CSM, but the drive is GPT. The result: no bootable device found, same error code.
The Fix: Match BIOS Boot Mode to OS Partition Style
- Enter BIOS. Look for Boot Mode or UEFI/BIOS Boot Mode.
- If the OS was installed on a GPT drive, set to UEFI (disable CSM). If the OS was installed on an MBR drive, set to Legacy or CSM Enabled.
- How to check which partition style your drive uses? If you have a bootable USB with a Windows installer, at the language screen press Shift+F10, run:
diskpart list diskLook at the Gpt column. An asterisk (*) means GPT (needs UEFI). No asterisk means MBR (needs Legacy).
- If you're in the wrong mode, change it and save. The system should boot.
If you absolutely need Legacy boot on a GPT drive (some old software forces this), you can't – the firmware won't do it. You'd need to reinstall Windows in Legacy mode, which reformats the drive to MBR. Don't do that unless you have to. Windows 10 and 11 run better on UEFI.
Quick-Reference Summary
| Cause | What to Do | Where in BIOS |
|---|---|---|
| Network boot first | Disable PXE or move local drive to top | Boot Order / Built-in Devices |
| Corrupted boot record | Run bootrec /rebuildbcd from USB | Windows Recovery Environment |
| Partition mode mismatch | Switch BIOS between UEFI and Legacy | Boot Mode / CSM Setting |
Start with Cause 1. It fixes 80% of 0X000009C7 errors. If that fails, move to Cause 2 and check the drive physically. Cause 3 is the least common but the most frustrating – get it right and you're golden.
Was this solution helpful?