2

I'm now editing this item since I think I have pinpointed the issue, this seems to be an OS bug for Win8.1 and Win10. Issue summary is still same as before "Low level mouse hook doesn't fire mousedown/mouseup event on admin process"... for admin apps if a non-admin starts its own low level hook.

Steps to reproduce issue:

  1. Download demo app here
  2. Run the app as admin
  3. Make sure to monitor mouse up/down/click events
  4. Confirm that the app started on step #2 is able to monitor mouse up/down/click events on admin processes (including on its own window)
  5. Run another instance of the app as non-admin
  6. Make sure to monitor mouse up/down/click events

Result: notice that the app's instance running as admin (started on #2) is now unable to get mouse up/down/click events, but it can still get other mouse events and all keyboard events

Has anyone encountered this issue?

Code.Blodded
  • 231
  • 1
  • 19
  • 1
    I can't reproduce. I downloaded the demo project on [this url](http://globalmousekeyhook.codeplex.com/downloads/get/290733) (same author, seems the evolution of that codeproject article) and it catches mouse up and mouse down events for me running as admin (Win 10, x64) – Jcl Feb 03 '16 at 08:23
  • 2
    Oh, I misread the problem. I see what you mean now: no, that's not possible, you can't catch messages of an app running with higher privileges than yours. If you run the demo app as admin, it'll actually catch them, but not if the running app is less privileged. – Jcl Feb 03 '16 at 08:33
  • yes my app is also running as admin, if my app is not running as admin then I cannot get all mouse/keyboard events, but if my app is running as admin then it cannot get mousedown/mouseup events only. I can also confirm this issue on the demo app on the URL you provided – Code.Blodded Feb 03 '16 at 08:34
  • It works for me, unless I'm understanding the problem wrong: I've ran the demo project as admin and then clicked on the task manager: http://i64.tinypic.com/oispbb.png – Jcl Feb 03 '16 at 08:40
  • I also tested it with other processes running as admin (not just task manager), and it works well too, it does detect mouseup and mousedown. – Jcl Feb 03 '16 at 08:43
  • Thank you for this info, I don't think there is much to not understand here so this may be difference in Windows update perhaps I don't know yet, I have tried this on my Win8.1 desktop and Win10 laptop and both fails so not sure what could be the difference – Code.Blodded Feb 03 '16 at 08:45
  • Is your hook app running in the WoW64 emulation layer, i.e. is it a 32-bit process running on 64-bit Windows? – IInspectable Feb 03 '16 at 19:05
  • yes it is a 32bit process running on a 64bit machine, but as I have found out today, this seems to be some issue with some software conflict perhaps or some Windows settings, not completely sure yet. Basically I have "reset" my Win10 installation, so all programs uninstalled and issue is gone now. But still need to find out what caused this perhaps what program can cause such weird behavior – Code.Blodded Feb 04 '16 at 09:52
  • 1
    Any application that installs a mouse hook can prevent other hooks from receiving messages, if it doesn't call [CallNextHookEx](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644974.aspx). – IInspectable Feb 04 '16 at 16:06
  • @Jcl I have edited the main description to reflect my new findings – Code.Blodded Feb 09 '16 at 15:35
  • I could definitely reproduce your behaviour in Win10. If you say that works in Win7 and it's not documented anywhere, then yes, it looks like a reproducible bug. That said, I have not read the documentation on Global Hooks so it might be documented somewhere. – Jcl Feb 09 '16 at 15:56
  • I have reaffirmed that issue does not happen on Win7 using the exact steps mentioned in main description – Code.Blodded Feb 09 '16 at 15:59

1 Answers1

4

OP:

...and it confirmed that mouseup/mousedown events are not getting triggered when foreground window is running as admin.

OP:

if my app is not running as admin then I cannot get all mouse/keyboard events,

Starting with Vista, it was not possible for an app to post messages to or install hooks on an elevated app. This is accomplished via User Interface Privilege Isolation (UIPI) and integrity (see below).

MSDN:

UIPI does not interfere with or change the behavior of window messaging between applications at the same privilege (or integrity) level. UIPI prevents lower-privilege processes from accessing higher-privilege processes by blocking the following behavior. A lower-privilege process cannot:

  • Perform a window handle validation of a process running with higher rights.
  • Use SendMessage or PostMessage to application windows running with higher rights. These APIs return success but silently drop the window message.
  • Use thread hooks to attach to a process running with higher rights.
  • Use journal hooks to monitor a process running with higher rights.
  • Perform dynamic link library (DLL) injection to a process running with higher rights. Tell me more...

I remember just before Vista came out there was a lovely Word document tome all about preparing your app for Windows Vista but sadly I cannot locate it.

but if my app is running as admin then it cannot get mousedown/mouseup events

Perhaps there is a problem with your mouse hook? Impossible to tell without seeing your code.

Is this a known issue for Windows

From my understanding, not for Windows Vista+.

Tell me more

Community
  • 1
  • 1
  • thank you for this info but my app is also running as admin, if my app is not running as admin then I cannot get all mouse/keyboard events, but if my app is running as admin then it cannot get mousedown/mouseup events only – Code.Blodded Feb 03 '16 at 08:32
  • That's by design. Your non-admin app cannot monitor an elevated app as the MSDN doco says –  Feb 03 '16 at 08:38
  • yes I do get that part, if my app is not running as admin then I cannot get *all* mouse/keyboard events, but why is it that if my app *is* running as admin then *still* I cannot get mousedown/mouseup events (but I can get the other mouse events such as mousemove, scroll) – Code.Blodded Feb 03 '16 at 08:41
  • @Code.Blodded Perhaps there is an issue with your mouse hook? –  Feb 03 '16 at 08:44
  • I'll check more but if so then I guess it should have never been working for Windows 7 too, but it only fails on Windows 8.1 and 10. Thanks for all your inputs – Code.Blodded Feb 03 '16 at 08:47
  • @Code.Blodded Hmm...maybe UAC was disabled on Windows 7? –  Feb 03 '16 at 08:55
  • I have confirmed that UAC is not disabled on my Win7 machine and that issue still happens on my Win10 machine even if UAC is completely disabled – Code.Blodded Feb 03 '16 at 08:59
  • 1
    @Code.Blodded Well it was worth a try. I did note _"Although the integrity mechanism supports UAC, the integrity mechanism remains in effect when UAC is disabled"_ so disabling UAC is no quick win for you sadly :( –  Feb 03 '16 at 09:00
  • @MikeyD, I have edited the main description to reflect my new findings – Code.Blodded Feb 09 '16 at 15:36