| 调试器输出 | | 第二步 | ParseArg | AML操作数流：名称串指针、类型标记 | 第一个参数“名称串”已解析 | | 第三步 | ParseOpcode(嵌套) | EisaId 的括号内表达式字节 | 返回一个 Buffer 对象的引用 | | 第四步 | MoveObjData | 处于未归档状态的数据对象、目标 NameSlot | Buffer 内容被完整拷贝进 _HID 的存储区 |
这个表在调试器里展开后，每一步的寄存器、对象地址都可以对应上。你会发现断点命中的顺序就是解释器的取指、解码、求值、写回流水线。这个流水线搞明白之后，ACPI 相关的那一坨符号就再也不是盲区了。
5. 结合调用栈判断系统正在执行哪一段AML
很多时候我不是主动去断这条链的，而是在看 dump 时被它绊住——调用栈里突然出现 ACPI!ParseArg、ACPI!MoveObjData，说明系统正在执行 AML，而且执行到一半出了问题。
这类问题的第一步永远是回答一个问题：这段 AML 是因为什么被触发的。看栈顶 UMS 之后向上翻，能找到提交执行的来源。常见的有几类：
- 中断触发的：GPE/SCI 事件被映射成 AML 里的 Notify 或 _Exx/_Lxx 方法；
- 设备初始化触发的：Pnp 枚举走到某个 _STA、_INI 方法；
- 电源事件触发的：睡眠、唤醒、电池状态变化，执行 _PS0/_PS3 或 _Qxx。
我遇到一个印象很深的案例：某块主板在唤醒复位后系统触发了一次中断风暴，调用栈反复出现在 ACPI!MoveObjData 附近。顺着栈里方法调用往回翻，发现正在执行的是设别 _PS0 里的 Store 操作。
AMLI 执行异常时，关键不是盯着异常指令，而是往回看一到两层栈，弄清楚是谁在调用它。AML 方法之间的嵌套最终会像函数调用一样压栈，而且 ACPI 解释器的方法栈深度是有限的——栈越深，能提供的上下文信息越多。拿到完整栈之后，按"父方法 → 当前方法 → 当前操作 → 当前数据对象"的顺序重新走一遍 ParseOpcode → ParseArg → MoveObjData 的流程，问题往往就清楚了。
还有一种情况是根本没有到 MoveObjData 这一步就卡死了。比如 ParseArg 阶段缺少终止标记，或者某个操作数类型不匹配，解释器会回滚当前方法并酌情上报错误。这种时候栈里只会看到 ParseOpcode 和 ParseArg，看不到后面的 Name、MoveObjData。千万别觉得这是断错了地方，这本身就是线索：数据没"落袋"，说明在求值阶段就已经夭折了。
6. ACPI调试链路上我踩过的几个刻骨铭心的坑
这一节想把我在实际折腾中反复踩过的几个坑一次性倒出来，每一个都是用时间换来的。
6.1 符号版本不一致，白忙一小时
老生常谈但最容易犯。本地缓存的 ACPI.sys 符号如果和当前系统版本不一致，反汇编窗口里显示的函数名、行号可能错位，甚至参数名全是错的。我曾经对着一个错的 Buffer 对象名分析半天，最后发现符号是旧版本的。调试 ACPI 这种内核模块，第一时间确认符号服务器拿到的 PDB 与系统版本严格一致，否则后面的所有分析都不可信。
6.2 ParseOpcode 的断点命中率能让人崩溃
AML 解释器一跑起来，ParseOpcode 就是最热的热点，断点一开，计数马上几万几万地涨。如果有条件，用日志断点代替普通断点，只记录当前指令指针落在哪个 DSDT 地址范围里。实际操作中我会先断一次，读 Current PC 和 AML 表基址，算出偏移，然后用地址范围条件去过滤。没有条件断点的话，就把方法名或名称字符串作为第二层过滤条件，命中后再展开详细寄存器。
6.3 MoveObjData 的操作对象不在寄存器里，在对象栈里
这一点新手最容易懵。MoveObjData 的两个参数不是像SourceAddress, DestAddress那样简单放在寄存器里的，而是通过 ACPI 内部对象栈传的。栈里的对象是 ACPI 内部对象（带类型标签、引用计数、联合体）的描述符。看这种参数，必须先认清对象描述符的头部结构，再解引用二级指针。直接单步跟汇编一两次你就会知道：不把对象描述符结构 dt 出来，单靠寄存器完全看不明白。
6.4 Buffer 对象的数据区不一定连续
AML 的 Buffer 对象在解释器内部存储时可能是一段不连续的资源，查看数据区时不要想当然地一条d命令从头读到尾。需要先看描述符里的字节长度字段，再按长度逐段观察。我在调试一个自定义 ACPI 表时，就是没注意 Buffer 的跨段存储，只看了第一个内存页，结果错过了真正的坏数据。
6.5 时刻留意递归深度
ParseOpcode 和 ParseArg 之间是互相递归的。一个方法里嵌套了几层 Store、DerefOf、CondRefOf 之后，递归深度可以很深。断点条件加上对返回地址或深度计数器的记录，才能在回溯时快速找到嵌套的根。某些异常的第二次或者第三次递归才会暴露，所以日志比单步更实用。
6.6 别忽略 IRQL 对调试操作的限制
在内核调试中，如果断点命中的上下文 IRQL 很高，某些内存读取和扩展命令会失效。这时候不要硬来，先把寄存器快照、调用栈记录下来，等 IRQL 降下来再继续分析。个人经验：把当前 IRQL 记入日志，和操作码、参数栈放在一起，后面复盘时会节省大量时间。
7. 一个把整条链跑通的模拟场景收尾
最后分享一个我自己概括的"三段式看链"方法，适用于绝大多数 ACPI 符号链路：
- 第一段，找字节流消费者：函数里肯定有一个读 AML 字节流的循环，对应 ParseOpcode；
- 第二段，找参数装配者：函数里存在按操作数数量循环、递归调用的逻辑，对应 ParseArg；
- 第三段，找数据落盘者：函数最终把求值结果写进某个命名对象或内部数据结构，对应 MoveObjData。
按这三段去拆任何一条陌生链路，基本都能快速定位到底执行到了哪一步、卡在哪一步。这也是我从最初面对 ACPI!ParseArg、ACPI!Buffer、ACPI!ParseOpcode、ACPI!Name、ACPI!MoveObjData 这一串名字时完全一头雾水，到现在能顺着断点把每一步都复现出来的全过程。
这几个函数本身并不神秘，神秘的是把它们的调用关系还原成 AML 执行流的那一步。下次再在调试器里撞见这条链，别急着绕开——先停一停，去看看当下执行的是哪段 AML，再看看数据对象要往哪儿去。真正搞懂一次之后，ACPI 这块黑盒就再也不是拦路虎了。
