I2C HID设备代码10排查：从ACPI到GPIO中断的启动链路

在设备管理器里看到黄色感叹号，双击进去，"该设备无法启动。（代码 10）"，下面一行小字可能是STATUS_DEVICE_POWER_FAILURE，也可能干脆什么都不显示。很多人第一反应是卸载设备、重装驱动，装完重启一看还是 10；换个版本的触摸板驱动再装，还是 10。之所以反复无效，是因为代码 10 从来不在"驱动装没装"这个维度上——它是设备在 StartDevice 阶段被驱动或总线"打回来"的结果，问题出在更下面，在 ACPI 资源描述、GPIO 中断、I2C 控制器状态这条链路的某一环。

这篇内容讲的就是 I2C HID 设备（触摸板、触摸屏、笔、部分传感器）报代码 10 的完排查路径。适合谁看：手上有一台二合一或者轻薄本，触摸板突然不工作；做驱动开发或系统集成，需要判断是自己的 INF 写错了还是 BIOS 的 ACPI 表描述错了；或者只是想搞明白"为什么我重装八遍驱动都没用"。全文按 ACPI → 总线驱动 → HIDI2C → 事件日志 → 硬件固件这个自下而上的顺序拆，每一层都给可复现的检查动作，不堆概念。

1. 代码10对应的内核阶段：StartDevice被打回，而不是驱动缺失

先把这个错误码的语义钉死，后面所有判断才有基准。CM_PROB_FAILED_START 翻译成一句话就是：PnP 管理器已经给这个设备找好了驱动、分配好了资源、下发了IRP_MN_START_DEVICE，然后驱动在处理这个 IRP 的时候返回了一个失败状态。这跟代码 28（驱动未安装）、代码 31（无法加载所需驱动）、代码 43（驱动已报告设备故障但资源已分配）是不同阶段的错误。

区别很关键：代码 28 是"根本没找到 INF"，代码 43 是"启动过了，运行中报告故障"，代码 10 卡在"启动这一步没走完"。所以修复代码 10 的动作，本质上是在修复"启动过程依赖的某个前置条件"。

1.1 一个I2C HID设备启动时要走完的四件事

对于挂在 ACPI 下的 HID over I2C 设备（硬件 ID 常见形如ACPI\PNP0C50、ACPI\VEN_XXXX&DEV_XXXX），StartDevice 的处理链路比普通设备长，至少要完成四步：

把这四步拆开之后，排查思路就变成了"我现在卡在第几步"。而判断卡在哪一步，不需要拆机、不需要重装系统，设备管理器里就有足够信息。

1.2 三个只读信号，五分钟内锁定失败环节

第一个信号是设备实例路径。在设备属性 → 详细信息 → 属性下拉选"设备实例路径"，你会看到形如ACPI\PNP0C50\1或者ACPI\VEN_ELAN&DEV_0633\4&2b7c9d1&0的字符串。这个路径的后半段是 ACPI 命名空间里的 UID，前半段是_HID/_CID。如果路径里带VEN_前缀的厂商 ID，说明 ACPI 表里写的是厂商自定义 HID，走的还是标准 HIDI2C 驱动；如果只有PNP0C50，说明是通用描述。这个信息决定了你后面去查哪一份 ACPI 表。

第二个信号是父设备的启动状态。在设备管理器里点"查看 → 依连接排序设备"，找到这个报 10 的设备，看它的父节点。正常情况下父节点是一个 I2C 控制器（显示名可能类似"Intel(R) Serial IO I2C Host Controller"或"标准 I2C 控制器"）。如果父节点本身带感叹号，那子设备报 10 是必然的，先修父节点。如果父节点是好，但再往上的 GPIO 控制器是"Microsoft 基本 GPIO 控制器"这种通用驱动，那中断路径大概率有问题，后面第 3 章会细讲。

第三个信号是资源选项卡里的中断类型。设备属性 → 资源选项卡，看"中断"那一行。健康的 HID over I2C 设备这里应该显示为IRQ加一个类似0x0000000000000021的数值，且"拥有者"是 GPIO 控制器转出来的。如果这里显示"该设备没有使用任何资源"或者中断项为空，说明_CRS里的 GpioInt 描述没有被成功解析，问题在 ACPI 这一层，不在驱动。

提醒：资源选项卡在部分系统上对 ACPI 枚举设备不显示完整资源列表，这时候要用Get-PnpDeviceProperty去取DEVPKEY_Device_AssignedResources，比界面可靠。

1.3 为什么"卸载重装"这个动作经常无效

卸载设备只能清掉HKLM\SYSTEM\CurrentControlSet\Enum下这个设备实例的配置，重新枚举时会重新读 ACPI 表、重新分配资源、重新走一遍 StartDevice。如果失败原因是 ACPI 表描述错误、GPIO 驱动不支持、或者固件处于挂死状态，那么重新枚举一万次结果都一样——因为前置条件一个都没变。

真正有意义的重装是"换掉上层那个有问题的驱动"，而不是"换掉报错这个设备"。这个判断顺序搞反了，就会陷入无休止的卸载重装循环。

2. ACPI描述层：_DSM、_CRS、_DEP三个方法的易错点

I2C HID 设备的所有"硬件信息"都是 ACPI 表告诉操作系统的：你在哪个 I2C 控制器上、从地址多少、中断走哪根 GPIO、HID 描述符存在哪个寄存器。这层信息一旦错，上层代码再正确也没用。而这一层恰恰是 BIOS 更新、主板换型、镜像迁移之后最容易出问题的地方。

2.1 _DSM返回的HID描述符地址，错了就是读不到

HID over I2C 协议规定，设备的 HID 描述符存放在 I2C 从设备的一段寄存器空间里，具体起始地址和长度不是固定的，由 ACPI 的_DSM方法（功能索引 1）返回一个两元素包：{寄存器地址, 长度}。hidi2c.sys 在 StartDevice 的最初阶段就会调用这个方法，拿到地址后发起一次 I2C 读，把描述符拉回来。

一份健康的 ASL 大概长这样：

Method (_DSM, 4, NotSerialized) { If ((Arg0 == ToUUID("3cdff6f7-4267-4555-ad05-b30a3d8938de"))) { If (Arg2 == 1) { Return (Package() { 0x0020, 0x01E4 }) } } Return (Buffer() { 0x00 }) }

这里的0x0020是 HID 描述符寄存器的地址，0x01E4是长度。如果 BIOS 里把这个地址写成了0x0001（也就是命令寄存器），驱动读回来的就是命令寄存器的内容，长度校验过不去；如果返回长度是 0，驱动会直接判定描述符无效。两种情况都表现为 StartDevice 失败，设备管理器报代码 10，事件日志里能看到一条HIDI2C: Failed to retrieve HID descriptor。

这个坑什么时候会遇到？一是 BIOS 升级后厂商改了_DSM实现（尤其是解决休眠唤醒问题时顺手改的），二是把一台机器的系统镜像整盘迁到了另一台机器上，三是某些工程样机或改装主板本身 ACPI 表就没写对。判断方法很直接：用 ACPI 表导出工具把当前机器的 DSDT/SSDT 拉出来，搜索对应设备的_DSM，看返回值是不是符合协议。

2.2 GpioInt与普通Interrupt：写错了中断永远连不上

这是 I2C HID 报代码 10 最高频的 ACPI 层原因。HID over I2C 设备的中断请求线不是传统的 ISA/LAPIC 中断，而是一根 GPIO 引脚，需要在_CRS里用GpioInt宏描述：

GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullUp, 0, "\\_SB.GPI0", 0, ResourceConsumer) { 0x0021 }

它声明了六件事：边缘触发、低电平有效、独占且可唤醒、内部上拉、去抖时间、所连接的 GPIO 控制器路径、引脚号。任何一项和实际硬件不符，都可能导致中断请求无法成功连接。

我在实际排查中遇到过的几种典型错法：把GpioInt写成了Interrupt（用传统 IRQ 描述），驱动拿到资源后发现没有 GPIO 连接，中断初始化直接失败；ActiveLow写成了ActiveHigh，设备能启动但一碰就卡死（这种通常报 43 而不是 10）；ExclusiveAndWake写成了Shared，两个设备抢一根线，谁先启动谁成功，另一个报 10，而且现象是"时好时坏"，特别迷惑人。

最后这种"时好时坏"的代码 10 是最难查的，因为每次重启结果不一样。判断依据是：出现故障时看事件日志里 Kernel-PnP 的事件 ID 411（设备启动失败），确认失败的是哪一个实例，然后核对两个设备的_CRS是否指向了同一个 GPIO 引脚号。

2.3 _DEP缺失导致的启动顺序倒挂

_DEP（Dependency）方法在 ACPI 规范里是一个容易被忽略的机制，它告诉 PnP 管理器："这个设备依赖某几个设备，在那几个设备启动完成之前不要启动我。"对于 I2C HID 设备，正常情况下应该声明依赖 I2C 控制器和 GPIO 控制器：

Method (_DEP, 0, NotSerialized) { Return (Package() { \_SB.GPI0, \_SB.I2C0 }) }

如果 BIOS 漏写了这个方法，Windows 有可能在 GPIO 控制器还没完成初始化的时候就去启动 HID 设备，中断资源申请失败，报代码 10。这种故障的特征是冷启动时概率性出现，热重启后恢复正常，因为热重启时设备枚举顺序恰好变了。

判断方法：在设备管理器里看故障设备的"位置"属性，确认它的父设备是否都已正常启动。如果父设备在故障时刻处于"正在启动"或带感叹号状态，基本可以确认是启动顺序问题。这种问题用户侧无法彻底修，只能靠 BIOS 更新，或者用pnputil在启动后手动禁用再启用一次设备绕过。

3. 驱动栈自下而上验证：GPIO、I2C控制器、HIDI2C逐层确认

ACPI 表是"说明书"，驱动栈是"执行者"。说明书没错，执行者出问题一样报 10。这一层的排查原则是严格自下而上，不能跳级——因为下层的故障会伪装成上层的错误。

3.1 GPIO控制器：中断到底能不能送进系统

I2C HID 设备的中断依赖 GPIO 控制器把引脚电平变化翻译成一个可被系统识别的中断。这块由两部分组成：GPIO 控制器的驱动，和 GPIO 到中断控制器的路由。

在设备管理器里展开"系统设备"，找到 GPIO 控制器。健康状态下显示的是平台厂商提供的专用驱动名（形如"Intel(R) Serial IO GPIO Controller"或芯片组配套的 GPIO 驱动）。如果显示成"Microsoft 基本 GPIO 控制器"或者"GPIO 控制器（通用）"，说明专用驱动没装上，系统用的是通用驱动。

通用驱动能实现基本的读写和中断转发，但功能集是不完整的：它往往不支持某些电源管理特性、不支持 D3cold 状态下的唤醒、对ExclusiveAndWake这类独占加唤醒的中断请求支持有限。表现出来就是设备能启动成功但没反应，或者干脆启动失败报 10。我遇到过好几例，装完平台芯片组的 Serial IO 驱动包之后，代码 10 直接消失。

检查专用驱动是否装上，用一条命令就够：

Get-PnpDevice -Class System | Where-Object { $_.FriendlyName -match 'GPIO|Serial IO|I2C' } | Select-Object Status, Class, FriendlyName, InstanceId | Format-Table -AutoSize

如果输出里有带感叹号的项，或者只有"Microsoft 基本 GPIO 控制器"，那就是缺驱动。注意 Serial IO 驱动包是一个整体，I2C 和 GPIO 通常在一个安装包里，但可能因为安装顺序或版本不匹配只装上了一半。

3.2 I2C控制器本身的状态与电源配置

父设备 I2C 控制器如果状态正常，说明它在 PnP 层面启动了，但不代表它能正常传输数据。这里有个隐蔽的坑：I2C 控制器进入了错误的低功耗状态。

在设备管理器里打开 I2C 控制器的属性 → 电源管理选项卡，看"允许计算机关闭此设备以节约电源"是否被勾选。对于某些平台的 I2C 控制器，这个选项勾上之后，控制器在系统空闲时会进入 D3，而 HID 设备在同一时刻可能还有输入请求在排队，唤醒不及时就会导致 StartDevice 失败。

验证方法是临时取消勾选，重启后观察。如果代码 10 消失，基本可以确认是电源时序问题。这不算根治方案（会轻微增加待机功耗），但足以证明问题域。

另外要看 I2C 控制器有没有报资源冲突。设备属性 → 资源选项卡，如果内存范围或中断有红色的冲突提示，说明有别的设备占了同一段资源，这时候要顺着冲突去找那个抢占的设备。

3.3 HIDI2C服务与厂商过滤驱动的加载顺序

在 I2C 控制器之上，是系统自带的 HIDI2C 驱动（hidi2c.sys），由它来创建设备对象、读描述符、注册到 HIDCLASS。再往上，部分厂商会装一层过滤驱动（触摸板手势增强、防误触、快捷键），这层过滤驱动是可选的，但它常常是代码 10 的元凶。

判断方法：查看设备属性 → 驱动程序 → 驱动程序详细信息，看加载的驱动文件列表。正常应该只有hidi2c.sys、hidclass.sys、hidparse.sys这几个系统组件。如果多出厂商的过滤驱动（文件名通常带品牌标识），可以尝试禁用：

# 先列出所有 HID 类设备及其服务 Get-PnpDevice -Class HIDClass | Select-Object FriendlyName, InstanceId, Service | Format-Table -AutoSize # 禁用指定设备（用上面的 InstanceId 替换） Disable-PnpDevice -InstanceId "ACPI\PNP0C50\1" -Confirm:$false Enable-PnpDevice -InstanceId "ACPI\PNP0C50\1" -Confirm:$false

这个禁用再启用的动作本身也是一个快速验证：如果禁用后启用能暂时恢复，说明硬件和资源描述都是好的，问题在软件层的初始化时序或驱动冲突，范围就缩小了很多。

还有一种情况是 HIDI2C 服务被设置成了手动或禁用启动。服务名是hidi2c，用sc query hidi2c确认状态是 RUNNING。如果是 STOPPED 且启动类型是 Disabled，改成 Demand 后重启即可。这个改动一般不会无故发生，但某些"系统优化"类工具确实会顺手关掉它。

4. 用事件日志把"10"翻译成具体错误码与失败阶段

设备管理器只告诉你"失败了"，不告诉你"为什么失败"。真正的错误信息在事件日志和内核调试器里。

4.1 Kernel-PnP事件ID的对应关系

打开事件查看器 → Windows 日志 → 系统，筛选来源为Microsoft-Windows-Kernel-PnP。几个关键事件 ID：

411 事件的详情里会有一个Status字段，通常是0xC000009A（STATUS_INSUFFICIENT_RESOURCES）、0xC00000C4（STATUS_DEVICE_POWER_FAILURE）、0xC0000185（STATUS_IO_DEVICE_ERROR）或者0xC0000143（STATUS_NO_SUCH_DEVICE）。

这几个状态码的指向性很强：INSUFFICIENT_RESOURCES通常意味着中断或内存资源分配失败，重点看_CRS和资源冲突；DEVICE_POWER_FAILURE意味着上电或电源状态切换失败，重点看_PR0/_PR3和 Reset GPIO；IO_DEVICE_ERROR通常是 I2C 传输本身出错，重点看总线速率、上拉电阻、从设备地址；NO_SUCH_DEVICE则是设备根本没应答，指向固件挂死或供电缺失。

用 PowerShell 可以批量拉取最近的相关事件，比手工点界面快：

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-PnP'; Id=411} -MaxEvents 20 | Select-Object TimeCreated, @{n='Message';e={$_.Message -replace "`r`n", ' '}} | Format-List

4.2 WinDbg下看StartDevice失败在哪一行

如果事件日志给的状态码还不够具体，就要上内核调试。本地内核调试或者双机调试都行，关键是打开 PnP 和 HIDI2C 的诊断输出。

第一件事是确认设备对象存在但未启动：

0: kd> !devnode 0 1 ACPI

这会列出 ACPI 枚举树，找到你那个设备节点，看它的State字段。如果显示DeviceNodeStarted以外还有ProblemCode = 0x0A，就确认了是 PnP 层面的启动失败。

接着看设备对象和它的驱动对象：

0: kd> !devobj ffffd40a`12345678 0: kd> !drvobj \Driver\hidi2c 2

!drvobj输出的 DriverObject 里能看到DeviceObject链表和AddDevice的地址，可以确认 hidi2c 是否成功创建了设备对象。如果设备对象存在但AttachedDevice链是空的，说明 StartDevice 根本没走进去，问题在资源分配阶段；如果设备对象不存在，说明 HIDI2C 压根没被调用，问题在 INF 匹配或者父设备枚举。

再进一步，用!irp看挂起或失败的 IRP：

0: kd> !irpfind -a

找目标设备相关的 IRP_MJ_PNP，看它的Status字段。如果能看到IRP_MN_START_DEVICE对应的 IRP 返回了错误状态，错误位置（IoStatus.Status）就是最原始的失败原因。

这套操作看起来很重，但它的价值是把"设备无法启动"这个黑盒打开。普通的驱动重装是在黑盒外面反复摇，内核调试是直接进去看。

4.3 Enum分支残留与设备实例清理

有一种代码 10 是"假故障"：设备本身完全正常，但是Enum分支下残留了一份错误的配置（比如上一次的驱动版本号、资源分配记录），导致重新枚举时用了旧数据。

判断方法：在注册表里定位到HKLM\SYSTEM\CurrentControlSet\Enum\ACPI\<硬件ID>\<实例>，看里面的Driver、ConfigFlags、Service值是否合理。如果ConfigFlags带了0x400（CONFIGFLAG_FAILEDINSTALL）或者其他异常位，说明这个分支被标记过安装失败。

清理的正确姿势是：先卸载设备（同时勾选"删除此设备的驱动程序软件"），然后重启让系统重新枚举。如果残留太顽固，可以用pnputil配合设备实例 ID 彻底移除：

# 列出所有有问题的设备 pnputil /enum-devices /problem # 移除指定实例（注意这会把设备从系统里摘掉，重启后重新枚举） pnputil /remove-device "ACPI\PNP0C50\1"

注意：/remove-device对 ACPI 枚举设备是安全的，重启会重新枚举出来；但如果用在 PCI 或 USB 设备上，某些情况下需要重新扫描总线才能恢复。动手前先记下设备的完整实例 ID。

5. 硬件侧的假故障：固件挂死、BIOS开关与状态残留

排完软件层还是代码 10，就要考虑硬件和固件了。这一层最容易被忽略，因为"设备在设备管理器里显示出来了"这件事本身给人一种"硬件没问题"的错觉。实际上设备能被枚举出来只说明供电和地址应答正常，不代表内部固件在正常工作状态。

5.1 触摸板固件挂死的识别特征

I2C HID 设备内部是一个 MCU，跑着自己的固件。这个 MCU 有可能进入挂死状态：能应答 I2C 地址探测（所以设备还能被枚举出来），但不响应 HID 描述符读取（所以 StartDevice 失败）。

识别特征很明确：故障出现在某次休眠唤醒、某次静电事件、或者长时间高负载使用之后，且重启无效、关机再开有效。因为关机（不是重启）才会切断 MCU 的供电，让它重新上电复位。

如果关机再开能好，但过几天又复发，说明这个固件存在稳定性问题，属于厂商侧的责任。缓解手段是关闭系统的快速启动——快速启动实际上是"混合关机"，只有内核会话被休眠，设备不断电，等于没有真正复位：

# 查看快速启动状态 powercfg /a # 关闭快速启动（管理员权限） powercfg /h off

关掉休眠之后快速启动也会一起失效，代价是开机慢几秒、休眠功能不可用，但对排查这类"关机才算真关机"的问题非常有效。

5.2 BIOS里与I2C、GPIO相关的几个开关

有几个 BIOS 选项会直接影响 I2C HID 设备能否启动，而且它们的名字往往不直观：

• Touchpad / Internal Pointing Device：部分商务本有这个开关，关闭后设备仍然枚举但报错。
• Serial IO / LPSS Configuration：平台芯片组的低功耗子系统配置，如果把某个 I2C 控制器设为 Disabled，挂在它下面的设备必然报 10。
• GPIO Lock / Pin Configuration：某些主板允许锁定 GPIO 配置，锁定后 ACPI 里的GpioInt描述可能失效。
• Modern Standby / S0ix：开启后设备需要支持 D3cold 和唤醒，如果设备的_PR3电源资源描述不完整，会在启动时失败。
• Secure Boot 与 Memory Integrity：这两个会影响驱动签名校验，非签名或旧签名的 I2C/GPIO 驱动会被拒绝加载。

前三个是"配置错误"，第四个是"能力缺失"，第五个是"加载被拦"。它们的共同点是：BIOS 里改了设置之后，系统侧的表现可能延迟到下一次完全断电重启才显现。这也是为什么"我什么都没改啊"这种说法在 BIOS 层面经常不成立。

5.3 双系统与快速启动带来的状态残留

装双系统的机器上，这个问题出现频率明显偏高。原因是 I2C HID 设备的固件状态是跨操作系统共享的——在另一个系统里如果设备没有被正确复位（比如那个系统直接热重启，没走完整的关机流程），设备会带着一个"已初始化"的状态进入 Windows，而 Windows 的 HIDI2C 驱动期望的是冷启动状态，握手失败就报代码 10。

还有一种情况是设备在两个系统之间被配置了不同的工作模式（比如一个是 I2C 模式、一个是 HID over I2C 模式），切换时没做复位。

处理方式是：从另一个系统里正常关机（不是重启、不是休眠），等电源指示灯完全熄灭，再开进 Windows。如果这样能恢复，那说明就是状态残留问题，可以在另一个系统的关机脚本里加一次 GPIO 复位动作来根治。

另外，雷电扩展坞、USB-C 扩展坞上的外接触摸屏、外接键盘，如果走的是 I2C over USB-C 的 Alternate Mode，拔出时机不对也会留下残留状态，导致下次插入时设备报 10。这类问题通常重新插拔一次就好，但要知道它的存在，免得误判成主板故障。

6. 分阶段排查清单：从五分钟只读诊断到深度处置

前面五章是"原理"，这一章是"动作"。我把它按风险分成三个阶段，前两个阶段都是可逆操作，第三个阶段才开始动系统配置。

6.1 第一阶段：只读诊断，不改任何东西

这一阶段的目标是收集足够信息，判断问题落在哪一层，耗时控制在十分钟以内。

1. 记录设备实例路径、硬件 ID、兼容 ID（设备属性 → 详细信息）。
2. 记录父设备的启动状态，逐级往上找到 I2C 控制器和 GPIO 控制器。
3. 看资源选项卡里的中断项是否存在、是否冲突。
4. 拉最近 20 条 Kernel-PnP 事件，重点看 411 的 Status 字段。
5. 确认hidi2c服务状态是 RUNNING。
6. 确认系统设备里 GPIO 控制器是专用驱动还是"Microsoft 基本 GPIO 控制器"。

这六条信息凑齐之后，基本能得出一个初步结论。举几个映射关系：中断项为空 + ACPI 层资源描述可疑 → 查_CRS；Status 是INSUFFICIENT_RESOURCES+ 有资源冲突 → 找抢占设备；Status 是IO_DEVICE_ERROR+ 关机再开能好 → 固件挂死；GPIO 是通用驱动 → 缺 Serial IO 驱动包。

6.2 第二阶段：驱动与设备重枚举，全部可逆

这一阶段的动作都是系统原生支持的，做完可以还原。

1. 安装或修复平台芯片组的 Serial IO 驱动包。顺序很重要：先装 GPIO，再装 I2C，最后装 HID 相关组件。反过来的话，I2C 控制器可能在 GPIO 就绪前就尝试枚举子设备，反而制造出新的代码 10。
2. 禁用再启用故障设备，观察是否恢复。
3. 如果恢复但重启后复发，把 I2C 控制器的"允许计算机关闭此设备以节约电源"取消勾选，再重启验证。
4. 卸载设备并勾选删除驱动，重启让系统重新枚举。这一步会重读 ACPI、重新分配资源，能排除掉 Enum 分支残留的因素。
5. 关闭快速启动，做一次完全关机（不是重启），再开机验证。这一步专门用来排除固件状态残留。

做完这五步还不好，说明问题不在驱动层，不要再继续折腾驱动了——继续重装只会浪费时间，还可能把正常的驱动版本搞乱。

6.3 第三阶段：深度处置与止损

到这一步，要么是 ACPI 表本身有问题，要么是硬件确实有故障，两种情况的处置方式完全不同。

如果是 ACPI 表问题，判断依据是：更换 BIOS 版本之后现象变化、或者在另一台同型号机器上不复现。这种情况用户侧能做的不多，能尝试的是更新到最新 BIOS、或者回退到已知稳定的 BIOS 版本。如果设备还在保修期内，把_DSM/_CRS的导出结果作为证据提交给厂商，比只说"触摸板不工作"有效得多。

如果是硬件问题，判断依据是：完全断电重启后仍然报 10、换到另一个系统（比如临时挂一个 PE 环境）也报 10、事件日志里的状态码在多次尝试中始终一致且指向 IO 错误。这时候要考虑排线接触不良（尤其是拆过机的机器）、触摸板本身的 MCU 损坏、或者主板上的 I2C 上拉电阻异常。

还有一个止损技巧值得说：如果这台机器是工作机，触摸板一时半会儿修不好，可以在 BIOS 里禁用内置触摸板，然后接一个 USB 触摸板或者鼠标先用着。禁用之后设备管理器里那个报 10 的条目会消失（变成隐藏设备），系统启动时也不会再去尝试初始化它，能顺带排除掉"这个设备拖慢开机"的怀疑。

我自己处理这类问题的习惯是：先把 411 事件的 Status 码记下来，再去动手。因为很多修复动作（重装驱动、断电重置）一旦做了，原本的错误状态就被覆盖，再想回头确认"当初到底是哪个错误码"就查不到了。这个习惯帮我省过好几次返工——有两次我以为是驱动问题，记下状态码之后才发现是INSUFFICIENT_RESOURCES，直接跳过了所有重装步骤，去查资源冲突，五分钟解决。

最后分享一个查 ACPI 表的小技巧：不需要装额外的驱动或者进调试模式，直接用系统的pnputil /enum-devices /deviceids配合设备属性里的"BIOS 设备名称"字段，就能拿到 ACPI 命名空间里的设备路径，然后对着导出的 DSDT 搜这个路径，比盲目搜索硬件 ID 准确得多。