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.
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
[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]
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][/quote]
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.