NETWORK_BOOT_DUPLICATE_ADDRESS 0x000000BC and PXE boot failures on WDS

Fix it now

0x000000BC means the network boot code sent an ARP request for the address it had just been given and another machine answered for it. That is fatal during a network boot. The companion codes are not addressing failures at all, and each carries a parameter that says which step failed.

arp -a
Get-DhcpServerInDC
Get-DhcpServerv4Lease -ScopeId <scope> | Where-Object AddressState -like '*Bad*'

1. Work out which address is duplicated. arp -a on a machine on the same segment shows which MAC currently answers for it; the DHCP lease list shows who was meant to have it.
2. Look through the scope for BAD_ADDRESS entries in the DHCP console. Those are the server telling you it has already detected a conflict.
3. Remove any static reservation that overlaps the dynamic range, and exclude the block used by statically configured devices with New Exclusion Range on the scope.
4. Turn on conflict detection: DHCP console, right-click the IPv4 node, Properties, Advanced, and set Conflict detection attempts to 1 or 2.
5. If the stop code is 0x000000BB or 0x000000F8 rather than 0xBC, the address was fine. Read parameter 1 of the bug check – on both codes it names the step that failed – before touching the image.

Conflict detection makes the server ping each address before offering it, which adds delay to every lease. One or two attempts is a fair trade during an imaging project; leaving it high on a busy scope is not.

If two machines now PXE boot in a row without a stop code, you are done. If not, the next section walks the network boot path and shows where each code sits on it.

Why it happens

A PXE boot involves more DHCP traffic than people expect. The adapter’s own PXE client requests an address and, separately, discovers where to fetch a boot program. It downloads that program, which loads a boot image over TFTP or HTTP. Windows PE then comes up inside a RAM disk and starts its own network configuration, which may request an address again.

0x000000BC is raised on that path. Microsoft publishes it precisely: when TCP/IP sent out an ARP request for its IP address, it received a response from another machine indicating a duplicate IP address – and when Windows is booting off a network, that is a fatal error. The parameters are unusually useful here. Parameter 1 is the IP address as a DWORD, so an address aa.bb.cc.dd appears as 0xDDCCBBAA. When parameter 4 is zero the connection is Ethernet and the other machine’s MAC address is spread across parameters 2 and 3.

The other three codes are later failures on the same path and none of them is about addressing. 0x000000BB, NETWORK_BOOT_INITIALIZATION_FAILED, means Windows failed to boot off a network, and parameter 1 says where: 1 is a failure updating the registry, 2 is a failure starting the network stack – Windows sends IOCTLs to the redirector and datagram receiver and times out waiting for the redirector to be ready – and 3 is a failure sending the DHCP IOCTL to TCP. Parameter 2 is the failure status.

0x000000F8, RAMDISK_BOOT_INITIALIZATION_FAILED, is an initialisation failure while attempting to boot from the RAM disk, and again parameter 1 identifies the step: no LoaderXIPRom descriptor in the loader memory list, unable to open ramdisk.sys, FSCTL_CREATE_RAM_DISK failing, unable to create a GUID string, or unable to create the symbolic link to the RAM disk device. 0x00000100, LOADER_BLOCK_MISMATCH, means the loader block is invalid or does not match the system being loaded, with the block’s major and minor version in the parameters – which is what mixing boot files from different releases produces.

Full reference

Decoding the parameters, which is faster than guessing

An address of the form aa.bb.cc.dd appears in parameter 1 of 0xBC as 0xDDCCBBAA, so read the bytes back to front. A MAC of aa-bb-cc-dd-ee-ff makes parameter 2 read 0xAABBCCDD and parameter 3 read 0xEEFF0000. That is enough to identify the offending machine from the stop screen alone, without touching DHCP.

Where WDS should sit relative to DHCP

Microsoft’s position on this is explicit and it settles a long-running argument. Setting DHCP option 60 to PXEClient, with options 66 and 67 naming the boot server and boot file, makes the client attempt to contact port 4011 on the DHCP server – which fails if the PXE server is a different machine. Microsoft states it does not support using these options on a DHCP server to redirect PXE clients, and gives the resolution as removing them and configuring the router’s IP helper table with the PXE server’s address.

That also solves the practical problem those options create. A boot file name hard-coded in a DHCP option cannot be right for BIOS and UEFI clients at the same time, whereas a server that receives the request itself can decide what to send.

Commands worth having open

Things worth checking that are not documented as causes

• Excluding the RemoteInstall folder from on-access antivirus scanning. A scanner holding a WIM open during transfer is a plausible source of truncated downloads, but it is engineering judgement rather than a published cause.
• Switch port configuration. Spanning tree convergence on a port without portfast can outlast the PXE client’s patience, which looks like a server problem.
• Link speed and duplex mismatches on older switches, which produce transfers that start and stall.
• Whether the boot image was ever re-added after a servicing update to the WIM. A partially updated image is a good candidate for a loader block mismatch.

Changes to DHCP scopes, exclusions and conflict detection affect every device on the subnet, not only the machines you are imaging. Make them in a maintenance window and write down what you changed so it can be reversed.

Every code this article covers

Confirm the fix worked

1. PXE boot two machines one after the other and confirm both reach the Windows PE stage without a stop code.
2. No new BAD_ADDRESS entries appear in the scope during the test.
3. arp -a from a machine on the same subnet maps each address to exactly one MAC.
4. The WDS event log records successful image transfers matching your test boots.
5. A UEFI client and a legacy BIOS client, if you have both, each receive the right network boot program.

Questions people ask about this