WP doesnt Count (Windows 7 / only in Visual Studio)

[realdognose]

Hello,

actually im using the beta Version of Windows 7. Whatpulse works nice,
but it still dont count my Keystrokes and Mouseclicks in VisualStudio 2008 ....
(This are about 90% of my Keystrokes / day ... :sad: )

Is there any work arround for windows 7 to get it working "everywhere"?

dognose

[realdognose]

Fixed it:

Running Visual Studio with Administrator Privilegs, makes Whatpulse
unable to count the KeyStrokes/Clicks.

Maybe this is not only fact for Visual Studio 2008 ?! :confused:

dognose

[bobL]

Windows 7 is a beta OS which we don't provide support for, but thanks for letting us know about your issues; it will be considered in the development of future versions of WhatPulse

[X-Kal]

Hmm... I'm not sure if we really "officially" have an OS Support list. If so, I've never seen the list :-P

I wish I knew more about Windows 7 and Visio to figure out what's going on in that interaction. I'm curious how many other whatpulse users have tried the Windows 7 beta - I had it installed on my netbook for about 10 minutes before I got tired of it.

[bobL]

Well, I'm not going debug a pre-RC OS and I doubt wasted will (maybe I'm wrong but I doubt it, he has enough to do), so it's pretty much on the 'list' The last public W7 beta had, as it would, quite a few problems with all sorts, so it's not a great surprise one of those programmes is WhatPulse and until the RC is out, there's no point in developing for it.

It'll remain to be seen how more finalized versions of W7 handle WP as it is, but until then...

[bobL]

I can't reproduce this at all...

[spacekuloos]

Hi,

I have the same problem as dognose but then in Vista SP1.
When i'm in Visual Studio 2008 SP1 opened with Administrator privileges, Whatpulse doesn't count keys or mouse clicks.
When i start Visual Studio normal then i have no problems.

So i don't think this is a Windows 7 problem but one from Visual Studio.

[shindouhikaru]

I think the problems mentioned is actually by design to secure Windows PCs to prevent unwanted software to gain access. Software started with one privilege level (ex. regular user) cannot interact with a software started with another privilege level (ex. administrator). This has been the case since Windows Vista.

Brief Technical
Windows User Account Control have a subfeature called User Interface Privilege Isolation. Applications can send window messages to each other without user interference. Same level and higher level privilege applications can send and receive these messages to each other freely. However, lower level privilege applications cannot send messages to higher level privilege applications. An example of this is included at the end of the post.

Detailed Technical (skip if you want):
Microsoft calls this User Interface Privilege Isolation. Excerpt from the website:

Windows Vista Application Development Requirements for UAC
link: h.t.t.p://msdn.microsoft.com/en-us/library/aa905330.aspx

Quote:[SIZE="1"]User Interface Privilege Isolation

User Interface Privilege Isolation (UIPI) is one of the mechanisms that helps isolate processes running as a full administrator from processes running as an account lower than an administrator on the same interactive desktop. UIPI is specific to the windowing and graphics subsystem, known as USER, that supports windows and user interface controls. UIPI prevents a lower privilege application from using Windows messages to send input from one process to a higher privilege process. Sending input from one process to another allows a process to inject input into another process without the user providing keyboard or mouse actions.

Windows Vista implements UIPI by defining a set of user interface privilege levels in a hierarchical fashion. The nature of the levels is such that higher privilege levels can send window messages to applications running at lower levels. However, lower levels cannot send window messages to application windows running at higher levels.

The user interface privilege level is at the process level. When a process is initialized, the User subsystem calls into the security subsystem to determine the desktop integrity level assigned in the process security access token. The desktop integrity level is set by the security subsystem when the process is created and does not change. Therefore, the user interface privilege level is also set by the User subsystem when the process is created and does not change.

All applications run by a standard user have the same user interface privilege level. UIPI does not interfere or change the behavior of window messaging between applications at the same privilege level. UIPI comes into effect for a user who is a member of the administrators group and may be running applications as a standard user (sometimes referred to as a process with a filtered access token) and also processes running with a full administrator access token on the same desktop. UIPI prevents lower privilege processes from accessing higher privilege processes by blocking the behavior listed below.

A lower privilege process cannot:

• [SIZE="1"]Perform a window handle validation of higher process privilege.[/SIZE]
• [SIZE="1"]SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.[/SIZE]
• [SIZE="1"]Use thread hooks to attach to a higher privilege process.[/SIZE]
• [SIZE="1"]Use Journal hooks to monitor a higher privilege process.[/SIZE]
• [SIZE="1"]Perform DLL injection to a higher privilege process.[/SIZE]
  

With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels:

• [SIZE="1"]Desktop window, which actually owns the screen surface.[/SIZE]
• [SIZE="1"]Desktop heap read-only shared memory.[/SIZE]
• [SIZE="1"]Global atom table.[/SIZE]
• [SIZE="1"]Clipboard[/SIZE]
  

Painting to the screen is another action that is not blocked by UIPI. Painting to the screen refers to the process of using the Paint method to display content on an external output—a monitor, for example. The USER/graphics device interface (GDI) model does not allow control over painting surfaces; therefore, it is possible for a lower privilege application to paint over the surface region of a higher privilege application window.

Note Because the Windows Shell (the Explorer.exe process) is running as a standard user process, any other process running as standard user can still send the Windows Shell keystrokes. This is the primary reason an administrator account in Admin Approval Mode is prompted for elevation consent when the user initiates an administrative action, such as double-clicking on a setup file or clicking on a button marked with an elevation shield icon.[/SIZE]

Example
An example to show this user input isolation isolation:
You logged in as a normal user, and whatpulse started up with the privilege given to your user account. These software running under the same logged on user session. Then you start a notepad session as an administrator and started typing. The keys you clicked on notepad will not be recorded because of the difference in user privileges level. However, if you run these applications with the same user privilege level or you elevate whatpulse to administrator level privilege to be able to capture all user inputs in applications with any privileges (even administrator), it will work well.

Again, this behavior is by default and has been so since Windows Vista.

[spacekuloos]

Thanks shindouhikaru, i just started whatpulse as administrator and all works fine now.
Maybe this should be in the FAQ or in the KB if it insn't already.