{
	"id": "3b24e9dc-72e9-44b7-88e0-08d70e13dda2",
	"created_at": "2026-04-06T01:30:04.177084Z",
	"updated_at": "2026-04-10T03:22:02.788574Z",
	"deleted_at": null,
	"sha1_hash": "3595ec075976793eb3f84fbadce79066751a2fc3",
	"title": "Hooks Overview - Win32 apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 85363,
	"plain_text": "Hooks Overview - Win32 apps\r\nBy Karl-Bridge-Microsoft\r\nArchived: 2026-04-06 01:00:12 UTC\r\nA hook is a mechanism by which an application can intercept events, such as messages, mouse actions, and\r\nkeystrokes. A function that intercepts a particular type of event is known as a hook procedure. A hook procedure\r\ncan act on each event it receives, and then modify or discard the event.\r\nSome uses for hooks include:\r\nMonitoring messages for debugging purposes\r\nProviding support for recording and playback of macros\r\nProviding support for a help key (F1)\r\nSimulating mouse and keyboard input\r\nImplementing a computer-based training (CBT) application\r\nNote\r\nHooks tend to slow down the system because they increase the amount of processing the system must perform for\r\neach message. You should install a hook only when necessary, and remove it as soon as possible.\r\nThis section discusses the following:\r\nHook Chains\r\nHook Procedures\r\nHook Types\r\nWH_CALLWNDPROC and WH_CALLWNDPROCRET\r\nWH_CBT\r\nWH_DEBUG\r\nWH_FOREGROUNDIDLE\r\nWH_GETMESSAGE\r\nWH_JOURNALPLAYBACK\r\nWH_JOURNALRECORD\r\nWH_KEYBOARD_LL\r\nWH_KEYBOARD\r\nWH_MOUSE_LL\r\nWH_MOUSE\r\nWH_MSGFILTER and WH_SYSMSGFILTER\r\nWH_SHELL\r\nThe system supports many different types of hooks; each type provides access to a different aspect of its message-handling mechanism. For example, an application can use the WH_MOUSE hook to monitor the message traffic\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 1 of 6\n\nfor mouse messages.\r\nThe system maintains a separate hook chain for each type of hook. A hook chain is a list of pointers to special,\r\napplication-defined callback functions called hook procedures. When a message occurs that is associated with a\r\nparticular type of hook, the system passes the message to each hook procedure referenced in the hook chain, one\r\nafter the other. The action a hook procedure can take depends on the type of hook involved. The hook procedures\r\nfor some types of hooks can only monitor messages; others can modify messages or stop their progress through\r\nthe chain, preventing them from reaching the next hook procedure or the destination window.\r\nTo take advantage of a particular type of hook, the developer provides a hook procedure and uses the\r\nSetWindowsHookEx function to install it into the chain associated with the hook. A hook procedure must have\r\nthe following syntax:\r\nLRESULT CALLBACK HookProc(\r\n int nCode,\r\n WPARAM wParam,\r\n LPARAM lParam\r\n)\r\n{\r\n // process event\r\n ...\r\n return CallNextHookEx(NULL, nCode, wParam, lParam);\r\n}\r\nHookProc is a placeholder for an application-defined name.\r\nThe nCode parameter is a hook code that the hook procedure uses to determine the action to perform. The value of\r\nthe hook code depends on the type of the hook; each type has its own characteristic set of hook codes. The values\r\nof the wParam and lParam parameters depend on the hook code, but they typically contain information about a\r\nmessage that was sent or posted.\r\nThe SetWindowsHookEx function always installs a hook procedure at the beginning of a hook chain. When an\r\nevent occurs that is monitored by a particular type of hook, the system calls the procedure at the beginning of the\r\nhook chain associated with the hook. Each hook procedure in the chain determines whether to pass the event to\r\nthe next procedure. A hook procedure passes an event to the next procedure by calling the CallNextHookEx\r\nfunction.\r\nNote that the hook procedures for some types of hooks can only monitor messages. The system passes messages\r\nto each hook procedure, regardless of whether a particular procedure calls CallNextHookEx.\r\nA global hook monitors messages for all threads in the same desktop as the calling thread. A thread-specific hook\r\nmonitors messages for only an individual thread. A global hook procedure can be called in the context of any\r\napplication in the same desktop as the calling thread, so the procedure must be in a separate DLL module. A\r\nthread-specific hook procedure is called only in the context of the associated thread. If an application installs a\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 2 of 6\n\nhook procedure for one of its own threads, the hook procedure can be in either the same module as the rest of the\r\napplication's code or in a DLL. If the application installs a hook procedure for a thread of a different application,\r\nthe procedure must be in a DLL. For information, see Dynamic-Link Libraries.\r\nNote\r\nYou should use global hooks only for debugging purposes; otherwise, you should avoid them. Global hooks hurt\r\nsystem performance and cause conflicts with other applications that implement the same type of global hook.\r\nEach type of hook enables an application to monitor a different aspect of the system's message-handling\r\nmechanism. The following sections describe the available hooks.\r\nWH_CALLWNDPROC and WH_CALLWNDPROCRET\r\nWH_CBT\r\nWH_DEBUG\r\nWH_FOREGROUNDIDLE\r\nWH_GETMESSAGE\r\nWH_JOURNALPLAYBACK\r\nWH_JOURNALRECORD\r\nWH_KEYBOARD_LL\r\nWH_KEYBOARD\r\nWH_MOUSE_LL\r\nWH_MOUSE\r\nWH_MSGFILTER and WH_SYSMSGFILTER\r\nWH_SHELL\r\nThe WH_CALLWNDPROC and WH_CALLWNDPROCRET hooks enable you to monitor messages sent to\r\nwindow procedures. The system calls a WH_CALLWNDPROC hook procedure before passing the message to\r\nthe receiving window procedure, and calls the WH_CALLWNDPROCRET hook procedure after the window\r\nprocedure has processed the message.\r\nThe WH_CALLWNDPROCRET hook passes a pointer to a CWPRETSTRUCT structure to the hook\r\nprocedure. The structure contains the return value from the window procedure that processed the message, as well\r\nas the message parameters associated with the message. Subclassing the window does not work for messages set\r\nbetween processes.\r\nFor more information, see the CallWndProc and CallWndRetProc callback functions.\r\nThe system calls a WH_CBT hook procedure before activating, creating, destroying, minimizing, maximizing,\r\nmoving, or sizing a window; before completing a system command; before removing a mouse or keyboard event\r\nfrom the system message queue; before setting the input focus; or before synchronizing with the system message\r\nqueue. The value the hook procedure returns determines whether the system allows or prevents one of these\r\noperations. The WH_CBT hook is intended primarily for computer-based training (CBT) applications.\r\nFor more information, see the CBTProc callback function.\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 3 of 6\n\nFor information, see WinEvents.\r\nThe system calls a WH_DEBUG hook procedure before calling hook procedures associated with any other hook\r\nin the system. You can use this hook to determine whether to allow the system to call hook procedures associated\r\nwith other types of hooks.\r\nFor more information, see the DebugProc callback function.\r\nThe WH_FOREGROUNDIDLE hook enables you to perform low priority tasks during times when its\r\nforeground thread is idle. The system calls a WH_FOREGROUNDIDLE hook procedure when the application's\r\nforeground thread is about to become idle.\r\nFor more information, see the ForegroundIdleProc callback function.\r\nThe WH_GETMESSAGE hook enables an application to monitor messages about to be returned by the\r\nGetMessage or PeekMessage function. You can use the WH_GETMESSAGE hook to monitor mouse and\r\nkeyboard input and other messages posted to the message queue.\r\nFor more information, see the GetMsgProc callback function.\r\nWarning\r\nJournaling Hooks APIs are unsupported starting in Windows 11 and will be removed in a future release. Because\r\nof this, we highly recommend calling the SendInput TextInput API instead.\r\nThe WH_JOURNALPLAYBACK hook enables an application to insert messages into the system message\r\nqueue. You can use this hook to play back a series of mouse and keyboard events recorded earlier by using\r\nWH_JOURNALRECORD. Regular mouse and keyboard input is disabled as long as a\r\nWH_JOURNALPLAYBACK hook is installed. A WH_JOURNALPLAYBACK hook is a global hook—it\r\ncannot be used as a thread-specific hook.\r\nThe WH_JOURNALPLAYBACK hook returns a time-out value. This value tells the system how many\r\nmilliseconds to wait before processing the current message from the playback hook. This enables the hook to\r\ncontrol the timing of the events it plays back.\r\nFor more information, see the JournalPlaybackProc callback function.\r\nWarning\r\nJournaling Hooks APIs are unsupported starting in Windows 11 and will be removed in a future release. Because\r\nof this, we highly recommend calling the SendInput TextInput API instead.\r\nThe WH_JOURNALRECORD hook enables you to monitor and record input events. Typically, you use this\r\nhook to record a sequence of mouse and keyboard events to play back later by using\r\nWH_JOURNALPLAYBACK. The WH_JOURNALRECORD hook is a global hook—it cannot be used as a\r\nthread-specific hook.\r\nFor more information, see the JournalRecordProc callback function.\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 4 of 6\n\nThe WH_KEYBOARD_LL hook enables you to monitor keyboard input events about to be posted in a thread\r\ninput queue.\r\nFor more information, see the LowLevelKeyboardProc callback function.\r\nThe WH_KEYBOARD hook enables an application to monitor message traffic for WM_KEYDOWN and\r\nWM_KEYUP messages about to be returned by the GetMessage or PeekMessage function. You can use the\r\nWH_KEYBOARD hook to monitor keyboard input posted to a message queue.\r\nFor more information, see the KeyboardProc callback function.\r\nThe WH_MOUSE_LL hook enables you to monitor mouse input events about to be posted in a thread input\r\nqueue.\r\nFor more information, see the LowLevelMouseProc callback function.\r\nThe WH_MOUSE hook enables you to monitor mouse messages about to be returned by the GetMessage or\r\nPeekMessage function. You can use the WH_MOUSE hook to monitor mouse input posted to a message queue.\r\nFor more information, see the MouseProc callback function.\r\nThe WH_MSGFILTER and WH_SYSMSGFILTER hooks enable you to monitor messages about to be\r\nprocessed by a menu, scroll bar, message box, or dialog box, and to detect when a different window is about to be\r\nactivated as a result of the user's pressing the ALT+TAB or ALT+ESC key combination. The WH_MSGFILTER\r\nhook can only monitor messages passed to a menu, scroll bar, message box, or dialog box created by the\r\napplication that installed the hook procedure. The WH_SYSMSGFILTER hook monitors such messages for all\r\napplications.\r\nThe WH_MSGFILTER and WH_SYSMSGFILTER hooks enable you to perform message filtering during\r\nmodal loops that is equivalent to the filtering done in the main message loop. For example, an application often\r\nexamines a new message in the main loop between the time it retrieves the message from the queue and the time it\r\ndispatches the message, performing special processing as appropriate. However, during a modal loop, the system\r\nretrieves and dispatches messages without allowing an application the chance to filter the messages in its main\r\nmessage loop. If an application installs a WH_MSGFILTER or WH_SYSMSGFILTER hook procedure, the\r\nsystem calls the procedure during the modal loop.\r\nAn application can call the WH_MSGFILTER hook directly by calling the CallMsgFilter function. By using\r\nthis function, the application can use the same code to filter messages during modal loops as it uses in the main\r\nmessage loop. To do so, encapsulate the filtering operations in a WH_MSGFILTER hook procedure and call\r\nCallMsgFilter between the calls to the GetMessage and DispatchMessage functions.\r\nwhile (GetMessage(\u0026msg, (HWND) NULL, 0, 0))\r\n{\r\n if (!CallMsgFilter(\u0026qmsg, 0))\r\n DispatchMessage(\u0026qmsg);\r\n}\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 5 of 6\n\nThe last argument of CallMsgFilter is simply passed to the hook procedure; you can enter any value. The hook\r\nprocedure, by defining a constant such as MSGF_MAINLOOP, can use this value to determine where the\r\nprocedure was called from.\r\nFor more information, see the MessageProc and SysMsgProc callback functions.\r\nA shell application can use the WH_SHELL hook to receive important notifications. The system calls a\r\nWH_SHELL hook procedure when the shell application is about to be activated and when a top-level window is\r\ncreated or destroyed.\r\nNote that custom shell applications do not receive WH_SHELL messages. Therefore, any application that\r\nregisters itself as the default shell must call the SystemParametersInfo function before it (or any other\r\napplication) can receive WH_SHELL messages. This function must be called with\r\nSPI_SETMINIMIZEDMETRICS and a MINIMIZEDMETRICS structure. Set the iArrange member of this\r\nstructure to ARW_HIDE.\r\nFor more information, see the ShellProc callback function.\r\nSource: https://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nhttps://msdn.microsoft.com/library/windows/desktop/ms644959.aspx\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://msdn.microsoft.com/library/windows/desktop/ms644959.aspx"
	],
	"report_names": [
		"ms644959.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775439004,
	"ts_updated_at": 1775791322,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3595ec075976793eb3f84fbadce79066751a2fc3.pdf",
		"text": "https://archive.orkl.eu/3595ec075976793eb3f84fbadce79066751a2fc3.txt",
		"img": "https://archive.orkl.eu/3595ec075976793eb3f84fbadce79066751a2fc3.jpg"
	}
}