大多数人第一次认真关注 Windows 的启动过程，往往是被一块蓝屏逼的。屏幕上写着 0xc000000f、0xc0000225，或是那句经典的"你的电脑需要修复"，附带的"按 Enter 重试、按 F8 进入启动设置、按 ESC 进入 UEFI 固件设置"三个选项全都不管用。此时你会发现一个尴尬的事实：我们对这台每天开机使用的机器，了解得几乎为零。
本文要做的事，就是把下面这条被无数技术文章反复引用、却极少被真正讲透的链路，拆成可以逐环节审视的工程细节：
控制权交接了三次，而不是一次。 固件 → 引导管理器、引导管理器 → 系统加载器、系统加载器 → 内核，每一次交接都伴随着执行环境（分页是否开启、物理地址还是虚拟地址、谁拥有内存、谁拥有中断）的根本性变化。
中间夹着两个配置数据库。 一个是固件侧的 NVRAM 变量（BootOrder / Boot####），一个是微软侧的 BCD 注册表 hive。二者都叫"启动配置"，格式、位置、读写者完全不同，但它们必须保持一致，任何一边漂移都会导致启动失败。
有一条与安全启动并行的"测量链"。 Secure Boot 决定"能不能跑"，Measured Boot 记录"跑了什么"，BitLocker 则基于后者决定"要不要解开磁盘密钥"。三者共用同一套 PCR 与事件日志。
用户给出的链路里有一个历史遗留的表述需要修正。 在 Windows 10 2004 及以后，hal.dll 已经不再是独立于内核的硬件抽象层实现，它被静态链接进了 ntoskrnl.exe。这不是咬文嚼字，而是理解现代 Windows 内核布局的关键。
每一次"下一步"都有失败分支。 启动链路真正的复杂度不在正常路径，而在它为每个环节准备的诊断、回滚与自动修复机制：Boot Status Policy、Last Known Good、WinRE、自动修复、启动计数。
本文按这条链路的自然顺序展开，但每一章都会同时讲三件事：它做了什么、它依赖什么前提、它在什么条件下失败，以及失败时你看到的是什么。写作目标是让读者读完以后，面对任何一条启动错误信息，都能立刻定位到它发生在链路的哪一段、该查什么证据、用什么工具修。
第一章 固件初始化：从复位向量到 ExitBootServices
1.1 一次加电，CPU 做的第一件事
按下电源键后，电源管理电路把 PWR_OK 信号拉高，主板解除对 CPU 的复位。x86-64 处理器在复位后的状态是一套刻意保留的、近乎"原始"的状态：寄存器被清零或置为固定值，分页未开启，大部分特性未启用，CPU 处于实地址模式的长模式前状态。唯一重要的是指令指针——它固定指向线性地址 0xFFFFFFF0，这个地址被称为复位向量（Reset Vector）。
这个地址位于 4GB 物理地址空间尽头往下 16 字节处，硬件（芯片组）保证这段地址被映射到主板 SPI Flash 上的固件映像末尾。那里通常只有一条远跳转指令，把执行流转向固件真正的入口。
从这一刻起，运行的代码来自主板上的那颗闪存芯片，而不是硬盘。这一点是理解整个安全启动模型的前提：操作系统还没参与任何事，第一道信任判定已经在固件里完成了。
第二章 bootmgfw.efi：Windows 引导管理器
2.1 它是谁，它从哪来
bootmgfw.efi 是 Windows Boot Manager 在 UEFI 平台上的实现。"mgfw"即 Manager Graphics/EFI Firmware Wrapper 一类的历史缩写延续，其对应的 Legacy BIOS 版本叫 bootmgr（无扩展名）。
它在磁盘上有几处副本，理解它们的区别很重要：
当你在 WinRE 命令提示符里执行：
bcdboot C:\\Windows /s S: /f UEFI
这条命令做的事情，本质上就是：在 \\Windows\\Boot\\EFI\\ 下取一组文件，复制到 ESP 的 \\EFI\\Microsoft\\Boot\\，生成/更新其中的 BCD，并向 NVRAM 写入（或刷新）一条指向 \\EFI\\Microsoft\\Boot\\bootmgfw.efi 的 Windows Boot Manager 启动项。
注意一个常见误解：bcdboot 并不只复制 bootmgfw.efi。它复制的是整套引导环境：引导管理器本体、语言资源文件（\\EFI\\Microsoft\\Boot\\Fonts\\ 下的字体、bg-BG、zh-CN 等语言目录）、内存诊断程序、以及用当前系统配置生成的 BCD。这也解释了为什么在一个"BCD 彻底损坏"的机器上，bcdboot 往往比 bootrec /rebuildbcd 更彻底——后者试图在既有 BCD 上打补丁，前者直接从源头重建整套。
第三章 BCD：固件之外的启动数据库
3.1 BCD 本质上是一个注册表 hive
这是理解 BCD 最重要的一句话：BCD 文件就是 Windows 注册表 hive 文件，用的是同一个 regf 格式，可以用 reg load 挂载、可以用注册表编辑器查看、可以用任何 hive 解析库读写。
3.2 对象类型码
每个对象在 Description\\Type 中记录一个 32 位类型码：
第四章 winload.efi：操作系统加载器
如果说 bootmgfw.efi 是"选谁来跑"，那么 winload.efi 就是"把它跑起来所需的全部准备工作"。这是整条链路中工作量最大、也最容易出错的一环。
4.1 定位与加载
引导管理器确定目标条目后，读取其 device（0x11000001）与 path（0x12000002）元素。对标准 Windows 10 UEFI 安装，这两个值是：
device partition=C: （即 \\Device\\HarddiskVolumeN，Windows 所在卷）
path \\Windows\\system32\\winload.efi
引导管理器用固件的文件服务把这个文件读进内存，但它不是简单地跳转执行——它通过 ImgArchStartBootApplication 一类的内部例程，完成一个"受保护的启动应用移交"：验证签名、准备执行环境、传递参数，然后进入 winload 的入口。
这里有一个安全上的重要设计：从 bootmgfw 到 winload 的这次加载，同样要过签名验证。即便 Secure Boot 在固件层已经关闭，Windows 的引导管理器依然会用微软的密钥体系校验 winload.efi 的完整性。这就是所谓 Trusted Boot（可信启动）：微软把自己的信任链从固件层延续到了操作系统加载器层，每一环都验证下一环。
如果这一步失败，你会看到：
Recovery
Your PC needs to be repaired
The application or operating system couldn't be loaded because a required file is missing or contains errors.
File: \\Windows\\system32\\winload.efi
Error code: 0xc0000428
0xc0000428 的含义是 STATUS_INVALID_IMAGE_HASH —— 镜像哈希无效，即签名校验失败。这通常意味着：
winload.efi 被篡改（恶意软件或错误的修补）；
磁盘错误导致文件读取损坏；
系统文件版本与引导管理器期望的不一致（例如跨版本回滚、组件存储损坏）。
注意区分 0xc000000f 与 0xc0000428：前者是"找不到/打不开"（路径或 BCD 问题），后者是"找到了但不可信"（内容问题）。两者修复方向完全不同——前者查 BCD 与分区，后者跑 sfc / DISM。
第五章 内核启动：ntoskrnl.exe 与 hal.dll
5.1 先修正一个流传很广的说法
用户的原始描述是：内核启动：ntoskrnl.exe（系统内核主体）、hal.dll（硬件抽象层）。
这个说法在 Windows 10 之前是准确的，但在 Windows 10 2004（版本 2004 / 20H1）之后已经过时了。
事实是：从 Windows 10 2004 开始，HAL 的实现被静态链接进了 ntoskrnl.exe。磁盘上那个 hal.dll 仍然存在，但它只是一个向后兼容的存根（stub）。
第六章 端到端时间线与状态快照
6.1 完整时间线
把前五章串成一条时间线（典型 UEFI + Windows 10，NVMe SSD，快速启动开启，耗时为常见范围）：
第七章 故障定位手册：从现象到根因
7.1 第一原则：先定位"死在哪一段"
面对一台起不来的机器，最有价值的一步不是急着敲命令，而是判断控制流停在了链路的哪一段。判别依据只有三个：屏幕内容、错误码前缀、以及按键响应。
7.2 引导错误码（0xc0000xxx）决策表
这些是 bootmgfw / winload 阶段抛出的错误，出现在深色背景的 WinRE 风格界面上。它们不是蓝屏，也不是内核错误，处理手段与蓝屏完全不同。
第八章 安全机制全景：七道防线
把散落在各章的安全机制串起来，Windows 10 的启动链实际上部署了七道防线：
第一道：硬件信任根（Boot Guard / PSP 硬件验证）
CPU 微码与 ACM 在固件执行前验证固件签名。失败 → 变砖或拒绝执行。防的是"刷恶意 BIOS"。
第二道：固件 Secure Boot
PK/KEK/db/dbx 四层密钥体系，验证每一个 EFI 映像。防的是"替换 bootmgfw.efi"。
第三道：Trusted Boot（微软自己的信任链）
bootmgfw 验证 winload.efi，winload 验证所有它加载的驱动（通过 ci.dll）。即便 Secure Boot 关闭，这一层依然工作。防的是"替换 winload 或注入未签名驱动"。
第四道：Measured Boot（TPM 度量）
PCR 0–7（固件）+ 11/12/13/14（Windows）记录所有被加载组件的摘要，事件日志可被远程验证。防的不是攻击本身，而是"攻击后伪装成健康"。
第五道：ELAM（早启动反恶意软件）
在 boot-start 驱动被初始化之前逐个分类（Good/Bad/Unknown），并可按策略阻止。防的是 rootkit 型驱动。
第六道：代码完整性 / HVCI / VBS
运行期持续强制签名策略（WDAC 可进一步限定允许的签发者）；基于虚拟化的安全（VBS）把安全敏感的内核代码放到受 hypervisor 保护的隔离区域；HVCI（内存完整性）确保内核代码页不可被写入、不可执行未签名代码。
第七道：BitLocker（数据静态保护 + 引导链密封）
把磁盘密钥与 PCR 值绑定。任何改变引导链的行为都会导致密钥无法解封。防的是"离线攻击"（把硬盘拆下来读数据、或用 U 盘启动改文件）。
这七道防线的关键性质：它们不是冗余的，而是分层的——每一道防的是不同的攻击路径：
一个常被问的问题：关掉 Secure Boot 会怎样？
第二道防线消失：任何 EFI 应用都能被固件加载，包括 bootkit。
但后面五道还在：bootmgfw 仍会验证 winload，winload 仍会验证驱动，ELAM 仍在工作，HVCI 仍在工作。
BitLocker 会立刻要求恢复密钥——因为 PCR 7（Secure Boot 状态）变了。这就是为什么"关 Secure Boot 试试"之后，很多人反而遇到更多麻烦。
理解它，不会让你开机更快。但当它坏掉的那天，你会知道自己该看哪里。
参考资料 https://mp.weixin.qq.com/s/E0Bd_GUEOiJe4agZD06sPg
