Certain Vista windows do not allow keys to be "listened" to

Oct 19, 2011 at 11:36 PM

Hello, I have been using this project for awhile now, from the original version at http://www.codeproject.com/KB/cs/globalhook.aspx to the current version 5674 and it works great except with certain Vista windows.  I have a simple Windows form project which needs to respond to global keys and mouse activity but when these types of Vista windows are foregrounded, the keys and mouse activities cannot be detected by my code with the key and mouse events.

I am using Vista Version 6.0 (Build 6002: Service Pack 2).  An example of the "type" of window which appears to block key messages is the "Services" window, "services.msc", but there are others as well.

To easily see the problem, launch the "MouseKeyboardActivityMonitor.Demo.exe" project, either x64 or x86, and set the Services window to the foreground.  Select the "Global hooks" option in the Demo and any or all of the mouse or key checkboxes.  With the Services window foregrounded, there will be no activity shown in the text box at the bottom of the Demo form.

Is this issue related to User Interface Privilege Isolation in Vista?  Is there anything I can do to configure my project or the globalhook project to make keys and mouse actions respond with these types of windows?

Should I log this as a defect?

Thanks for any insight you can provide.


Oct 20, 2011 at 5:33 PM
Edited Oct 20, 2011 at 5:33 PM

Hey thanks for using the library. I too had been using the old version some years ago (2005 maybe?) for various projects and its because of that reason I joined the project.

Unfortunately, in regards to your issue, I am not able to fully test it because I don't have access to a machine running Vista. What I can tell you is that the problem does not occur in Windows 7.

As you surmised, it may very well be an issue with the Privilege Isolation in Vista. I don't know of any way to circumvent it in your scenario, except the usual "run as an admin.. blah blah", and I assume you've tried that anyway. Sorry I can't be of more help. 

Go ahead and file a ticket. If you figure out how to get global hooks to work with services.msc and other similar applications, please let us know.

Oct 21, 2011 at 12:30 AM

Actually, I had not tried running it as administrator.  It turns out that indeed, if I run the "MouseKeyboardActivityMonitor.Demo.exe" project as admin, the keys and mouse activity is correctly interpreted.

So that's good, except that with my specific project, I would really prefer to not have to run it as admin.

I now believe that the problem has to do with the fact that services.msc, and other similar applications, have to be run as admin.  I tried other windows launched from "Control Panel\Administrative Tools" and they all had this same "problem".  If I run my project as admin, the keys are interpreted.

Is there any way to get around this without running my project as admin?  I just don't really want to have the extra step of having the "An unidentified program wants access to your computer" dialog coming up and having the user "allow" it.  My project runs fine for any other windows.  The ideal solution would be to programmatically detect whether the "run as admin" window is the foreground window and then conditionally run code with admin rights so that the keys are detected.  Is there any way the code in the MKAM project can be adjusted to get around this issue?  Is there a way to programmatically (C# .net 3.5) determine if a window has been run as admin and maybe warn the user that my program would have to be restarted as admin?  Not an ideal solution, but if the MKAM project cannot be adapted to handle this situation, maybe that would be okay.

What has changed between Windows 7 and Vista that makes MKAM work with "run as admin" windows properly?


Oct 21, 2011 at 2:12 PM
Edited Oct 21, 2011 at 2:12 PM

I'm glad to know that running as administrator does monitor other applications with admin privileges.

Last night, I remembered that UAC is completely disabled, so infact the application may have been assumed elevated privileges without me knowing. Will test upon next restart and reply.

You've got a lot of good questions, and the answers are beyond my knowledge. For the best solution, I recommend asking on stackoverflow.

You asked about programmatically detecting if the focused window is running as administrator and the only way that I can think of is to use Windows API, something along the lines of:

OpenProcessToken() // use handle from GetForegroundWindow... not sure if it'll work.

I hope that points you in the right direction.