Keyboard.IsKeyDown false для процесса UAC с uiAccess = true?

Question

У меня есть программа, которая пытается установить себя на целевой машине с uiAccess=true в манифесте.

Вот документация на это: https://msdn.microsoft.com/en-us/library/windows/desktop/ee671610(v=vs.85).aspx

В соответствии с документацией это должно предоставить приложению разрешение на выполнение дополнительных действий, пока приложение UAC с повышенными правами находится в фокусе.

Однако, как только административное приложение находится в фокусе, Keyboard.IsKeyDown возвращает false для любого ключа, который фактически не работает.

Это приводит меня к мысли, что вещь uiAccess на самом деле не работает.

Вот что я сделал, чтобы убедиться, что происходит:

• Моя программа подписана сертификатом подписи кода согласно документации от Comodo. Это не сертификат EV.
• Программа запускается по защищенному пути UAC (C:\Program Files\Shapeshifter).

Как мне отладить uiAccess и выяснить, почему он не работает?

Answer 1

Как я могу отладить uiAccess

Единственная реальная вещь, которую можно отлаживать, - это убедиться, что ОС обнаружила, что вы ее запросили. Очень легко сделать, и то, что вы, вероятно, уже сделали: не подписывайте исполняемый файл. С ожиданием, что теперь вы больше не можете запускать EXE. Если он действительно запускается, то вы точно знаете, что UIPI не был отключен.

Keyboard.IsKeyDown возвращает false

Это ожидаемое поведение и то, что отключение UIPI не исправляет. Это свойство WPF использует GetKeyState () под капотом. Довольно печально известная функция в SO со многими жертвами и очень мало полезных ответов. Состояние клавиатуры и обработка ввода выполняются для каждого процесса (технически для очереди ввода), только процесс, имеющий окно на переднем плане, может ожидать нажатия клавиш. Исправление требует использования функции winapi, которую любит ненавидеть Раймонд Чен, AttachThreadInput (). С ожиданием, что с отключенным UIPI он больше не завершается с ошибкой 5 (иначе доступ запрещен).

Очень сложно правильно использовать, не считая проблем Раймонда, так как вам нужно отследить, какое окно находится на переднем плане. Я не могу сказать, зачем вам это нужно, но наверняка вы бы предпочли SetWindowsHookEx () или RegisterHotKey (), возможно, UI Automation, как это поддерживается пространством имен System.Windows.Automation.