Following a Windows Boot Through UEFI and BCD in PVE

Checo9/21/26About 4 min

Following a Windows Boot Through UEFI and BCD in PVE

“BIOS finds the disk; BCD boots Windows” compresses several different responsibilities. PVE’s virtual-device order, UEFI boot entries, and Windows BCD system selection are separate configurations.

On September 21, 2026, I fully cloned a Windows Server template into VM202, disconnected its network, disabled autostart, inspected it read-only, and observed a normal boot. Template VM200 and DC VM201 were untouched. This was static evidence plus boot verification, without firmware execution tracing or ETW boot timing.

An isolated clone

Recorded configuration:

VMID      202
bios      ovmf
machine   pc-q35-11.0
boot      order=scsi0
scsi0     80 GiB, VirtIO SCSI
efidisk0  4 MiB, OVMF variables
TPM       separate 4 MiB state disk
network   link_down=1
onboot    0
memory    4096 MiB

The disconnected link prevented template first-boot routines from reaching AD. Autostart remained off, and a full clone avoided dependence on the template base disk. Host-side disk inspection occurred only after verifying the VM was stopped, using read-only access and releasing mounts and loop devices afterward.

GPT and actual files

The stopped system disk had this layout:

Partition	Size	Type	Verified contents
1	100 MiB	ESP / EF00	FAT32, EFI programs and BCD
2	16 MiB	MSR / 0C01	Reserved, not an ordinary filesystem
3	79.4 GiB	Basic data / 0700	Windows files
4	494 MiB	Recovery / 2700	Type only; recovery files not inspected

These are machine-specific sizes. Host partition numbers do not establish guest drive letters.

Read-only inspection found:

EFI/Boot/bootx64.efi
EFI/Microsoft/Boot/bootmgfw.efi
EFI/Microsoft/Boot/BCD
EFI/Microsoft/Boot/bootmgr.efi

file identified bootmgfw.efi as an x86-64 EFI application and BCD as a Windows registry file. Partition three contained winload.efi and ntoskrnl.exe. BCD is a database; the boot manager is on the ESP, while the OS loader and kernel are on the Windows partition.

efidisk0 is not the ESP

QEMU info block showed distinct objects:

pflash0        OVMF_CODE_4M.secboot.fd (read-only firmware code)
pflash1        drive-efidisk0 (per-VM persistent variables)
scsi0          Windows system disk (including its ESP)

OVMF supplies UEFI. efidisk0 holds persistent firmware variables, not Windows’s FAT32 ESP. A secboot firmware filename alone does not establish that Secure Boot was enabled.

String extraction from the variable disk found BootOrder, Boot0000, Windows Boot Manager, and the bootmgfw.efi path. This proves stored references, not fully decoded device paths or which Boot#### entry actually won during that boot.

Offline BCD inspection

Read-only parsing with regipy found 17 objects, including firmware menus, recovery, and memory testing. Seventeen objects did not mean seventeen installed systems.

The relevant decoded relationships were:

Windows Boot Manager
  path: \EFI\Microsoft\Boot\bootmgfw.efi
  default/displayorder: Windows Server object

Windows Server
  path: \Windows\system32\winload.efi
  systemroot: \Windows
  resumeobject: Windows Resume Application

Windows Resume Application
  path: \Windows\system32\winresume.efi
  hiberfile: \hiberfil.sys

This is an offline summary, not fabricated bcdedit output. Object GUIDs are machine-specific, and encoded device/osdevice data was not fully converted to drive letters. Recovery environments can assign different letters; a later actual bcdedit /enum all /v would provide a cross-check.UEFI BCD configuration

The configuration and files describe a normal path:

OVMF boot entry
  → bootmgfw.efi on the ESP
    → reads BCD and selects Windows
      → winload.efi on the Windows partition
        → kernel and boot-critical drivers
          → logon and desktop

These arrows describe normal mechanism and file relationships, not a captured instruction timeline. UEFI starts an EFI application; Windows Boot Manager reads BCD.Microsoft startup stages

What cold boot demonstrated

Display captures showed a branded splash with Windows dots, Administrator/User Profile Service initialization, then a desktop. A single frame cannot identify the exact executing component at the firmware/Windows boundary.

The template may contain answer-file/autologon behavior, so reaching a desktop does not prove manual password entry. The guest agent never ran, even though Windows reached the desktop: an agent failure is not a boot failure.

After shutdown, System.evtx yielded 550 records, including EventLog 6005/6009 and 6006. EventRecordIDs, XML, QEMU restarts, and guest clock offset were not fully correlated. Two timestamp groups therefore cannot prove an OOBE restart or determine total boot duration. EventLog startup is not the power-on instant.

Map offline objects from inside Windows

Read-only guest checks can relate the observed ESP/BCD to Windows. Use adequate privileges and actual GUIDs/paths rather than changing defaults for inspection:

Get-Disk | Select-Object Number,FriendlyName,PartitionStyle,Size
Get-Partition | Select-Object DiskNumber,PartitionNumber,Type,GptType,Size
bcdedit /enum '{bootmgr}'
bcdedit /enum '{current}'
bcdedit /enum firmware

{bootmgr}, the current loader alias, and firmware entries represent different layers. Runtime evidence is still needed to establish the Boot#### actually selected. Relate device/osdevice to partitions rather than assuming an offline volume is C:.

Reading BCD is different from running bcdboot or deleting entries. Preserve the failed state, partition layout, file hashes, and error screen before repair. Design a one-variable experiment on a copy.

Separate files, visible progress, and timing

Existing bootmgfw.efi/winload.efi establish files; BCD establishes configuration references; a cold-boot login/desktop image establishes that run's visible result. Desktop arrival does not validate networking, Agent, or applications.

Define timing boundaries before measuring: QEMU creation, firmware start, kernel start, login screen, desktop, and service readiness produce different intervals. Approximately 550 event records are not 550 boots. Two timestamps cannot establish every phase duration, and clocks/buffering can affect order.

Question	Additional evidence
Actual firmware entry selection	Runtime firmware evidence and matching variables
Kernel/driver start	Supported boot trace and system events
Slow login service	Timeline, service state, ETW/WPR
Enabled Secure Boot	Guest state and keys/policy, not filename
Failure after storage change	Isolated one-variable fault experiment

The original record did not complete ETW tracing or fault injection. These are research steps separating observed structure from unmeasured runtime behavior, not claims that more desktop screenshots resolve the mechanism.

Choose evidence by failure stage

Symptom	Inspect first
No usable firmware device or entry	Virtual devices, variables, ESP
Boot Manager BCD/loader error	Default object, target device, path
INACCESSIBLE_BOOT_DEVICE after Windows loading	Controller, boot driver, SYSTEM hive
Welcome/logon hang	Services, profiles, logs, ETW

This is an investigation order, not diagnosis from a screenshot. Missing storage drivers and missing EFI executables are different failures; bcdboot does not repair every stage.

Further work could decode UEFI variables structurally, collect OVMF debug output, correlate QEMU block traces, and use WPR/WPA. A block read alone still cannot identify its caller as the BCD parser. Neither fault injection nor those traces occurred in this round.WPR command-line documentation

VM202 finished stopped, disconnected, and without autostart. The useful result was separating three boot orders and distinguishing stored configuration, inferred sequence, and observed successful execution.

Related: DC rebuild and template use.

The article date is the main KB’s first Git commit date, 2026-09-21 (UTC+8), commit 3cddb2c. Experiment dates are stated separately. No production systems were accessed or changed while preparing this article.