Search code examples
c#wpfuac

Keyboard.IsKeyDown false over UAC process with uiAccess=true?

I have a program which tries to install itself on the target machine with uiAccess=true in the manifest.

Here is the documentation on that: https://msdn.microsoft.com/en-us/library/windows/desktop/ee671610(v=vs.85).aspx

According to the documentation, this should grant the application permission to do more things while a UAC elevated application is in focus.

However, as soon as an administrative application is in focus, Keyboard.IsKeyDown returns false for any key that is in fact down.

This leads me to believe that the uiAccess thing is not actually working.

Here's what I made sure is happening:

  • My program is signed with a code signing certificate as per the documentation, from Comodo. It is not an EV certificate.
  • The program is launched from a UAC protected path (C:\Program Files\Shapeshifter).

How can I debug uiAccess and figure out why it is not working?

Solution

  • How can I debug uiAccess

    The only real thing debuggable about it is to verify that the OS detected that you asked for it. Very easy to do and something you probably already did: don't sign the executable. With the expectation that you now can no longer start the EXE. If it does start then you know for a fact that UIPI was not disabled.

    Keyboard.IsKeyDown returns false

    That is the expected behavior and something that disabling UIPI does not fix. This WPF property uses GetKeyState() under the hood. Quite a notorious function at SO with many victims and very few usable answers. Keyboard state and input handling is per-process (technically per input queue), only the process that has a window in the foreground can expect to see keypresses. Fixing that requires using the winapi function that Raymond Chen loves to hate on, AttachThreadInput(). With the expectation that with UIPI disabled it no longer fails with error 5 (aka access denied).

    Very hard to use correctly, beyond Raymond's concerns, since you need to track which window is in the foreground. I can't tell why you need it, but surely you'd favor SetWindowsHookEx() or RegisterHotKey(), perhaps UI Automation as supported by the System.Windows.Automation namespace.