9.12 典型异常排查与故障分诊指南

在操作系统内核自举与初始化的探索过程中，由于缺乏用户态那样成熟的调试器、符号回溯与核心转储支持，开发者常常面临“系统静默挂起”或“屏幕闪退黑屏后物理机瞬时冷重启”的严峻调试挑战。

这类看似毫无线索的灾难性故障，背后都有其严密的硬件状态机与异常级联逻辑。掌握 x86 体系结构下各类底层硬件异常的触发机理、提取关键控制寄存器的状态镜像，并建立自顶向下的分诊排查路径，是保证内核工程稳步推进的核心能力。

1. 虚拟机 / 实体机突然重启

当虚拟机或真实物理机在引导过程中未输出任何报警信息便瞬间发生黑屏重启时，在硬件底层几乎必然触发了三重错误（Triple Fault）。

在 x86 架构中，三重错误意味着异常分发体系自身的彻底崩溃。当遭遇此类问题时，应当沿着硬件异常捕获路径逐层反查：

• IDT 描述符表的就绪状态：确认内核是否已执行 lidt 指令加载中断描述符表；IDTR 寄存器中的基地址是否按 8 字节对齐且限长（Limit）是否足够覆盖 256 个向量；
• 异常门描述符的空缺与有效性：当发生常规硬件异常时，CPU 查询 IDT 对应项，若该表项为空、存在位（Present）为 0 或选择子指向非法段，硬件无法完成跳转，将立即升级为 8 号双重错误（Double Fault）；
• 双重错误处理例程的健壮性：若连 8 号异常的处理入口也无法正常执行（例如栈指针越界或页目录走查失败），CPU 硬件控制器将判定系统陷入死锁，主动向总线发出关机引脚信号强制主板复位。

2. DoubleFault 异常（#DF，向量 8）

双重错误发生在 CPU 尝试调用前一个异常的处理程序期间再次触发了另一个无法协同的次级异常。这通常意味着内核的执行基础设施已经出现局部破坏。

排查与处理双重错误的工程原则包括：

• 抓取原发异常的现场：双重错误本身往往只是次生灾害，必须设法反查并记录引发连锁反应的第一现场向量号与错误码；
• 清查通用异常存根的缺陷：检查常规中断入口是否存在栈对齐偏差、错误码弹出顺序颠倒等汇编错误；
• 预留专用自救执行环境：双重错误发生时，原有的执行栈与内存环境通常已被破坏，常规异常处理程序极易再次崩溃引发三重错误。

双重错误处理的防御性隔离准则

处理 #DF 时，必须假设当前上下文已处于高度不可靠状态：

• 设立独立的专属栈区：在内核静态数据区开辟一块不小于 1 KiB 的专用栈（如 df_stack），并在 #DF 汇编存根入口处第一时间将 esp/rsp 指针强制重定向至该安全栈顶；
• 切换到恒等映射的安全页表：若启用了虚拟分页，应准备一套仅映射基础运行环境的专用应急页表，发生双重错误时主动切入，规避因原页表损坏造成的走查崩溃；
• 收敛行为至现场转储与停机：在双重错误处理函数内部，仅执行最关键的寄存器转储与屏幕/串口日志输出，切勿尝试调用睡眠、互斥锁或复杂格式化输出等高风险例程，输出完毕后立即执行 cli; hlt 挂起系统。

3. PageFault（#PF，向量 14）

缺页异常是分页式虚拟内存系统中最常见也最关键的硬件异常。诊断缺页异常的核心依据是控制寄存器 CR2（硬件自动填入引发缺页的线性虚拟地址）以及栈上压入的 32 位缺页错误码（PF Error Code）。

3.1 NotPresent 场景分析

当错误码的 P 位（位 0）为 0 时，表明 CPU 访问了一个在页表项中标记为不存在（Present=0）的线性地址：

• 空指针解引用：若 CR2 中记录的地址恰好为 0x00000000，或处于非常小的偏移范围（例如结构体基址为 NULL 时访问其字段，导致地址处于前几百字节），明确指示程序中发生了空指针解引用；
• 合法按需换页（Demand Paging）：若 CR2 落在应用程序堆或栈的合法扩展区间内，且该区间由内核虚拟内存管理结构记录，此时该缺页属于正常系统行为，内核应当为其动态分配物理页框、填入页表项并刷新 TLB，随后恢复指令执行；
• 走查越界与执行流失控：若 CR2 呈现出不可理喻的野指针数值，通常说明内核执行流或栈帧被破坏，函数返回地址被脏数据覆盖导致指令指针取指跑飞。

执行流失控预警

当 CR2 频繁出现无法对应到任何已知符号或数据区间的离散地址时，重点排查缓冲区溢出、栈平衡破坏以及未初始化函数指针的调用。

3.2 UserMode 特权违规

当错误码的 U 位（位 2）为 1、P 位（位 0）为 1 时，表示当前运行在 Ring 3 特权级的用户态程序企图读取或写入一个被页表项标记为特权级（Supervisor-only，U/S 位为 0）的内核空间内存。内核必须拦截该行为并向对应进程投递段错误信号。

4. GeneralProtectionFault（#GP，向量 13）

通用保护异常是 x86 体系中用于捕获所有未被其他专用异常覆盖的保护性违规：

• 非法或未就绪硬件访问：在未完成设备 BAR 基址映射或外设总线未使能时，直接向设备 MMIO 地址执行非法对齐读写；
• 上下文切换寄存器损坏：在任务调度执行上下文保存与恢复时，若从损坏的栈上弹出了非法的段选择子（如段索引超出 GDT 范围或段描述符存在位为 0）；
• 控制寄存器非法置位：向控制寄存器（如 CR0、CR4）写入了保留位组合，或者在不支持的硬件上尝试启用扩展机制；
• 对齐违规：现代 SIMD 向量指令（如 SSE/AVX）对操作数内存地址通常要求 16 字节或 32 字节严格对齐，访问未对齐的局部对象将直接引发 #GP。

5. InvalidOpcode（#UD，向量 6）

非法操作码异常发生在 CPU 指令译码阶段，当执行单元遇到无法识别的机器指令字节序列时触发：

• 数据段被误当代码执行：程序计数器 EIP 错误跃迁至纯数据段、BSS 区或已被释放的内存块，将任意数据当成指令进行译码；
• 指令集架构不匹配：编译工具链开启了当前物理 CPU 并不支持的高级扩展指令集（如在老旧核心或极简虚拟机上执行了 AVX 指令）；
• 扩展指令未在控制寄存器使能：部分处理器指令虽然硬件支持，但处于默认禁用状态，必须由内核显式配置控制寄存器（如开启 CR4.OSFXSR 与 CR4.OSXMMEXCPT 支持 SSE 异常）；
• 快速系统调用未激活：64 位下的 syscall 指令依赖于对扩展特性 MSR（如 EFER.SCE 位）的预先配置。在多处理器体系下，若主核心使能而从核心未使能，从核心执行系统调用时便会触发 #UD。

6. 部分实体机跑不起来我的 OS

在模拟器（如 QEMU、Bochs）中稳定运行的内核，在真实物理主板上启动却频遭卡死，这一现象广泛存在于自制内核开发中。这是由于虚拟机往往对非标准硬件行为有较高的宽容度，且启动时内存大多预先清零。

而在异构的真实物理机上：

• 固件行为与硬件拓扑差异：不同主板制造商对规范的理解与非标准保留区的设置各异，绝不可盲目假设未初始化内存包含特定初值；
• 避免硬编码物理基地址：切勿在源码中写死任何外设基址、帧缓冲地址或内存界限。所有硬件基址均应依托标准总线协议（如通过 ACPI 静态表解析 MADT/FADT、通过 PCI 枚举读取 BAR、通过引导器获取内存映射图）动态探查并验证其合法性后再行使用。

物理机兼容性防线

凡是能够通过标准协议（ACPI、Multiboot/Limine 内存映射表、PCI 配置空间）动态获取的硬件资源，一律禁止硬编码为静态常量。系统必须防御性地假定任何特定物理地址均有可能已被硬件固件或总线控制器所保留。

7. 习题

7.1 巩固

#50909

⚡1⏳1

缺页异常 (Page Fault) 在 cr2 之外还会压入一个 32 位错误码，各位的含义如下：

• 第 0 位 P：为 0 表示页不存在，为 1 表示页存在但访问被拒绝；
• 第 1 位 W：为 1 表示这次访问是写；
• 第 2 位 U：为 1 表示访问来自用户态；
• 第 3 位 RSVD：为 1 表示页表项里的保留位被置了 1；
• 第 4 位 ID：为 1 表示这次访问是取指。

写一个 C 程序 pf_decode.c，实现 void pf_decode(uint32_t err)，按「不存在 / 写 / 用户态 / 保留位 / 取指」的顺序打印置位的项，其他位为 0 时打印什么都没置。用下面六个值测试，把输出填成表：

0x0  0x2  0x4  0x6  0x7  0x10

然后回答：

(1) 本页第 3.1 节说的 NotPresent 情形，错误码的最低两位是什么？

(2) 第 3.2 节的 UserMode 情形对应哪几个值？为什么它一定同时带 U 位？

(3) cr2 为 0、错误码为 0x2 时，最可能是什么代码造成的？错误码为 0x0 时呢？

#50910

⚡3⏳2

内核在异常处理里打印了一份现场，格式固定为一行一个字段：

vec=13 err=0x0000 eip=0x00102a4c cs=0x0008 cr2=0x00000000
vec=14 err=0x0002 eip=0x00104b10 cs=0x0008 cr2=0x00000010
vec=14 err=0x0007 eip=0x00105002 cs=0x0023 cr2=0xc0001000
vec=6  err=0x0000 eip=0x00103b20 cs=0x0008 cr2=0x00000000

写一个主机程序 fault_triage.c 做分诊：

(1) 定义 struct fault { unsigned vec; unsigned err; uint32_t eip; unsigned cs; uint32_t cr2; } 和一个从上面这种行里解析出结构体的函数（sscanf 加固定格式即可）。

(2) 按本页第 1～5 节的判据写 const char *diagnose(const struct fault *f)，至少区分下面几种情况，每种返回一句结论和一句下一步该查什么：

• vec=13、err 为 0：对照本页第 4 节的三条，说明最可能是哪一条被违反；
• vec=14、err 的 P 位为 0 且 cr2 小于 4096：空指针；
• vec=14、err 的 P 位为 0 且 cr2 落在内核区间、cs 的 RPL 为 3：用户态越界访问；
• vec=14、err 的 P 位为 1：已映射但权限不符，说明是写只读页还是用户态碰内核页；
• vec=6：按本页第 5 节判断是取指跑飞还是扩展指令未启用。

另外留一个入口 const char *diagnose_boot(int printed_anything, int reboot_count)：内核一行现场都没打印、机器反复重启时，按第 1 节判断为 TripleFault，并列出该查的三处；打印过现场却仍重启时，说明 #DF 的处理本身有问题。

(3) 用上面四行输入跑一遍，把输出贴出来。再自己补两行，让 diagnose 的另外两个分支各被走到一次，并对 diagnose_boot(0, 5) 与 diagnose_boot(1, 5) 各调用一次。

(4) cs 的低 2 位是 RPL。说明为什么分诊时要看它，只看 cr2 会漏掉什么。

7.2 编程

#50911

⚡3⏳3

正文要求双重异常时切换到一块 1 KiB 的专属栈。32 位保护模式的任务状态段里虽然有 esp0，但 CPU 只在特权级变化时才从它取栈，同一个内核里发生的 #DF 不会触发换栈，所以要么配任务门让 CPU 换任务，要么在 #DF 入口用一小段汇编自己换 esp。本题先做后一种，再对照前一种。

(1) 写一个 #DF 的入口存根 isr8_df：进入后把 esp 指向静态数组 df_stack[1024] 的顶端，把原来的 esp 保存到一个全局对象里，然后调用 C 处理函数 df_handler(uint32_t old_esp, uint32_t err)。给出汇编与 C 两侧的声明。

(2) 处理函数只打印 err、old_esp 和 cr2，然后 cli 加 hlt 死循环。说明为什么这里不能 iret，也不能调用可能睡眠或加锁的函数。

(3) 说明 df_stack 为什么必须 __attribute__((aligned(4))) 且用 static 存储期，不能是局部数组。

(4) 给出 IDT 第 8 号表项指向 isr8_df 的初始化代码。

(5) 对照方案：x86-64 的 IDT 表项有位 32～34 可以选 IST，硬件会在进入时自动换栈。说明 32 位模式下为什么没有这个便利，以及换成任务门时需要额外准备什么。

(6) 在这块 1 KiB 的栈上，处理函数能安全使用多少字节？printf 一类的格式化输出会不会吃掉大半？给出你的估算和理由。

#50912

⚡4⏳3

页错误处理要区分「按需分配」与「真的出错」。下面的骨架用来实现前者，其中 read_cr2 是要你自己写的三行内联汇编：

static inline uint32_t read_cr2(void)
{
    uint32_t v;
    __asm__ volatile("mov %%cr2, %0" : "=r"(v));
    return v;
}

void page_fault_handler(registers_t *regs, uint32_t err)
{
    uint32_t addr = read_cr2();
    /* ... */
}

要求：

(1) 从错误码取出 P、W、U 三位，写成 pf_flags，并给出三个 enum 值。

(2) 实现按需分配：P 为 0、addr 落在用户堆区间 [USER_START, USER_HEAP_END)、且映射不存在时，分配一个页框、建立映射、刷新 TLB 后返回。其余情况打印诊断信息：错误码、cr2、出错指令地址（regs->eip）、当前进程号，然后终止该进程。

(3) 用 code/项目/mdrOS/memory.h 里的接口把上面用到的东西对上：get_page、alloc_frame、flush_tlb 各取什么参数，get_page 的 make 参数取 1 会做什么。USER_START 与 USER_HEAP_END 也在这个头文件里。

(4) 对本页第 3.1 节列出的三种情形各构造一个用例，写出 cr2 与错误码，说明处理函数的分支走向。

(5) 用户态程序访问内核区域会得到 U 位为 1、P 位为 1 的错误码。说明为什么这条路径不能走按需分配，即使 addr 落在某个已经映射的区间。

7.3 综合与挑战

#50913

⚡5⏳4

写一个异常处理的分派与诊断模块，替换现在 isr_handler 里的空壳。要求：

(1) 用 32 项的跳转表分派 0～31 号向量。每项包含向量名、是否有错误码、处理函数指针：

struct exception {
    const char *name;
    int has_error;
    void (*handler)(registers_t *regs, uint32_t err);
};

(2) 存根对没有错误码的向量也压了一个 0，所以 32 个处理函数拿到的第二个参数总是「错误码」。说明这样一来 struct exception 里的 has_error 字段还有没有用；如果要让它是准的，存根和表各要改哪里。

(3) 除 #PF 与 #DF 外，其余异常的处理函数统一打印向量号、名称、错误码和 eip，然后停机。用一个故意除零的内核函数验证：输出里的 eip 应当落在触发除法的那条指令上。写出你用来定位 eip 的命令（objdump 或 addr2line）。

(4) 为 #GP 与 #UD 各写一条针对性的提示：#GP 的错误码为 0、eip 落在驱动初始化函数里时，最可能是本页第 4 节三条里的哪一种；#UD 出现在 syscall 指令上时，最可能缺了第 5 节说的哪一步设置。

(5) 说明为什么 #DF 除了要换一块栈，还要换一张页表：#DF 的常见成因是页表本身损坏，此时沿用当前页目录会怎样？

(6) 给每个异常加一个「发生次数」计数，并用 printf 每 100 次汇总一次。说明这个计数为什么必须是每核一份，多核共用一份会怎样。

#50914

⚡6⏳5

处理本页第 6 节说的「部分实体机跑不起来」。写一个小工具，检查内核在启动早期是否依赖了写死的地址或未验证的假设。要求：

(1) 定义一个描述表，把内核里每一处「从固件取得的地址」登记下来：来源（ACPI、cpuid、multiboot、Limine、写死）、用途、是否已校验。写一个 struct hw_fact 数组，至少覆盖：帧缓冲基址、AHCI_BASE、APIC 基址、页表基址、栈顶。

(2) 实现 check_facts：对来源为「写死」的项打印警告；对来源为固件的项检查地址非零且对齐符合要求（帧缓冲 4 字节、APIC 4 KiB、页表 4 KiB）。

(3) 分别对「AHCI_BASE 写死为 0x400000」与「页表基址直接从固定常量取」两种写法各跑一次，说明哪一个在换机器之后更容易坏，依据是这处地址被谁占用。

(4) 把 AHCI_BASE 从「写死」改成「从 PCI 取得 ABAR」，在改动记录里写清楚这一步依赖了哪些前置条件（PCI 枚举可用、ABAR 已映射、映射无缓存）。

(5) 说明为什么用 cpuid 取多核代号在部分实体机上不可靠，改用 ACPI 的 MADT 或 lapic_id 之后代码要改哪几处。