这是个挺典型的Windows设备管理场景——明明设备标记了可禁用，API调用返回错误，但重启后却能生效。我来拆解下你可能遇到的问题点：

1. 关键输入设备的系统保护机制 #

USB键盘属于Windows认定的核心输入设备，系统有专门的保护逻辑防止你在当前会话中直接禁用正在使用的输入设备（毕竟如果即时禁用，你就没法通过键盘操作系统了）。

• 当你调用SetupDiCallClassInstaller执行禁用操作时，系统会检测到这是当前活跃的输入设备，因此返回ERROR_NOT_DISABLEABLE阻止即时生效，但它依然会把禁用标记写入设备的注册表项中。
• 重启系统后，设备加载时会读取这个注册表标记，所以会执行禁用操作。

你可以做个小测试：如果这个USB键盘不是当前正在使用的输入设备（比如你外接了另一个鼠标/键盘，或者通过远程桌面操作），再调用相同的API，应该就能即时成功，不会返回错误。

2. SetupDi系列API的参数配置细节 #

确认你在设置参数时有没有遗漏关键配置：

• 确保SP_CLASSINSTALL_HEADER的InstallFunction字段设置为DIF_PROPERTYCHANGE。
• 对应的SP_PROPCHANGE_PARAMS结构体中：
  • StateChange设为DICS_DISABLE
  • Scope如果设为DICS_FLAG_GLOBAL，会标记全局禁用（重启生效）；如果设为DICS_FLAG_CONFIGSPECIFIC，是针对当前硬件配置的禁用，但对于关键输入设备，即时操作依然会被系统拦截。
• 打开设备信息集时，要确保使用了正确的标志（比如DIGCF_PRESENT | DIGCF_ALLCLASSES），并且SetupDiOpenDeviceInfo获取了足够的权限（比如GENERIC_WRITE）。

3. DN_DISABLEABLE标志的局限性 #

你通过CM_Get_DevNode_Status获取到的DN_DISABLEABLE标志，仅表示该设备支持禁用操作，但不代表可以在当前会话中即时执行禁用。这个标志不会绕过Windows对核心输入设备的即时操作限制。

解决建议 #

• 如果需要即时禁用：先确保目标键盘不是当前活跃的输入设备（比如切换到其他输入方式），再执行API调用。
• 如果不需要即时生效：当前的行为其实是符合系统逻辑的，你可以接受重启生效的结果，或者尝试使用CM_Disable_DevNode函数，它的行为与SetupDi系列API略有不同，但同样要注意核心设备的限制。
• 另外，检查代码中是否正确释放了设备信息集（调用SetupDiDestroyDeviceInfoList），避免资源泄漏，但这和当前的错误无关。

内容的提问来源于stack exchange，提问作者Vitaliy Lutsushyn