none
Collecting keyboard and mouse usage statistics from a system service...how?

    Question

  • My company is developing software that collects usage statistics on various activities and among those activities is how often the keyboard / mouse are used.  We want to collect things like number of keystrokes per minute, mouse pixels moved per minute, etc.  I've been able to implement this logging mechanism as a standard user-space application, but I continually get zero data when running from a system service.

    In a normal user application, watching keyboard and mouse events can easily be done with the SetWindowsHookEx API passing WH_KEYBOARD_LL and WH_MOUSE_LL as the first parameter.  

    My bing-foo has only turned up results saying that system services run in their own Desktop but with API calls SetProcessWindowStation() and SetThreadDesktop(), I should be able to hook into applications on any desktop, especially considering that this system service (does/does not?) runs with administrator rights.   Even though SetThreadDesktop("Default") doesn't generate any errors, my system hooks never get data.  All the references to this problem out there talk about a solution that works in Windows Vista but not Windows 7.  I'm assuming security changes were made in this regard...

    In any case, does anyone know any solutions to what I want to accomplish... that is, monitor keyboard and mouse activity from a system service?  A different approach to system hooks is fine (lower level API?), but working from within a system service is fairly important.

    Thanks in advance,

    Chuck



    • Edited by Chuck Mason Friday, August 26, 2011 10:53 AM eliminate error
    Friday, August 26, 2011 10:37 AM

All replies

  • Your problem is that services run in a different desktop (this is an intentional security feature) than user space applications. 

    The general approach to take is to handle user login events in your service and spawn a normal user executable that runs in that user's session that does the stuff that actually interacts with the desktop.

    Unfortunately I only the general theory, I am not certain of the details.

    Friday, August 26, 2011 1:37 PM
  • I've heard this several times now, but I was hoping there was a better way to handle it.  

     

    Are there any other suggestions?

    Monday, August 29, 2011 7:10 AM