余淏上周帮一台Windows Server 2022排查设备安装问题时，设备管理器里一直挂着一个“未知设备”，驱动文件明明已经装到系统里，INF路径也看得见，可设备就是起不来。手动更新驱动提示“指定的文件夹没有包含设备的兼容软件”，用setupapi.dev.log看了半天，只看到一行很干脆的注册表操作失败。这种问题在用户态能查的手段基本都用尽了，最后只能把WinDbg拉出来，直接在内核态盯着设备枚举路径走一遍，才把问题定位到 nt!PiProcessNewDeviceNode 里的一次 nt!PiCreateDeviceInstanceKey 调用上。
nt!PiCreateDeviceInstanceKey 在ntoskrnl.exe的符号里存在，但微软从未公开过它的原型，任何官方文档都查不到它。它负责的却是即插即用设备管理中极关键的一环：为新设备节点创建注册表里的设备实例键（Device Instance Key）。一旦这一步失败，驱动加载、资源分配、设备状态记录这些后续动作全部都会断掉。这篇文章我按实际排查的思路，把设备节点处理流程、这两个函数各自负责的事、以及在调试器里怎么验证它们的调用关系完整梳理一遍。对做驱动开发、内核调试、或者搞Windows底层排障的人来说，这条调用链是绕不开的必修课。
1. 一次“未知设备”排障把我引向了nt!PiCreateDeviceInstanceKey
1.1 驱动在、设备也在，为什么就是装不上
当时那台服务器上有个PCIe设备，属于比较老的第三方硬件。设备管理器里能看到一个带问号的未知设备，查看硬件ID也能看到PCI\VEN_xxxx&DEV_xxxx这样的标识，说明PnP管理器确实枚举到了设备，设备节点已经建立。但你要给它手动指定inf，系统死活不认。
我第一反应是INF签名或者驱动架构问题。结果检查一遍，x64驱动，签名证书正常，哈希也没问题。接着打开C:\Windows\INF\setupapi.dev.log，日志里很明确地写着注册表操作失败，但具体哪个键、哪一步失败，日志不会给你细到内核函数的程度。ProcMon挂上去之后，能看到针对HKLM\SYSTEM\CurrentControlSet\Enum下某个路径的RegCreateKey操作返回了ACCESS_DENIED，但ProcMon只能告诉你“哪一步操作失败”，它没法告诉你“是内核里哪个函数在哪条调用链上发起的操作”。
这种场景就很典型：用户态工具能定位到“注册表出问题了”，但真正要判断是哪个内核模块在什么时机、以什么安全上下文写入失败，必须去内核态看函数调用链。
1.2 设备实例键到底是个什么东西，为什么它失败影响这么大
设备实例键的路径固定在HKLM\SYSTEM\CurrentControlSet\Enum下，后面跟着枚举器（Enumerator）、设备ID、实例ID，比如：
code复制HKLM\SYSTEM\CurrentControlSet\Enum\PCI\VEN_8086&DEV_1234&SUBSYS_00008086&REV_00\5&2b3a1c44&0&18
这个键是设备实例的“户口本”。硬件ID、兼容ID、设备描述、驱动服务名、类GUID、安全描述符、ContainerID全部存在这个键下面。内核的PnP管理器、驱动加载器、用户态的设备和打印机管理器，都靠这个键来确认设备身份和状态。
如果说DEVNODE是设备在内核对象树里的存在，那设备实例键就是设备在注册表里的存在。内核里的DEVNODE断电就没了，注册表里的设备实例键则让设备在重启后依然能被识别、被匹配驱动。所以 PiCreateDeviceInstanceKey 就是“内核对象世界”和“注册表持久化世界”之间的那个桥梁。它一旦失败，后面找驱动、加载驱动、记录状态全部无从谈起。
1.3 为什么这种问题常规排查手段查不到根因
setupapi.dev.log和ProcMon能告诉我们“注册表写入被拒绝”，但注册表路径只是一个结果。设备枚举这个动作发生在PnP管理器处理设备节点的上下文中，通常运行在System进程里，是一个高度内聚的内核流程。你要知道是谁在写、为什么写、写到哪一步被拒，最直接的办法就是在 PiCreateDeviceInstanceKey 下断点，看它返回的NTSTATUS，看它的参数里挂的是哪个DEVNODE，然后往上回溯调用栈。
那次问题最终的结论是Enum目录下某个子键的安全描述符被之前的安全加固脚本改坏了，DeviceInstaceKey创建时打开父键失败，返回0xC0000022（STATUS_ACCESS_DENIED）。修好之后设备一切正常。这次经历让我彻底把这两个内核函数在心里的位置提了上来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PiProcessNewDeviceNode到底在设备枚举流程里干了什么
2.1 设备节点（DevNode）是PnP世界的基本单位
Windows的PnP系统以设备树（Device Tree）的形式管理所有设备，树上每个节点就是一个设备节点，内核里对应结构体是 nt!_DEVICE_NODE。设备树本身是分层的：根总线下面是PCI、ACPI这类总线设备，总线设备下面再挂实际功能设备。硬件热插拔、驱动重载、资源重平衡这些动作，本质上都是对这颗设备树上的节点做状态迁移。
_DEVICE_NODE 里的信息很多，但排障时最常用的是这几个字段：Parent（父节点）、ChildList（子设备链表）、InstancePath（实例路径）、State（节点状态）、Level（设备树层级）。用WinDbg看一个设备节点的状态，常常就是 dt nt!_DEVICE_NODE 一把梭。
code复制kd> dt nt!_DEVICE_NODE 0xffffe0015b3ae010
输出里能看到设备树的父子关系、状态、还有指向设备ID的指针。这个结构体里没有直接写“下一步要干什么”，具体执行逻辑全在函数调用栈里。
2.2 从设备枚举到PiProcessNewDeviceNode的调用路径
当总线驱动（比如PCIe驱动、ACPI驱动）发现新硬件时，会向PnP管理器报告新的子设备。PnP管理器会为这个设备创建DEVNODE、分配资源、寻找匹配的驱动，并创建对应的设备实例键。这一整套兜底逻辑里，nt!PiProcessNewDeviceNode 是核心入口之一。
从实际调试和公开逆向资料整理出来的调用关系大体是：
text复制ZwCreateFile / Ioctl -> IopInitializeDeviceNode -> PiProcessNewDeviceNode -> PiCreateDeviceInstanceKey
PiProcessNewDeviceNode 这个名字里的“Process”很有误导性，让人以为是“处理设备节点”的通用入口。实际上它处理的是“新设备节点”的首次落地，重点集中在：
- 根据总线驱动给的信息组装设备的身份信息；
- 在注册表里创建设备实例键（调PiCreateDeviceInstanceKey）；
- 检查设备是否曾经被卸载或禁用，恢复相应状态；
- 发起驱动搜索匹配，把设备的服务键指向匹配的驱动；
- 启动设备节点状态机，让设备进入开机/停止/重启等正常流转。
所以如果你看到系统启动时、或者热插拔设备时，CPU在 nt!PiProcessNewDeviceNode 里停留，不要觉得奇怪。它正在给一个“无户籍”的设备上户口。
2.3 “新节点”和“已有节点”差别很大，这也是本函数存在的原因
设备名相同不代表设备是同一个实例。PnP管理器会通过实例ID（Instance ID）区分同一个硬件ID下多个实例。第一次看到一个硬件ID时，必须创建全新的设备实例键；再次看到同样的硬件ID，则会走“打开已有键、更新状态”的路径。
这一步的差别非常重要。在排障中我们经常遇到一个现象：设备实例键已经存在，但状态是错误状态（比如被标记为需要卸载、或禁用了），此时 PiProcessNewDeviceNode 走到实例键处理时，不会直接覆盖写一份干净的键，而是会复用旧键，把设备状态从注册表里读出来，继续往下执行。
所以当你发现“设备明明第一次插，怎么注册表里Enum下面已经有它了”，不必惊讶。要么是之前同一实例ID被写入过没清理，要么是系统镜像封装时带进去的。这也正是很多“旧设备迁移”问题的根源：注册表里的实例键状态与实际设备状态不一致，而 PiProcessNewDeviceNode 就是那个需要协调二者一致性的地方。
3. 深入PiCreateDeviceInstanceKey：写键值之前的那些关键步骤
3.1 未公开函数的原型，靠调试器还原
PiCreateDeviceInstanceKey 没有文档，但通过WinDbg的符号和反汇编，可以非常确定它的核心调用逻辑。常见调用形式大约是这样的：
cpp复制NTSTATUS PiCreateDeviceInstanceKey(
_DEVICE_NODE *DeviceNode,
PUNICODE_STRING DeviceInstanceKeyPath,
ULONG Flags, // 是否覆盖、是否继承安全描述符等
PVOID SecurityDescriptor)
第一个参数必然指向当前正在处理的DEVNODE，第二个参数是设备实例键路径的UNICODE_STRING，后面的参数是标志和安全描述符。具体参数细节不必过度纠结，因为你在调试时更需要的不是“自己调用它”，而是“理解它为什么失败”。
从反汇编来看，这个函数的内部动作大致是：
- 取出DeviceNode里的枚举器名称和设备ID；
- 拼接出
\Registry\Machine\SYSTEM\CurrentControlSet\Enum\…完整路径； - 调用
ZwCreateKey打开或者创建这个键； - 写入安全描述符，设置设备节点保护属性；
- 写入硬件ID、兼容ID、设备描述、类GUID等核心键值；
- 最后把设备节点状态更新为“实例键已创建”。
3.2 它写入的键值清单，比INF里写的多得多
设备实例键里到底存了哪些东西，这个在调试时非常关键。下面这张表是我在排障中最常关注的几个值：
| 键值名 | 类型 | 来源/含义 |
|---|---|---|
| HardwareID | REG_MULTI_SZ | 设备硬件ID列表，INF的Models段靠它匹配 |
| CompatibleIDs | REG_MULTI_SZ | 兼容ID列表，用于宽松匹配 |
| ContainerID | REG_SZ | 设备容器ID，决定多个设备是否归同一物理设备 |
| Service | REG_SZ | 驱动服务名，指向对应内核服务 |
| ClassGUID | REG_SZ | 设备类GUID，设备管理器分类依据 |
| Class | REG_SZ | 设备类名称 |
| DeviceDesc | REG_SZ | 设备描述，设备管理器里显示的名称 |
| Mfg | REG_SZ | 制造商名称 |
| Driver | REG_SZ | 指向当前使用的驱动键路径 |
| Capabilities | REG_DWORD | 设备能力标志 |
| Security | REG_BINARY | 设备安全描述符 |
| ParentIdPrefix | REG_SZ | 父设备ID前缀，USB等设备使用 |
很多人以为这些信息是INF安装时写进去的，这是一个非常普遍的误解。INF驱动安装时写的是系统驱动库里的信息，而设备的硬件ID、兼容ID、描述这些关键身份数据，是设备枚举阶段由PnP管理器调用 PiCreateDeviceInstanceKey 时根据设备节点里的信息直接写入的。INF只是后面匹配驱动时的参考物。
也就是说：即便你有一个绝对正确的INF，如果设备实例键里HardwareID没有写对，后续驱动搜索匹配依然找不到你。这也是我在排障时从“看INF对不对”转向“看设备实例键对不对”的重要原因。
3.3 失败路径和NTSTATUS，哪些能忽略、哪些必须查
PiCreateDeviceInstanceKey 的返回值直接决定了 PiProcessNewDeviceNode 后续分支怎么走。常见的NTSTATUS对应关系如下：
| NTSTATUS | 含义 | 排障建议 |
|---|---|---|
| 0x00000000 STATUS_SUCCESS | 键已创建/打开 | 正常 |
| 0x00000000（实际为打开已有键成功） | 键已存在但直接打开 | 多数情况正常 |
| 0xC0000035 STATUS_OBJECT_NAME_COLLISION | 键已存在 | 通常是重复枚举，不致命，走打开路径 |
| 0xC0000022 STATUS_ACCESS_DENIED | 父键权限不足 | 立即检查Enum目录安全描述符 |
| 0xC000003A STATUS_OBJECT_PATH_NOT_FOUND | 父键路径不存在 | 检查枚举器目录是否被误删 |
| 0xC0000001 STATUS_UNSUCCESSFUL | 通用失败 | 结合设备节点状态和总线驱动信息查 |
我见过不少人在ProcMon里看到STATUS_OBJECT_NAME_COLLISION就紧张，以为设备注册表冲突了。实际上设备实例键创建时路径上已经存在同名键，是一个非常普通的情况，函数内部会走“打开已有键再更新”的分支。真正要警惕的是ACCESS_DENIED和PATH_NOT_FOUND，这两个通常意味着系统级问题——注册表被外部工具篡改、安全软件强制限权、或者Sysprep封装时有残留。
3.4 为什么这个函数不只是ZwCreateKey那么简单
有人可能会问：创建设备实例键不就是调一个 ZwCreateKey 把值写进去吗，为什么要单独封装一个函数来处理？
关键在于设备的身份不是静态的。硬件ID、兼容ID可能来自多个来源：总线驱动返回的DeviceProperty、ACPI固件表、设备自身描述符等。设备实例键要在这一个函数里把这些来源串起来，还要处理安全描述符继承、容器ID计算、设备迁移标记、设备覆盖标志等一堆隐形逻辑。
特别是安全描述符。设备实例键的Security值决定了后续哪些用户态服务能访问这个设备的设备接口，一旦写错或者缺失，设备可能看得到但用不了。容器ID的生成也一样，它会决定Windows能不能把蓝牙鼠标和内置蓝牙适配器归到同一个设备容器里，这直接影响设备管理器的分组界面和某些功能联动。这些逻辑看起来是注册表写入，实际上已经是设备管理策略的一部分了。
4. WinDbg实战：如何在下一条断点里看清键名、设备路径和返回值
4.1 先下断点再触发设备枚举
调试这种问题时不要一上来就盲追。先下好断点在两个函数上，然后触发设备枚举，等断点命中再看现场：
code复制kd> bu nt!PiProcessNewDeviceNode
kd> bu nt!PiCreateDeviceInstanceKey
kd> g
bu的好处是延迟断点，系统还没加载ntoskrnl时就可以先设置，模块加载后会自动绑定。触发设备枚举的方式有很多：插拔USB设备、在设备管理器里“扫描检测硬件改动”、或者直接重启系统看启动阶段枚举。如果是PCIe设备，通常重启或者设备管理器扫描就能触发。
断点命中以后，第一件事是看调用栈：
code复制kd> k
如果命中的是 nt!PiCreateDeviceInstanceKey，调用栈里几乎必然能看到 nt!PiProcessNewDeviceNode，这就验证了标题里的调用关系。
4.2 从入参看设备节点实例路径
在x64系统上，第一个参数大概率放在RCX寄存器。对于 PiCreateDeviceInstanceKey 来说，第一个参数就是当前正在处理的 _DEVICE_NODE *。WinDbg里直接看这个结构体：
code复制kd> dp rcx L8
kd> dt nt!_DEVICE_NODE @rcx InstancePath DeviceID State
示例输出：
code复制kd> dt nt!_DEVICE_NODE @rcx InstancePath DeviceID State
+0x030 DeviceID : 0xffffe0015b47fff0 "PCI\VEN_8086&DEV_1234"
+0x038 InstancePath : 0xffffe0015b47ffe0 "PCI\VEN_8086&DEV_1234&SUBSYS_00008086&REV_00\5&2b3a1c44&0&18"
+0x State : 0x1 (DeviceNodeStateInitializing)
看到InstancePath，就知道当前代码在给哪个设备实例上户口了。这个路径和注册表里的HKLM\SYSTEM\CurrentControlSet\Enum后面跟的路径是一致的。一旦这里能对上，再回到设备管理器里对照硬件ID，基本不会认错设备。
为了不打断系统运行太多，也可以把断点改成日志断点，只输出不上停下：
code复制kd> bu nt!PiCreateDeviceInstanceKey ".echo PI_CREATE_DEVICE_INSTANCE_KEY; dt nt!_DEVICE_NODE @rcx InstancePath DeviceID; kL3; g"
这样系统每次进入这个函数都会打一行设备路径和三层调用栈，适合抓那种偶发性设备丢失问题。我经常在测试机器上开一串日志断点跑一个晚上，第二天看调试输出文件就能还原整个枚举过程。
4.3 现场还原：一次典型的调用栈
下面是一次USB设备拔出再插入时，在 nt!PiCreateDeviceInstanceKey 命中后看到的调用栈示例（不同系统版本偏移量会不同，函数名顺序才是重点）：
text复制kd> k
# Child-SP RetAddr Call Site
00 ffffd001`abca36b0 fffff802`4e1a0a15 nt!PiCreateDeviceInstanceKey+0x166
01 ffffd001`abca3730 fffff802`4e1c8b0c nt!PiProcessNewDeviceNode+0xa15
02 ffffd001`abca37a0 fffff802`4e1d6a22 nt!PnpSynchronousCall+0x2e
03 ffffd001`abca3810 fffff802`4e1d8d44 nt!IopInitializeDeviceNode+0xb0c
04 ffffd001`abca38b0 fffff802`4e1e07f2 nt!IopProcessNewDeviceNode+0x...
这个栈验证了一个重要事实：PiCreateDeviceInstanceKey 并不是从系统任意注册表写入路径都能进入的，它几乎总是从 PiProcessNewDeviceNode 进来。这也意味着，如果你看到设备实例键出现了不明键值，很大概率就是设备枚举时被这两个函数之一的逻辑写入的，而不太可能是第三方应用程序绕路写入。
4.4 条件断点：只看某个设备
真实环境中系统会很频繁地枚举几十个设备，每个都停下来看会疯掉。这时可以写条件断点，只匹配目标设备路径。WinDbg的脚本写法比较直接，可以先用字符串比较函数判断InstancePath是否含目标子串：
text复制kd> bu nt!PiCreateDeviceInstanceKey ".if ($spat(\"PCI\\VEN_8086\", @rcx->InstancePath)) { .echo TARGET_DEVICE; dt nt!_DEVICE_NODE @rcx InstancePath; kL5 } .else { gc }"
这段脚本的思路是：命中 PiCreateDeviceInstanceKey 时，检查RCX指向的DEVNODE的InstancePath是否以目标硬件ID开头，如果匹配则打印详情和栈，否则直接继续执行。
这种做法的价值在于，你可以在系统毫无感知的情况下获取到目标设备创建实例键时的完整上下文。实际干活时我最常用这个方式来确认“这个设备到底有没有走到实例键创建那一步”，效率比在ProcMon里一条一条翻注册表操作高得多。
4.5 ProcMon配合：一个看行为，一个看原因
很多开发者在遇到设备安装问题时第一反应是打开ProcMon，过滤RegCreateKey、RegSetValue，观察哪一步注册表操作失败。这个习惯非常好，但ProcMon的局限在于它只看得到作用的键路径和返回结果，看不到是谁在调用、调用方处于什么设备状态机里。
我的习惯是两者配合：ProcMon确定方向（比如看到Enum下某段路径权限错误），WinDbg定位根因（比如看到是PiCreateDeviceInstanceKey写入时父键打开失败）。ProcMon就像监控摄像头告诉你“这台车里的人被拒之门外”，WinDbg则直接告诉你“这个人在哪个部门上班、拿着什么文件来办事”。配合使用基本可以覆盖绝大多数设备注册表问题的排查。
5. 跟设备实例键有关的故障，我从这些角度排查
5.1 场景A：Enum目录权限被改坏，设备大面积消失
这是一种很典型的“人为故障”，常见于安全加固脚本、组策略、以及某些“系统优化软件”。这些工具可能会出于安全考虑修改注册表键的安全描述符，结果误伤HKLM\SYSTEM\CurrentControlSet\Enum这个重要目录。
故障现象非常典型：设备管理器里大量设备变成未知设备，或者某些设备明明存在但无法启用。热插拔新设备时设备无法被正确枚举，因为 PiCreateDeviceInstanceKey 在创建实例键时发现父键没有KEY_CREATE_SUB_KEY权限，直接返回ACCESS_DENIED。
处理方式很简单：恢复Enum目录的默认权限，从同版本正常系统的注册表导出权限信息然后应用；或者直接用内置SYSTEM账户打开注册表编辑器，手动把权限改回来。改完之后重启系统，让PnP管理器重新枚举所有设备。
5.2 场景B：系统镜像部署后出现残留实例键
做系统封装、Sysprep、或者用第三方工具备份还原系统时，设备实例键经常被连带保存下来。新系统启动后，PnP管理器枚举到设备，发现注册表里已经有对应实例键，于是跳过全新创建，直接打开旧键。旧键里如果记录了错误状态、过期驱动路径或者不匹配的容器ID，设备就会表现异常。
这个时候 PiProcessNewDeviceNode 的调用栈看起来非常正常，PiCreateDeviceInstanceKey 也可能根本没有进入“创建”分支，而是直接打开已有键。排障重点就变成检查设备实例键里的状态字段和驱动路径是否合理。最有效的办法是在设备管理器里把目标设备卸载并勾选“删除此设备的驱动程序软件”，然后重新扫描检测。这样会清理掉设备实例键和关联驱动键，强制PnP走一遍全新创建流程。
5.3 场景C：总线驱动返回了非法硬件ID
有些第三方总线驱动在枚举子设备时，上报的硬件ID格式不合法，比如包含不可见字符、字段长度异常、或者兼容ID数组结构与PnP预期不一致。这种情况下 PiCreateDeviceInstanceKey 依然会执行，但写进设备实例键的HardwareID可能为空，或者被截断。后续查找驱动时，INF里的硬件ID永远匹配不上。
排障时在断点里看 InstancePath 和 DeviceID 往往就能发现问题。如果实例路径里有明显不该出现的字符，基本可以肯定是上游总线驱动上报了脏数据。这种情况修INF没用，要去找总线驱动厂商确认设备描述符的解析逻辑。
5.4 场景D：ContainerID错配导致设备被错误分组
Windows 8以后的系统使用设备容器（Device Container）来把蓝牙、USB、HID等物理设备归组。设备实例键里的ContainerID是PnP管理器在创建设备实例键时从ACPI固件表或设备描述符里提取的。如果固件对该字段支持不完整，多个不同物理设备可能被分到同一个容器里。
故障现象可能是蓝牙鼠标和内置蓝牙适配器被“绑定”在一起，拔掉USB接收器连蓝牙设备也一起消失。排查时需要重点看设备实例键的ContainerID，对比正常设备的值。如果异常，优先更新主板固件，或者检查总线驱动对_DSM方法的实现。
5.5 问题排查总表
| 现象 | 关键断点观察点 | 常见返回值 | 处理方向 |
|---|---|---|---|
| 设备管理器未知设备 | 断点能命中，但返回ACCESS_DENIED | 0xC0000022 | 恢复Enum目录权限 |
| 设备存在但驱动不匹配 | 设备实例键里HardwareID为空或异常 | STATUS_SUCCESS | 检查上游总线驱动上报数据 |
| 设备消失，ProcMon无操作 | 断点无法命中 | 无 | 检查是否被安全软件拦截枚举 |
| 设备分组错乱 | 实例键ContainerID重复 | STATUS_SUCCESS | 更新固件或检查DSM方法 |
| 重启后驱动状态丢失 | 旧键被复用，状态字段异常 | STATUS_OBJECT_NAME_COLLISION | 卸载设备并清理旧键 |
这张表不是教科书，是我自己踩坑之后整理出来的“第一反应对照表”。它不能替代完整排查，但能帮你快速判断该往哪个方向继续深挖。
6. 长期调试内核PnP流程之后沉淀的几条经验
内核态PnP函数的调试和平常写业务代码完全是两回事。最大的障碍是信息量太大，设备枚举时系统里同时可能有几十个设备节点在跑状态机。如果没做好过滤，WinDbg里刷出来的信息多到你根本不知道该看哪条。
我的经验是：无论问题多复杂，永远先把“设备实例键到底有没有被正确创建”作为第一检查点，再往上游或下游发散。因为设备实例键是设备枚举和驱动加载之间的分水岭：创建成功，问题大概率在驱动匹配；创建失败，问题大概率在PnP管理器、注册表或总线驱动。把这条线切开，整个问题域一下就小了一半。
另外，调试时不要迷信网上流传的固定字段偏移量。不同Windows版本的_DEVICE_NODE布局会有变化，用WinDbg的dt nt!_DEVICE_NODE直接看本地符号才是最稳的。条件断点里的字符串判断脚本，在不同系统上也建议先手动跑一次确认路径格式，再挂上自动执行。
回到开头那台Windows Server 2022。最后定位到的问题就是安全加固脚本把Enum目录下某个子键的权限收紧，PiCreateDeviceInstanceKey写入时父键打开失败。把权限恢复到默认值之后，设备重新枚举一次就正常了。整个过程如果只看用户态日志，大概率会绕很多弯路。而一旦掌握了PiProcessNewDeviceNode到PiCreateDeviceInstanceKey这条调用链，再遇到类似问题，基本就是按图索骥的事了。