Windows 11 bootmgr outgrew legacy PXE memory

NTDEV
1

Hello,

I maintain a custom legacy BIOS PXE/SAN boot environment based on iPXE.

We are not using wimboot in this path. The client starts undionly.kpxe, iPXE exposes a network-backed disk through INT 13h, and the standard Microsoft NTFS boot sector loads the root bootmgr file.

Recent Windows 11 bootmgr files have grown to the point where this boot path is becoming unreliable or impossible on systems where the firmware UNDI remains resident.

Memory layout

undionly.kpxe unloads the PXE base code but intentionally retains the firmware UNDI implementation. On an affected system, iPXE reports approximately 580 KiB of free base memory after unloading PXE, before reserving its own resident 16-bit code and data.

With our current undionly.kpxe build, the relevant layout is:

bootmgr load address:        0x20000
iPXE resident .text16:       [0x8D640, 0x8DF40)
iPXE resident .data16:       [0x8DF40, 0x91000)
free base-memory boundary:   0x91000
retained firmware UNDI:      reserved at or above 0x91000

I also examined the NTFS /nt60 boot-sector template from Microsoft-signed bootsect.exe build 26100.8875.

The boot sector:

  • sets ES to 0x2000,
  • loads the root bootmgr through INT 13h starting at 2000:0000,
  • and finally transfers control to 2000:0000.

Therefore, the raw root bootmgr is loaded from physical address 0x20000 upward. On our 4-KiB-cluster NTFS boot volume, the read size is rounded to the allocated cluster size.

These are the files I tested:

Source image Logical file size Rounded load size Physical load range Clearance before iPXE at 0x8D640
Windows 10 19045.4046 416,284 bytes 0x66000 [0x20000, 0x86000) 30,272 bytes free
Windows 11 26100.1742 442,600 bytes 0x6D000 [0x20000, 0x8D000) only 1,600 bytes free
Windows 11 26100.8875 490,424 bytes 0x78000 [0x20000, 0x98000) overlaps by 43,456 bytes

The exact boundary varies with the firmware-reported free base memory, the iPXE build, and the NTFS allocated size. Therefore, the 26100.1742 file is already marginal and may work or fail depending on the machine.

The 26100.8875 file, however, clearly extends through the complete resident iPXE range and continues 28,672 bytes beyond the 0x91000 free-memory boundary into memory reserved for the retained firmware UNDI.

The failure sequence is therefore:

Microsoft NTFS boot sector
    -> loads bootmgr from 0x20000 through iPXE INT 13h
    -> the larger bootmgr overwrites resident iPXE code and data
    -> bootmgr later performs another disk read
    -> the INT 13h callback reaches corrupted iPXE/UNDI code
    -> boot can no longer continue

With this particular memory layout and 4-KiB NTFS clusters, the maximum logical bootmgr size that fits is 446,464 bytes. Adding even one byte beyond that boundary requires another 4-KiB cluster, which begins overwriting the iPXE resident region.

When the NIC option ROM’s PXE/UNDI implementation is completely unloaded, more conventional memory becomes available—over 600 KiB, and close to the normal 640-KiB boundary on some systems. In that layout, the newer bootmgr can fit.

The problem specifically occurs with the legacy BIOS undionly.kpxe path where the firmware UNDI must remain resident.

Windows 10 bootmgr workaround

As a diagnostic workaround, I replaced only the root bootmgr on the Windows 11 volume with the bootmgr from Windows 10 build 19045.4046.

The following components were left unchanged:

  • BCD store
  • winload.exe
  • Windows kernel
  • the rest of the Windows 11 installation

With only that replacement, the Windows 11 installation boots successfully through the same PXE environment.

I understand that mixing boot-component versions may be unsupported, may omit later security fixes, and may be undone by Windows servicing or boot repair. I am not proposing this as a production solution. It is useful evidence that the failure is directly related to the newer and larger root bootmgr.

I am also aware that the published Windows 11 client hardware requirements call for UEFI and Secure Boot capability. My question concerns the legacy PC/AT bootmgr that is nevertheless still present on the Windows 11 media and successfully starts the Windows 11 installation when the older version is substituted.

Questions

  1. What is driving the continued growth of the legacy BIOS bootmgr?

    Is this simply an expected consequence of additional boot functionality and security mitigations, with no fixed size or conventional-memory-footprint compatibility limit?

    I am not asking for proprietary implementation details. Even confirmation that no such size limit is maintained would be useful.

  2. Is a legacy BIOS PXE environment with a resident PXE/UNDI stack still considered or tested?

    In an undionly.kpxe environment, the firmware UNDI must remain resident and therefore reduces the available conventional memory.

    If this configuration is supported, is there a documented minimum amount of free conventional memory or a required INT 12h/E820 memory layout that the PXE implementation must provide?

    If retained PXE/UNDI is no longer a tested or supported Windows 11 boot scenario, confirmation of that would also answer the question.

  3. What problems could arise from using the Windows 10 bootmgr to start Windows 11?

    Since the Windows 10 19045.4046 bootmgr successfully starts an otherwise unchanged Windows 11 installation, is there any intended forward-compatibility contract between bootmgr and newer BCD/winload.exe versions, or must these components always be treated as a matched set?

    Beyond missing newer boot-manager security fixes and having Windows servicing or boot repair replace the file, could this mixed-version workaround cause problems with:

    • newer BCD elements,
    • recovery or resume,
    • BitLocker or measured boot,
    • future cumulative updates,
    • or future feature updates?

My practical goal is to determine whether we must redesign the PXE loader to reclaim or relocate more conventional memory, or whether there is a documented legacy Boot Manager memory requirement that we have missed.

I would appreciate either technical guidance or a clear statement that this boot path is outside the configurations tested for Windows 11.

Thank you.