ACPI!ACPIDetectPdoDevices 对 Device (ACAD) 的处理，这问题说大不大，说小不小，却是不少电源类驱动问题的分水岭。我第一次较真这个函数，是因为一台笔记本在插拔电源后电量状态完全不响应，系统日志里没有明显的设备错误，但电源子系统就是认为不存在交流电源。WinDbg 挂上之后一路跟下去，所有线索都指向\_SB.ACAD这个节点没有被正常枚举成 PDO。那时候你才会意识到，ACPI 命名空间里一个平平无奇的 ACAD 节点，背后牵动的是整套交流电源识别链条。
这篇文章就把我调试这个过程时对ACPIDetectPdoDevices的理解完整写出来。不光是函数本身的逻辑拆解，还包括 ACAD 节点为什么需要单独处理、它在枚举阶段经历的每一步，以及真碰到设备不出来时该怎么用调试器一步步确认问题。内容偏 Windows 内核驱动和电源管理方向，适合做驱动开发、系统底层调试的朋友参考，做 BIOS/EC 固件的同学看完也会有大用处。
1. 背景：ACPIDetectPdoDevices 在 ACPI 驱动栈里的位置
1.1 ACPI 设备枚举的整体流水线
Windows 里 ACPI 设备枚举这事，核心在 Acpi.sys。加载顺序上，PnP 管理器先加载 ACPI 功能驱动，Acpi.sys 在 AddDevice 阶段被调用，然后它会去读固件送过来的 ACPI 命名空间。命名空间本质是一棵由 DSDT（Differentiated System Description Table）定义的对象树，里面有处理器、PCI 总线、电池、温度传感器、风扇、交流电源适配器等各类节点。Acpi.sys 的职责就是把树上这些节点转换成 PnP 体系里的物理设备对象，也就是 PDO，再上报给 PnP 管理器，让它决定谁来当功能驱动、谁来绑过滤驱动。
ACPIDetectPdoDevices就是这条流水线上非常靠前的一个环节。它的名字拆开看很直白：Detect PDO Devices，检测并创建物理设备对象。在主板上电、系统启动这个语境里，它承担的是命名空间子节点到 PDO 的映射工作。如果它在某个节点上判断"这个设备不存在"，那么后续所有组件都见不到这个设备。
1.2 为什么枚举逻辑需要一个专门函数
可能有人会问，枚举设备不是 PnP 管理器自己就能干吗？ACPI 特殊就特殊在，它不是一个传统意义上的总线，设备节点也没有标准的硬件枚举机制。PCI 总线可以靠配置空间里的 Vendor ID、Device ID 来发现设备，USB 靠描述符。ACPI 命名空间里的设备存在于一张表里，是否真实存在、是否可用，完全由 ASL（ACPI Source Language）代码里的_STA方法说了算。这意味着枚举器必须先执行 ASL 方法、解析返回值，再决定要不要创建 PDO。
这活儿如果放在 PnP 管理器里做肯定不合适，因为 PnP 管理器是通用机制，不可能理解某个 ASL 方法的语义。于是 Acpi.sys 内部就有了一连串设备节点处理循环，ACPIDetectPdoDevices就是其中一个重要的环节。它做的事情说简单也简单，说复杂也复杂：遍历子节点、读取设备标识、执行状态检查、决定创建怎样的 PDO、设置电源关系。ACAD 节点就是在这个环节里被"看见"或者"忽略"的。
注意：
ACPIDetectPdoDevices并不是一个公开的导出函数，微软符号库里能看到，但官方文档里不会专门讲解它的行为。所以这篇文章里关于内部逻辑的理解，都是基于调试经验和 ACPI 规范推导的，但这对排错已经足够了。
2. Device (ACAD) 的特殊性，决定了它不能被当普通设备处理
2.1 ACAD 到底是哪种设备
ACAD 通常是\_SB.ACAD或\_SB_.ACAD，在传统笔记本 DSDT 里非常常见。名字本身是 ACPI 设计者自己起的，代表 AC Adapter，也就是交流电源适配器。ACPI 规范其实不强制节点叫 ACAD，但是约定俗成的命名在绝大多数固件里保持一致，所以调试时看到这个名字基本可以直接认定是电源适配器节点。
它和 GPU、网卡这些设备不一样，没有真正意义上的"物理硬件"可以直接访问。交流电源是否存在，在硬件层面往往是一个电平信号，接到嵌入式控制器（EC）的 GPIO 上，或者集成在电源管理芯片里。ACPI 固件通过_PSR（Power Source）方法去查询这个状态，返回 1 表示在使用交流电源，返回 0 表示在使用电池。你可以把 ACAD 节点理解成一个"探测端口"，它的存在是为了给操作系统提供一个查询电源来源的路径。
2.2 ACAD 的身份信息从哪里来
在 ACPI 枚举中，设备要能被识别，通常需要三类信息：
| 信息类型 | ASL 方法 | 作用 |
|---|---|---|
| 身份标识 | _HID/_CID | 告诉操作系统这个设备是什么型号、属于哪类设备 |
| 存在状态 | _STA | 返回设备是否存在、是否启用、是否在 UI 中显示 |
| 电源状态 | _PSR | 当前是否接入交流电源 |
ACAD 节点的_HID一般是"ACPI0003"。这个 ID 是 ACPI 规范里给 AC Adapter 分配的标准即插即用 ID。部分老式 DSDT 可能写"PNP0C09"之类，但那更多出现在电池节点上，按规范电池是PNP0C0A、AC 是ACPI0003，当然老固件里奇奇怪怪的写法都存在，后面排查部分我会专门说。
_STA对于 ACAD 尤其要紧。很多 DSDT 里它不只是简单返回 0xF，而是会去读 EC 的状态或者某个 GPIO，从而动态反映硬件配置。比如某些准系统主板，没插 DC 电源时_STA返回 0，插上之后返回 0xF。Windows 的 ACPI 枚举器对这个返回值非常敏感，返回 0 就认为设备不存在，直接跳过，不会给你任何二次确认的机会。
2.3 ACAD 与电池节点的依存关系
ACAD 和电池在 ACPI 里是强关联的两个节点。电池节点_SB.BAT0，它的_PSR描述的是电池当前是否在放电，_BIF描述电池信息。而 ACAD 的_PSR则说明系统是否插着电源。电源管理子系统通常同时订阅这两类状态事件。
从枚举顺序上看，ACAD 和电池节点是平级的，谁先谁后没有强制的规范要求，但ACPIDetectPdoDevices处理完它们之后，设备之间的关系就确定了。Windows 里电池设备和电源适配器设备之间会建立一种设备依赖关系，具体反映在 PnP 设备树上就是父子或者同层关联。如果 ACAD 没被枚举出来，电池设备虽然可能存在，但充电状态、电源来源判断都会变成无水之源。
我实际见过一个现象：ACAD 节点被 BIOS 禁用后，电池能在 Windows 里看到，但系统永远认为自己在用电池，连插着电源充电都显示"未充电"。这就是因为电源关系树里缺了 ACAD 这一环。
3. ACPIDetectPdoDevices 处理 ACAD 的逻辑拆解
3.1 第一步：遍历命名空间，先过_STA这道筛选
从逻辑上讲，ACPIDetectPdoDevices处理任何子节点时，都要先执行_STA。这一步等价于枚举器的"简历初筛"。_STA返回值的 bit0 代表设备是否存在，bit1 代表设备是否启用，bit2 代表是否应该在用户界面显示，bit3 代表电池是否正在充电。ACAD 节点正常情况下返回 0xF，也就是所有位都是 1。
如果_STA返回 0，枚举器直接跳过该节点，不创建 PDO。这里有一个容易忽视的坑：某些固件的_STA实现包含了对 EC 的访问操作，在系统启动早期 EC 可能还没完成初始化，_STA读到的是错误状态，从而让 ACAD 被误判为不存在。换句话说，ACAD 枚举失败，不一定是固件故意禁用，也可能是时序问题导致的。
经验上判断，固件里 ACAD 的_STA简单写Return (0x0F)最稳妥。虽然查询 EC 看起来更"智能"，但启动阶段的时序风险很大。如果确实要动态判断，_STA 里就必须做 Level 检测和稳定延时，防止上电瞬间误读。
3.2 第二步：识别 ACAD 的类型，决定交给谁
过了_STA筛选之后，枚举器需要确定这个节点的身份。做法是读取_HID和_CID，然后和 Acpi.sys 内部维护的设备类型表去比对。ACPI0003会命中 AC Adapter 类型。识别出类型后，Acpi.sys 会在这个节点的设备扩展里记录设备类型，用于后续创建不同特征的 PDO。
这里我要强调一点：Devicetype 识别是在 PDO 创建之前完成的。也就是说，ACPI 驱动需要先知道"这是一个电源设备"，才能决定周边要挂什么属性。ACAD 命中 ACPI0003 之后，后面设置的电源管理能力位、通知方式、功耗状态都和普通 PCI 设备完全不一样。
如果用伪代码来展示这个过程，大致是这样：
for each childNode in namespace { status = EvaluateMethod(childNode, "_STA"); if ((status & 0x3) != 0x3) continue; hid = EvaluateMethod(childNode, "_HID"); if (hid == "ACPI0003") { pdoContext->DeviceType = DeviceTypeACAdapter; pdoContext->PowerSourceMethod = "_PSR"; CreatePdo(childNode, pdoContext); RegisterPowerNotification(pdoContext); } }这不是 Acpi.sys 的逐行源码，只是我根据可观察行为还原出的逻辑轮廓，帮助理解角色关系。
3.3 第三步：创建 PDO 并接入电源管理链路
识别类型之后，ACPIDetectPdoDevices会为 ACAD 创建 PDO。这个 PDO 的设备 ID 通常是ACPI\ACPI0003或者带实例号的形式。PDO 创建完成后，上报给 PnP 管理器，系统会尝试寻找匹配的功能驱动。
AC 适配器在 Windows 里的处理方式有一点特别：它并不需要一个传统意义上的、替用户完成 I/O 操作的功能驱动，而是更多服务于电源管理框架。系统里的电源引擎插件（Power Engine Plugin，PEP）或电池类驱动会关注这个设备的存在。也就是说，这个 PDO 更像是一个"状态发布者"，它的价值不在数据读写，而在状态通知。
ACAD 的 PDO 创建成功后，_PSR会被挂接到系统电源状态变更的通知机制里。当_PSR返回值变化时，例如拔掉电源从 1 变成 0，ACPI 驱动要通过 Notify 机制向电源管理框架发通知，触发整个系统的电源来源切换逻辑。这也是为什么 ACAD 枚举失败时，插拔电源毫无反应——因为通知机制根本没有建立起来。
3.4 关键点：ACAD 的 PDO 与普通设备 PDO 有什么不同
普通设备的 PDO 代表一块可以打开、读写、做 I/O 控制的硬件，比如一个 GPIO 控制器、一个传感器。ACAD 的 PDO 没有硬件资源，不需要分配内存窗口，也不会有中断资源。它存在的全部意义就是让上层看到"这里有一个交流电源感知点"。
从调试器的视角看，ACAD 设备对象上会挂一些电源相关的属性，比如设备状态、电源能力。它会参与系统的电源状态转换，但不会像磁盘、网卡那样出现在设备管理器常规视图里被人关注。很多人在设备管理器里把"电池"和"AC 适配器"混在一起，实际上 ACAD 在设备管理器里通常出现在"系统设备"或者"电池"分类下，名称可能是"ACPI 电源适配器"之类的通用描述。看不到这个条目，往往就是枚举失败的直接体现。
4. 调试实录：用 WinDbg 跟踪 ACAD 的枚举
4.1 环境准备和符号配置
调试ACPIDetectPdoDevices建议用双机内核调试。Windbg 连接目标机以后，第一件事确认 Acpi.sys 的符号能解析。微软公共符号服务器上 Acpi.sys 的符号基本都能拿到，直接设置：
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols .reload /f acpi.sys加载成功之后，可以用x acpi!ACPIDetectPdoDevices确认函数符号存在。如果这一步显示找不到，先检查符号路径和版本，多数情况下是符号缓存不对，而不是函数本身没有导出。
4.2 断点设置与关键数据观察
枚举发生在系统启动早期，所以要用bu（unresolved breakpoint）在模块加载时下断点：
bu acpi!ACPIDetectPdoDevices这个断点让调试器在函数被调用时中断。触发后，用kn看调用栈，你会看到它的调用来源基本在 Acpi.sys 的启动枚举路径上。这里要观察的核心数据是函数参数里的命名空间上下文，以及遍历到 ACAD 节点时的中间状态。
不过这个函数是内部函数，参数和结构体不会完整公开到符号里，直接dt不一定能全部展开。我的做法是配合!acpi扩展来查看 ACPI 设备树。进入内核调试模式后执行：
!acpi它的输出会列出 ACPI 枚举出来的设备列表。如果这里能看到类似ACPI\ACPI0003的条目，说明枚举链路已经走通了。重点观察\_SB.ACAD节点是否在列表中，以及它对应的 PDO 指针是有效还是 0。
4.3 一次完整跟踪流程的记录
我之前调过一台问题机器，现象是电池栏显示 0%、插电不充电。启动断点上去以后，在ACPIDetectPdoDevices入口先bu住，然后放行到函数内部。因为函数会遍历多个节点，每次都中断很烦，我做了个条件断点，用模块名过滤不是 ACAD 的路径。
bu acpi!ACPIDetectPdoDevices ".if (poi(参数) != 'ACAD') { gc } .else { .echo ACAD node reached }"条件命中后单步执行，跟踪到它调用_STA的那一步。这里用!acpi或者直接读返回值。那次跟踪发现_STA返回了 0，整个节点被跳过。随后我去读 DSDT 里的 ASL 源码，发现那个机器的_STA实现里有一个 EC 寄存器读取操作，EC 在启动早段还处于复位状态，读到 0，固件就"诚实"地报告设备不存在。
解决方式不是改 Windows，而是调整固件：把 ACAD 的_STA改成返回 0xF，或者至少保证读取 EC 状态前有足够的延时可让 EC 稳定。改完后，重新刷固件，!acpi里就能看到 ACAD 节点，系统充电状态立刻恢复正常。
实操心得：如果
!acpi看不到 ACAD，不要急着认为是 Acpi.sys 的问题，先用 ACPI 表工具（比如 RW Everything 或者 ASL 反编译工具）看看 DSDT 里节点定义和_STA逻辑，排查顺序永远是"固件先、驱动后"。反复重装驱动解决不了枚举层的问题。
5. 常见故障与排查心得
5.1 症状速查表
ACAD 枚举相关问题，外在表现通常集中在电源管理上。以下是我整理的症状速查表：
| 症状 | 可能原因 | 排查方向 |
|---|---|---|
| 系统一直认为使用电池，插电源无反应 | ACAD 节点未被枚举 | _STA返回 0，检查固件 |
| 电池显示已连接但未充电 | ACAD 枚举了，但_PSR状态不一致 | 检查_PSR逻辑、EC 状态 |
| 插拔电源后状态不更新 | ACAD 的通知机制未建立 | 确认 PDO 是否创建，设备关系是否正确 |
| 设备管理器里看不到电源适配器 | 枚举失败 | WinDbg!acpi查看设备树 |
| 系统睡眠唤醒后电源状态异常 | ACAD 设备未处理唤醒通知 | 检查_PSW、_PRW等电源方法 |
5.2 怎么区分是固件问题还是 Acpi.sys 处理问题
排错第一原则：先确定问题在固件表达层，还是在系统处理层。
固件表达层问题非常典型：DSDT 里 ACAD 节点不存在、_HID写成一个非标值、_STA返回不稳定的值、_PSR没有实现。这些问题从 ASL 源码里一眼就能看出来。建议先把 DSDT 反编译，搜索ACAD，看一下节点里面定义了哪些方法、每个方法的返回值逻辑是什么。
系统处理层问题则表现为：ACPI 表正常，节点定义没有任何毛病，但设备就是不出来。这时候重点看ACPIDetectPdoDevices是否真的遍历到了这个节点。有可能是命名空间路径访问问题，比如枚举代码按某个固定深度枚举，而 ACAD 节点嵌套过深导致没走到。虽然这种情况在标准笔记本上少见，但在改过 ACPI 表的定制固件上确实可能发生。解决方式是修改固件，把 ACAD 节点移动到标准路径下。
区分两类问题的操作很简单：在ACPIDetectPdoDevices下断点，观察它有没有执行到与\_SB.ACAD相关的遍历深度。如果单步执行时函数已经离开子节点枚举循环都没碰到 ACAD，多半是固件路径不标准的问题。如果碰到了但被_STA挡掉，那就是固件状态判断问题。
5.3 我的几个落地经验
第一个经验：ACAD 的_HID建议写标准 ID。虽然老系统也许支持自定义 ID，但 Windows 的 ACPI 驱动对 ACPI0003 有明确的内置处理路径，自定义 ID 可能导致参数匹配异常。如果你的固件里写的是厂商自定义 ID，先把它改成标准 ID 再谈其他问题。
第二个经验：_STA的 bit0 和 bit1 必须为 1。我见过很多开发者只注意 bit0，返回 3 就是存在且启用。有些固件返回 0xF 之外的值，比如 0x1 或者 0x3，理论上也能让设备存在，但 Windows 某些内部逻辑会要求完整状态标志。最省事的就是返回 0xF，别在这里玩花活。
第三个经验：注意_PSR的返回值类型。ACPI 规范里_PSR返回整数，0 表示电池，1 表示 AC。但有些固件返回的是布尔值 true/false，有些直接返回 EC 寄存器的原始字节。如果数值含义弄反了，Windows 的电源管理就会把插电源当成拔电源。这类问题不会体现在枚举上，设备是正常出现的，但行为完全颠倒。调试时在 WinDbg 里查看_PSR的返回值，和硬件实际状态对照一遍，能快速锁定问题。
6. 工程建议：BIOS/DSDT 与驱动两侧的配合
这段写给做固件的朋友。ACAD 节点虽小，但它代表了一类典型问题：ACPI 枚举依赖于固件表达的正确性，而固件表达不仅仅是一张表，还包括了 ASL 代码的运行时行为。
BIOS 端设计建议三条：第一，ACAD 节点名称和路径保持标准，放\_SB下直接子节点最稳。第二，_STA从简，不要让启动时序影响判断。第三，_PSR的读取逻辑要保证在 S0 状态下任何时刻都能返回稳定结果，不要有未定义路径。
驱动端开发碰到的 ACAD 相关 bug，大部分不是 Acpi.sys 本身的问题，而是固件和系统之间对规范理解的错位。理解ACPIDetectPdoDevices对 ACAD 的处理逻辑，本质上就是在理解"ACPI 规范如何通过一个枚举器变成设备树上的现实"。这个函数没有任何魔法，它做的就是一个判断者该做的事：检查状态、确认身份、建立对象、注册通知。
我在实际调试里多次体会到，ACPI 枚举问题最怕的不是复杂，而是隐蔽。一些看似玄学的电源故障，最后追到底都是 ACAD 在枚举前被淘汰了。把断点下到ACPIDetectPdoDevices上，把_STA返回值盯住，把 DSDT 反编译出来一行行看，解决问题的路径就是这样朴素。如果你的项目里恰好在为电源状态诡异而苦恼，不妨也用这个思路查一遍，八成会有意想不到的收获。
