Windows CBT Hooks
-
The remarks section certainly implies quite strongly that the application that calls
SetWindowsHookExmust keep running (and pumping messages).Thank you Richard. I reread the remarks and I see that you are correct.
Quote:
However, because a 32-bit application must run the hook code, the system executes the hook in the hooking app's context; specifically, on the thread that called SetWindowsHookEx. This means that the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes.
When I install the hook, I must pass a pointer to the hook callback function. However, that's a pointer that's only valid inside the process space of the application installing the hook. How does it use that pointer to call the correct code inside the address space of the application that is a target of the hook? :confused:
The difficult we do right away... ...the impossible takes slightly longer.
-
Thank you Richard. I reread the remarks and I see that you are correct.
Quote:
However, because a 32-bit application must run the hook code, the system executes the hook in the hooking app's context; specifically, on the thread that called SetWindowsHookEx. This means that the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes.
When I install the hook, I must pass a pointer to the hook callback function. However, that's a pointer that's only valid inside the process space of the application installing the hook. How does it use that pointer to call the correct code inside the address space of the application that is a target of the hook? :confused:
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
a pointer to the hook callback function.
The system keeps that address (which is the target of the hook) and uses it to call back into your application at the appropriate time (i.e when the relevant hook event triggers). But if you close your application, its address space is destroyed and the hook is no longer valid, so the system will no longer call it.
-
Richard Andrew x64 wrote:
a pointer to the hook callback function.
The system keeps that address (which is the target of the hook) and uses it to call back into your application at the appropriate time (i.e when the relevant hook event triggers). But if you close your application, its address space is destroyed and the hook is no longer valid, so the system will no longer call it.
Thank you for your response. OK, so if the system calls back into my application at the appropriate time, why must the system load the DLL containing the filter function into each process that is hooked? IOW, if the hook function is run inside the installing application, why must the hook function DLL be injected into every targeted application?
The difficult we do right away... ...the impossible takes slightly longer.
-
Thank you for your response. OK, so if the system calls back into my application at the appropriate time, why must the system load the DLL containing the filter function into each process that is hooked? IOW, if the hook function is run inside the installing application, why must the hook function DLL be injected into every targeted application?
The difficult we do right away... ...the impossible takes slightly longer.
Sorry I don't know the answer to that one. There is an implication that injecting the hook into another process can be done of the call-back function is in a dll. If that is the case then the dll must be associated withe the address space of that process. I must admit it is a long time since I used this feature so my recollection of it is not 100%.
-
Sorry I don't know the answer to that one. There is an implication that injecting the hook into another process can be done of the call-back function is in a dll. If that is the case then the dll must be associated withe the address space of that process. I must admit it is a long time since I used this feature so my recollection of it is not 100%.
OK Thank you for your contributions thus far.
The difficult we do right away... ...the impossible takes slightly longer.
-
Thank you for your response. OK, so if the system calls back into my application at the appropriate time, why must the system load the DLL containing the filter function into each process that is hooked? IOW, if the hook function is run inside the installing application, why must the hook function DLL be injected into every targeted application?
The difficult we do right away... ...the impossible takes slightly longer.
You need an instance handle to load the DLL ... guess what happens to the instance handle when the application terminates :-)
In vino veritas
-
You need an instance handle to load the DLL ... guess what happens to the instance handle when the application terminates :-)
In vino veritas
Yes, thank you. I progressed to the point where I'm creating the hook and processing it successfully. But now the problem is that when the hook installer application terminates, it crashes all of the hooked applications *even though* I call UnhookWindowsHookEx() to remove the hook before terminating. Would you have any hints what I can do about that?
The difficult we do right away... ...the impossible takes slightly longer.
-
Yes, thank you. I progressed to the point where I'm creating the hook and processing it successfully. But now the problem is that when the hook installer application terminates, it crashes all of the hooked applications *even though* I call UnhookWindowsHookEx() to remove the hook before terminating. Would you have any hints what I can do about that?
The difficult we do right away... ...the impossible takes slightly longer.
The unhook is usually just done in WM_DESTROY of the main application. From memory it must be before you post WM_QUIT which will kill the instance handle.
In vino veritas
-
The unhook is usually just done in WM_DESTROY of the main application. From memory it must be before you post WM_QUIT which will kill the instance handle.
In vino veritas
Do you mean that the system waits until the window receives the WM_DESTROY message before it actually unhooks the hook? Or do you mean that I must call UnhookWindowsHookEx BEFORE the WM_QUIT message is posted?
The difficult we do right away... ...the impossible takes slightly longer.
-
Do you mean that the system waits until the window receives the WM_DESTROY message before it actually unhooks the hook? Or do you mean that I must call UnhookWindowsHookEx BEFORE the WM_QUIT message is posted?
The difficult we do right away... ...the impossible takes slightly longer.
Unhook it before you post the WM_QUIT message
In vino veritas
