沿着 UEFI 和 BCD 看一次 Windows 启动

Checo2026/9/21大约 7 分钟

沿着 UEFI 和 BCD 看一次 Windows 启动

“BIOS 找盘，BCD 引导 Windows”省略了几层关系。PVE 的虚拟设备顺序、UEFI 的启动项、Windows BCD 的系统选择是三份不同配置。真正打开磁盘和虚拟固件，区别就清楚了。

2026 年 9 月 21 日，我从 Windows Server 黄金模板完整克隆 VM202，断开网卡、关闭自启，完成只读检查和一次正常启动观察。模板 VM200 与域控 VM201未改动。这一轮是静态证据加启动验证，没有固件指令跟踪或 ETW 启动时序。

从隔离实验机开始

现场配置摘录：

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

link_down=1 防止模板首启流程接触现有域，onboot=0 避免实验机随宿主重启。完整克隆避免依赖模板基盘。主机侧挂载系统盘前确认 VM 已停止，只读分析后释放挂载和 loop 设备。

第一份证据：GPT 和真实文件

停止状态下读取系统盘分区表，结果为：

分区	大小	类型	本轮核实内容
1	100 MiB	ESP / EF00	FAT32，EFI 程序和 BCD
2	16 MiB	MSR / 0C01	保留分区，不是普通文件系统
3	79.4 GiB	Basic data / 0700	Windows 系统文件
4	494 MiB	Recovery / 2700	只确认类型，未检查恢复文件

大小是本机事实，不是所有 Windows 安装的固定布局。宿主分区号也不能直接推导 Windows 盘符。

只读 ESP 中存在：

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

file 判断 bootmgfw.efi 为 x86-64 EFI application，BCD 为 Windows registry file。第三分区则有 Windows/System32/winload.efi 和 ntoskrnl.exe。这说明 BCD 是数据库，启动管理器在 ESP，系统加载器与内核在 Windows 分区。

第二份证据：efidisk0 不是 ESP

QEMU 的 info block 现场显示三条不同路径：

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 是该 VM 的 UEFI 固件。efidisk0 保存固件变量，不是 Windows 的 FAT32 ESP。固件文件名带 secboot 也不能单凭名称证明 Secure Boot 当时启用。

变量盘文本提取发现 BootOrder、Boot0000、Windows Boot Manager 和 \EFI\Microsoft\Boot\bootmgfw.efi。这些证明变量里存在对应引用；字符串扫描没有完整解析设备路径，也不能证明当次实际命中了哪个 Boot####。

第三份证据：离线解析 BCD

从停止的实验盘读取 BCD，用 regipy 离线解析出 17 个对象。除了系统项，还包含固件菜单、恢复和内存测试项，所以对象数不是操作系统数量。

关键关系如下，名称是可读整理，未虚构 bcdedit 输出：

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

对象 GUID 是本机标识，device/osdevice 还有编码数据。本轮没有完整解码盘符，不能把十六进制字符串直接解释为 C:。在恢复环境里盘符可能改变，后续可用实际 bcdedit /enum all /v 交叉验证。UEFI BCD 配置

由配置与文件能建立正常启动路径：

OVMF 的启动入口
  → ESP 中 bootmgfw.efi
    → 读取 BCD，选择 Windows 项
      → Windows 分区的 winload.efi
        → 内核与启动必需驱动
          → 登录与桌面

箭头是文件关系与正常机制的说明，不是一条已录制的精确调用轨迹。UEFI 先启动 EFI 应用，Windows Boot Manager 才读 BCD。Microsoft 启动阶段说明

冷启动看到的结果

QEMU 显示输出先出现品牌启动画面与 Windows 圆点，然后是 Administrator / User Profile Service，最后到桌面。单张画面不能判定此刻究竟是固件、Boot Manager 还是内核在执行。

模板可能有首启应答与自动登录，所以桌面不证明手工输入过密码。guest agent 全程未运行，却不妨碍 Windows 到达桌面：Agent 错误与启动失败不是一回事。

正常停止后读取 System.evtx，解析到 550 条记录，包含 EventLog 6005/6009 与 6006。但没有逐条关联 EventRecordID、XML、QEMU 重启记录及来宾时钟偏差，因此不能把两组时间戳写成“确定 OOBE 重启了一次”，也不能用 6005 时间当电源键时刻。

在 Windows 内把离线对象对应起来

离线看到 ESP 与 BCD 后，可以在实验来宾内做只读对应。以下命令需要相应权限，输出中的 GUID 与路径以本机结果为准；不要为了检查直接改默认加载项。

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} 说明 Boot Manager 对象，{current} 是当前系统加载器别名，firmware 枚举有助于关联 UEFI 配置。它们不是同一层对象；固件是否实际选择某个 Boot####，仍需运行时证据。输出 device/osdevice 可能使用分区设备或抽象标识，应与磁盘分区对应，而不是按 C: 字母猜离线卷的位置。

读取 BCD 不同于执行 bcdboot 或删除加载项。诊断阶段若先重写引导，就丢掉了失败前状态。应先保存配置、分区布局、相关文件哈希和错误画面；再在副本上设计一次只改变一个因素的实验。

静态文件、屏幕画面与启动时长是三层证据

ESP 上存在 bootmgfw.efi、Windows 卷里存在 winload.efi，证明文件存在；BCD 指向它们，证明配置关联；冷启动画面到达登录/桌面，才是该次启动运行结果。任何一层都不能替代所有后续阶段，例如到桌面不证明网络、Agent 或用户应用已可用。

如果研究“为什么慢”，应该先定义计时起点和终点：QEMU 进程创建、固件开始、Windows 内核启动、登录画面、用户桌面、服务可用，得到的是不同区间。历史事件中的约 550 条记录不是 550 次启动，两个时间戳也不能直接计算每阶段耗时；时钟和事件缓冲可能影响顺序。

研究问题	所需补充证据
固件实际选了哪个入口	固件运行日志/对应变量与观察
何时开始内核与驱动加载	受支持的启动追踪与系统事件
哪项服务拖慢登录	事件时间线、服务状态与 ETW/WPR
Secure Boot 是否启用	来宾实际状态与密钥/策略，而非固件文件名
存储切换会怎样失败	隔离副本上的单变量故障注入

原记录没有做完整 ETW 启动追踪或故障注入，因此这张表是后续研究路线。它保留了“已观察的结构”和“尚未测到的运行机制”的边界，也让下一轮实验知道要补什么，而不是继续多截几张桌面图。

按故障阶段选择证据

现象	优先查看
固件找不到可用设备或启动项	虚拟设备、固件变量、ESP
Boot Manager 报 BCD/加载项错误	BCD 默认对象、目标设备与路径
Windows 加载后 INACCESSIBLE_BOOT_DEVICE	存储控制器、启动驱动、SYSTEM hive
登录/欢迎页面停住	服务、用户配置文件、系统日志、ETW

这是定位顺序，不能仅凭错误图就下根因结论。缺少存储驱动和缺 EFI 启动文件处于不同层，不能都用 bcdboot 处理。

下一轮可在独立克隆上解析结构化 UEFI 变量、用 OVMF 调试输出、QEMU block trace 与 WPR/WPA 追踪补时间关系；块读取本身仍不能证明调用者就是 BCD 解析器。故障注入尚未执行，不能提前写成实验成果。WPR 命令行文档

本轮实验机最终正常停止、网卡保持断开、不自动启动。最大的收获是区分三种“启动顺序”，以及把“配置存在”“过程推断”“运行成功”分别表述。

关联阅读：域控重建与黄金镜像使用。

本文日期采用主 KB 首次 Git 提交日期 2026-09-21（UTC+8），提交 3cddb2c。操作与评测时间在正文单独注明；写作期间未连接或修改生产设备。