SetWindowHookEx API with WH_JOURNALRECORD. This API fails with access denied (Error 5).

A while ago I came across a problem in which  SetWindowHookEx API with WH_JOURNALRECORD was failing with Access denied on Windows Vista.

If you have the same problem you can do what I tried.

1)      Create and Embed an Application Manifest with Your Application.

o   In our case we would need manifest with <requestedExecutionLevel level="requireAdministrator" uiAccess="true" />

2)      Authenticode Sign Your Application  You can follow following steps to create a certificate and sign your application. You will need a commercial certificate if you wish your application to be trusted on the target computer of a customer installing your application. The following procedures are provided as examples and are not intended to be strictly followed. For example, replace the test certificate's name with your certificate's name and ensure that you tailor the procedures to map to your specific CA and development environment.

                                             i.            Open Visual Studio Command prompt. Navigate to the folder which has the executable. For example: I am using the sample application you have sent. You should keep that sample application in trusted folder (Program Files).

                                           ii.            Generate the certificate makecert -r -pe -ss PrivateCertStore -n "" MyCertificate.cer

                                          iii.            Sign the code. Applying a timestamp while signing your application will ensure that the application will continue to run after the validity period of the original certificate. Signtool sign /v /s PrivateCertStore /n /t MyApplication.exe

                                         iv.            Install the Certificate. To install the test certificate

A.      Launch an elevated command window by right-clicking Command Prompt and selecting Run as administrator.

B.      In Command Prompt, type mmc.exe and press Enter.

C.      In the mmc, select File and then select Add/Remove Snap-in…

D.      In Add or Remove Snap-ins, select Certificates, click Add, and then click OK.

E.       In the Certificates snap-in dialog box, select Computer account and click Next.

F.       In Select Computer, select Local Computer, and then click OK.

G.     In Add or Remove Snap-ins, click OK.

H.      In the Certificates snap-in, and navigate to Trusted Root Certificate Authorities, right-click Certificates, select All Tasks, and then select Import…

I.        In the Certificate Import Wizard, import the test certificate, ContosoTest.cer.


3)      Run your application from trusted folders.


You might want to check the following document

Windows Vista Application Development Requirements for User Account Control Compatibility

You would need to follow following steps elaborated in this white paper.

Step Six: Create and Embed an Application Manifest with Your Application (Page 63)

Step Eight: Authenticode Sign Your Application (Page 72)


By specifying UIAccess=”true” in the requestedPrivileges attribute, the application is stating a requirement to bypass UIPI restrictions on sending window messages across privilege levels. Windows Vista implements the following policy checks before starting an application with UIAccess privilege.

The application must have a digital signature that can be verified using a digital certificate that chains up to a trusted root in the local machine Trusted Root Certification Authorities certificate store.

The application must be installed in a local folder application directory that is writeable only by administrators, such as the Program Files directory. The allowed directories for UI automation applications are:

%ProgramFiles% and its subdirectories.

%WinDir% and its subdirectories, except a few subdirectories that are excluded because standard users have write access.

The %WinDir% subdirectories that are excluded subdirectories include:











User Account Control: Only elevate UIAccess applications that are installed in secure locations

This setting is enabled by default. However, an administrator can disable it if there are situations where UIAccess applications (Accessible Technology) that must be launched from folders are not protected by administrator-only write access.

If the UI automation application that requests UIAccess meets the UIAccess setting requirements, then Windows Vista launches the application with the ability to bypass most of the UIPI restrictions. If the UI automation application does not meet the security restrictions, the application will be launched without UIAccess rights and can interact only with applications at the same or lower privilege level.

A process that is launched with UIAccess rights:

Has the ability to set the foreground window.

Can drive any application window using SendInput function.

Has read input for all integrity levels using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput.

Can set journal hooks.

Uses AttachThreadInput to attach a thread to a higher integrity input queue

Possible uiAccess values




The application does not need to drive input to the user interface of another window on the desktop. Applications that are not providing accessibility should set this flag to false. Applications that are required to drive input to other windows on the desktop (on-screen keyboard, for example) should set this value to true. 


The application is allowed to bypass user interface control levels to drive input to higher privilege windows on the desktop. This setting should only be used for user interface Assistive Technology applications.


Comments (0)

Skip to main content