Upgrade your Internet Experience
Microsoft.com
Welcome Sign in
Windows Developer Center
Click to Rate and Give Feedback
MSDN
MSDN Library
User Interface
Windowing
Hooks
Hook Reference
Functions
 SetWindowsHookEx Function
SetWindowsHookEx Function

The SetWindowsHookEx function installs an application-defined hook procedure into a hook chain. You would install a hook procedure to monitor the system for certain types of events. These events are associated either with a specific thread or with all threads in the same desktop as the calling thread.

Syntax

HHOOK SetWindowsHookEx(      
    int idHook,
    HOOKPROC lpfn,
    HINSTANCE hMod,
    DWORD dwThreadId
);

Parameters

idHook
[in] Specifies the type of hook procedure to be installed. This parameter can be one of the following values.
WH_CALLWNDPROC
Installs a hook procedure that monitors messages before the system sends them to the destination window procedure. For more information, see the CallWndProc hook procedure.
WH_CALLWNDPROCRET
Installs a hook procedure that monitors messages after they have been processed by the destination window procedure. For more information, see the CallWndRetProc hook procedure.
WH_CBT
Installs a hook procedure that receives notifications useful to a computer-based training (CBT) application. For more information, see the CBTProc hook procedure.
WH_DEBUG
Installs a hook procedure useful for debugging other hook procedures. For more information, see the DebugProc hook procedure.
WH_FOREGROUNDIDLE
Installs a hook procedure that will be called when the application's foreground thread is about to become idle. This hook is useful for performing low priority tasks during idle time. For more information, see the ForegroundIdleProc hook procedure.
WH_GETMESSAGE
Installs a hook procedure that monitors messages posted to a message queue. For more information, see the GetMsgProc hook procedure.
WH_JOURNALPLAYBACK
Installs a hook procedure that posts messages previously recorded by a WH_JOURNALRECORD hook procedure. For more information, see the JournalPlaybackProc hook procedure.
WH_JOURNALRECORD
Installs a hook procedure that records input messages posted to the system message queue. This hook is useful for recording macros. For more information, see the JournalRecordProc hook procedure.
WH_KEYBOARD
Installs a hook procedure that monitors keystroke messages. For more information, see the KeyboardProc hook procedure.
WH_KEYBOARD_LL
Windows NT/2000/XP: Installs a hook procedure that monitors low-level keyboard input events. For more information, see the LowLevelKeyboardProc hook procedure.
WH_MOUSE
Installs a hook procedure that monitors mouse messages. For more information, see the MouseProc hook procedure.
WH_MOUSE_LL
Windows NT/2000/XP: Installs a hook procedure that monitors low-level mouse input events. For more information, see the LowLevelMouseProc hook procedure.
WH_MSGFILTER
Installs a hook procedure that monitors messages generated as a result of an input event in a dialog box, message box, menu, or scroll bar. For more information, see the MessageProc hook procedure.
WH_SHELL
Installs a hook procedure that receives notifications useful to shell applications. For more information, see the ShellProc hook procedure.
WH_SYSMSGFILTER
Installs a hook procedure that monitors messages generated as a result of an input event in a dialog box, message box, menu, or scroll bar. The hook procedure monitors these messages for all applications in the same desktop as the calling thread. For more information, see the SysMsgProc hook procedure.
lpfn
[in] Pointer to the hook procedure. If the dwThreadId parameter is zero or specifies the identifier of a thread created by a different process, the lpfn parameter must point to a hook procedure in a DLL. Otherwise, lpfn can point to a hook procedure in the code associated with the current process.
hMod
[in] Handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.
dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

Return Value

If the function succeeds, the return value is the handle to the hook procedure.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

Remarks

SetWindowsHookEx can be used to inject a DLL into another process. A 32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL cannot be injected into a 32-bit process. If an application requires the use of hooks in other processes, it is required that a 32-bit application call SetWindowsHookEx to inject a 32-bit DLL into 32-bit processes, and a 64-bit application call SetWindowsHookEx to inject a 64-bit DLL into 64-bit processes. The 32-bit and 64-bit DLLs must have different names.

An error may occur if the hMod parameter is NULL and the dwThreadId parameter is zero or specifies the identifier of a thread created by another process.

Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications.

Before terminating, an application must call the UnhookWindowsHookEx function to free system resources associated with the hook.

The scope of a hook depends on the hook type. Some hooks can be set only with global scope; others can also be set for only a specific thread, as shown in the following table.

HookScope
WH_CALLWNDPROCThread or global
WH_CALLWNDPROCRETThread or global
WH_CBTThread or global
WH_DEBUGThread or global
WH_FOREGROUNDIDLEThread or global
WH_GETMESSAGEThread or global
WH_JOURNALPLAYBACKGlobal only
WH_JOURNALRECORDGlobal only
WH_KEYBOARDThread or global
WH_KEYBOARD_LLGlobal only
WH_MOUSEThread or global
WH_MOUSE_LLGlobal only
WH_MSGFILTERThread or global
WH_SHELLThread or global
WH_SYSMSGFILTERGlobal only

For a specified hook type, thread hooks are called first, then global hooks.

The global hooks are a shared resource, and installing one affects all applications in the same desktop as the calling thread. All global hook functions must be in libraries. Global hooks should be restricted to special-purpose applications or to use as a development aid during application debugging. Libraries that no longer need a hook should remove its hook procedure.

Windows 95/98/Me: SetWindowsHookEx is supported by the Microsoft Layer for Unicode (MSLU). However, it does not make conversions. To see Unicode messages, notifications, and so forth, you must subclass the window. To use this version of the API, you must add certain files to your application, as outlined in Installing and Releasing Hook Procedures.

Example

For an example, see Installing and Releasing Hook Procedures.

Function Information

Minimum DLL Versionuser32.dll
HeaderDeclared in Winuser.h, include Windows.h
Import libraryUser32.lib
Minimum operating systems Windows 95, Windows NT 3.1, Windows 7
UnicodeImplemented as ANSI and Unicode versions.

See Also

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Hook not called anymore when installed thread exits      www.debugbar.com   |   Edit   |   Show History
Hi,

It is not specified in any doc, and I found this problem on several codes : For a local hook, if you install the hook from a thread to another thread in the process, the hook will stop to be called when the thread which installed the hook exits (even if the thread on which you installed the hook is still running).
Tags What's this?: hook (x) thread (x) Add a tag
Flag as ContentBug
Re: Hook not called anymore when installed thread exits      greybeard2008   |   Edit   |   Show History
I quote from Richter 'Advanced Windows: Third Edition' (1997), page 88: [What Happens When a Thread Terminates] "1. All User object handles owned by the thread are freed. In Win32, most objects are owned by the process containing the thread that creates the objects. However, two User objects can be owned by a thread: windows and hooks. When the threads that create these objects die, the system automatically destroys the objects." The chapter on threads and indeed, the entire book, are well worth reading. The current edition is "Programming Applications for Microsoft Windows: Fourth Edition", but if you don't have the $60 and don't need the up-to-datest on Vista, "Advanced Windows" can be had $5 from Amazon's partners.
Tags What's this?: Add a tag
Flag as ContentBug
idHook Value      HackerJLY ... Thomas Lee   |   Edit   |   Show History
#define WH_KEYBOARD_LL 13
#define WH_MOUSE_LL 14
Tags What's this?: hook (x) Add a tag
Flag as ContentBug
Not All Global Hook Procedure Must Be In A Separate Dll Module      HackerJLY   |   Edit   |   Show History
A global hook procedure can be called in the context of any application in the same desktop as the calling thread, so the procedure must be in a separate DLL module.
------------------------------------------
The above idea is wrong.
For exsample : The Low-Level Hook:
WH_KEYBOARD_LL
WH_MOUSE_LL

There's Procedure may be called in Application's code.
------------------------------------------
Myself's idea.
Tags What's this?: hook (x) Add a tag
Flag as ContentBug
If you want to use then Low-Level Hook in VC6,You must define the _WIN32_WINNT or WinVer in StdAfx.h      HackerJLY   |   Edit   |   Show History
If you want to use then Low-Level Hook in VC6,You must define the _WIN32_WINNT or WinVer in StdAfx.h.Otherwise it will report error.

For Example:
#define _WIN32_WINNT 0x0400
Tags What's this?: hook (x) Add a tag
Flag as ContentBug
Visual Basic 9 declaration      Đonny   |   Edit   |   Show History 
Public Declare Auto Function SetWindowsHookEx Lib "user32.dll" (ByVal idHook As WindowsHook, ByVal lpfn As HookProc, ByVal hMod As IntPtr, ByVal dwThreadId As UInteger) As IntPtr

For signature of HookProc delegate see for example LowLevelMouseProc or LowLevelKeyboardProc.

For KEYBOARD_LL and MOUSE_LL on Vista32 I have success with caling this method with hMod = 0 and dwThreadId = 0 for lpfn defined in managed DLL, but it seems that it is better to call it with hMod = GetModuleHandle(GetType(TypeInWhichLpfnIsDefined).Module.FullyQualifiedName), because some hooks need this to be nonzero (i.e. KEYBOARD).

Public Enum WindowsHook As Integer
    CALLWNDPROC = 4
    CALLWNDPROCRET = 12
    CBT = 5
    DEBUG = 9
    FOREGROUNDIDLE = 11
    GETMESSAGE = 3
    JOURNALPLAYBACK = 1
    JOURNALRECORD = 0
    KEYBOARD = 2
    KEYBOARD_LL = 13
    MOUSE = 7
    MOUSE_LL = 14
    MSGFILTER = -1
    SHELL = 10
    SYSMSGFILTER = 6
End Enum

Note: As described in http://support.microsoft.com/default.aspx?scid=kb;en-us;318804, .NET basically does not support global hooks. KEYBOARD_LL and MOUSE_LL are exceptions. But when you register e.g. KEYBOARD hook it will receive callbacks only as long as your application is in foreground. When you switch to another application, your application stops to receive hook callbacks and will not start to receive them again as it becomes foreground. Call to UnhookWindowsHookEx returns 0 (associated error message tell something about bad descriptor). This behavior is by-design, because .NET cannot expose static function pointer. The only workaround is creation of small unmanaged DLL, or use those only 2 LL hooks which works.
SetWindowsHookEx DLL example needed      JanCasper   |   Edit   |   Show History
except for the _LL hook, SetWindowsHookEx must be using in a DLL. The DLL will be injected in other processes then your own and its methods are called in the context of those processes, you might need a shared section in the DLL to deal with this.

I have not been able to produce a good working example.

Two remarks:
- first, I think it is important that:

HINSTANCE hMod  : should be the instance that was passed from DLLmain()

BOOL WINAPI DllMain(
  __in  HINSTANCE hinstDLL,   <--- this instance
  __in  DWORD fdwReason,
  __in  LPVOID lpvReserved
);

- second:
#pragma data_seg("shared")
#pragma comment(linker, "/section:shared,rws")
HWND gTarget = 0;    // it is required to initialize shared variables
#pragma data_seg()

if you do not initialize such a variable, it will be placed in the default data section, not in the shared section. The word "shared" is just a name of a section and has no function, the 'rws' part is what specifies the 'shared' property. Note that spaces in the "linker" string are not allowed, as it follows commandline syntax.

We need a good example of this usage!

(The "Installing and Releasing Hook Procedures." section contains an incomplete example)

Tags What's this?: Add a tag
Flag as ContentBug
C++ Template      Asaf Shelly   |   Edit   |   Show History
Tags What's this?: Add a tag
Flag as ContentBug
© 2010 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement
Page view tracker