Keyboard.IsKeyDown 在 uiAccess=true 的 UAC 进程中是否为 false？答案

【问题标题】：Keyboard.IsKeyDown false over UAC process with uiAccess=true?Keyboard.IsKeyDown 在 uiAccess=true 的 UAC 进程中是否为 false？
【发布时间】：2018-05-09 04:27:55
【问题描述】：

我有一个程序尝试在清单中使用uiAccess=true 将自己安装在目标机器上。

根据文档，这应该授予应用程序权限，以便在 UAC 提升的应用程序处于焦点时执行更多操作。

但是，只要管理应用程序成为焦点，Keyboard.IsKeyDown 就会为实际上已关闭的任何键返回 false。

这让我相信 uiAccess 的东西实际上并没有工作。

这是我确定正在发生的事情：

根据文档，我的程序使用来自 Comodo 的代码签名证书进行签名。它不是 EV 证书。
程序从受 UAC 保护的路径 (C:\Program Files\Shapeshifter) 启动。

如何调试 uiAccess 并找出它为什么不起作用？

【问题讨论】：

标签： c# wpf uac

【解决方案1】：

如何调试 uiAccess

唯一可调试的东西是验证操作系统是否检测到您要求它。很容易做到，而且您可能已经做过：不要签署可执行文件。期望您现在无法再启动 EXE。如果它确实启动了，那么您就知道 UIPI 没有被禁用。

Keyboard.IsKeyDown 返回 false

这是预期的行为，禁用 UIPI 无法解决问题。此 WPF 属性在后台使用 GetKeyState()。在 SO 中相当臭名昭著的功能有很多受害者，但可用的答案很少。键盘状态和输入处理是每个进程的（技术上是每个输入队列），只有在前台有窗口的进程才能看到按键。修复这个问题需要使用 Raymond Chen 讨厌的 winapi 函数，AttachThreadInput()。期望在禁用 UIPI 后，它不会再因错误 5（即访问被拒绝）而失败。

除了 Raymond 的担心之外，很难正确使用，因为您需要跟踪哪个窗口在前台。我不知道你为什么需要它，但你肯定更喜欢 SetWindowsHookEx() 或 RegisterHotKey()，也许是 System.Windows.Automation 命名空间支持的 UI 自动化。

【讨论】：

但是在以下资源中它说 GetKeyState 允许用于 uiaccess 应用程序：docs.microsoft.com/en-us/windows/security/threat-protection/…
当然，在调用 AttachThreadInput 之后。也提到了。你试过了吗？然后你有代码可以复制/粘贴到你的问题中，其他人可以尝试重现问题。
我尝试将UAC提升进程的主窗口的UI线程附加到我的线程，但我仍然无法检测到键盘状态。我需要先将自己的窗口推到前台吗？