SetWindowsHookEx(WH_KEYBOARD) - 64-bit and 32-bit hooks don't work simultaneously

Question

SetWindowsHookEx(WH_KEYBOARD) - 64-bit and 32-bit hooks don't work simultaneously

Mikola Akbal̆ 75

Hi! I try to install hook with SetWindowsHookEx(WH_KEYBOARD), and I see that 32-bit hook and 64-bit hook can not work simultaneously. If I install both, only 64-bit hook works, 32-bit doesn't.

I solved this problem by algorithm that chooses appropriate bitness depending on bitness of process that owns foreground window. One of hooks I turn off, and another I turn on. At the moment, only 32-bit hook is installed, or only 64-bit hook is installed. That solves, but it's difficult.

Documentation of SetWindowsHookEx() says that both - 32-bit and 64-bit - can work simultaneously. Did I understand it correctly?

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexw To hook all applications on the desktop of a 64-bit Windows installation, install a 32-bit global hook and a 64-bit global hook, each from appropriate processes, and be sure to keep pumping messages in the hooking application to avoid blocking normal functioning. If you already have a 32-bit global hooking application and it doesn't need to run in each application's context, you may not need to create a 64-bit version.

So, why doesn't it work?

Viorel 122.9K Reputation points

2023-03-04T09:11:49.94+00:00

What hooks are you set and how did you check them?
David Lowndes 4,726 Reputation points

2023-03-04T10:17:50.6866667+00:00

Were you trying to install a 64-bit & 32-bit hook in the same process?
Note that the documentation says:

"install a 32-bit global hook and a 64-bit global hook, each from appropriate processes"
RLWA32 49,666 Reputation points

2023-03-04T11:34:02.8666667+00:00

I solved this problem by algorithm that chooses appropriate bitness depending on bitness of process that owns foreground window.

Why would you want to install both 64-bit and 32-bit hooks in a particular process? The documentation speaks about using 64-bit and 32-bit hooks in the context of global hooks, not process-specific ones.

One of hooks I turn off, and another I turn on.

What does this mean? How do you toggle an installed hook?

@David Lowndes pointed out that 32-bit and 64-bit hooks need to be installed from appropriate processes. Additionally, the documentation states "The 32-bit and 64-bit DLLs must have different names." Have you done this?
RLWA32 49,666 Reputation points

2023-03-04T20:37:58.6866667+00:00

They are questions to help us understand what was actually done. That's why they are posted as Comments and not as Answers.

The original post was essentially a brief description that can be distilled to "I tried to install 32-bit and 64-bit hooks at the same time but it didn't work. Why?"

I suggest you share a code sample that reproduces the problem. Help us to help you.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:00:18.5833333+00:00

Hooks: WH_KEYBOARD and WH_CALLWNDPROCRET. Identical hooks in 32-bit dll and 64-bit dll. The same C++ code that is compiled in 32-bit dll and 64-bit dll - with different file names. The only difference in C++ code is name of window class for communication window. Application specific window messages are sent to communication windows to control the actions of controllers and main process.

Hook.64.dll - 64-bit dll.

Hook.32.dll - 32-bit dll.

Hook.Controller.64.exe - 64-bit process that installs 64-bit hook.

Hook.Controller.32.exe - 32-bit process that installs 32-bit hook.

Application.exe - main 64-bit process. It doesn't install hooks. Hooks are installed by Controllers with appropriate bitness.

If only one of these hooks is installed - it works. In processes with corresponding bitness.

If both are installed - only 64-bit hook works. 32-bit doesn't work. I don't see activity that must be.

If I press certain key, it activates certain keyboard layout. It works in 32-bit processes when I install only 32-bit hook. It works in 64-bit processes when I install only 64-bit hook. If I install both hooks - 32-bit and 64-bit - in that case 32-bit processes don't activate keyboard layout. Hook procedure in 32-bit dll is not called? What can be reason?
David Lowndes 4,726 Reputation points

2023-03-05T00:10:36.44+00:00

Can you elaborate on what precisely doesn't work? Does the 32-bit hook get installed - does any API report an error?

Do your hook functions play by the rules and call CallNextHookEx?
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:51:20.41+00:00

"install a 32-bit global hook and a 64-bit global hook, each from appropriate processes"

Yes, it is.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:53:07.08+00:00

Why would you want to install both 64-bit and 32-bit hooks in a particular process?

I need global hook - that is installed in every 32-bit and 64-bit process in logon session.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:55:58.3533333+00:00

The documentation speaks about using 64-bit and 32-bit hooks in the context of global hooks, not process-specific ones.

I don't specify certain process or thread to hook. I need global hook. For every process and thread in a logon session. My keyboard layout setter must work in all applications that are run.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:57:22.6366667+00:00

What does this mean? How do you toggle an installed hook?

Are you kidding? SetWindowsHookEx() installs. UnhookWindowsHookEx() removes.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:58:29.9666667+00:00

@David Lowndes pointed out that 32-bit and 64-bit hooks need to be installed from appropriate processes. Additionally, the documentation states "The 32-bit and 64-bit DLLs must have different names." Have you done this?

Yes. It is. It's shown in other comment.

Mikola Akbal̆ 75

No. My guess was wrong. That doesn't solve.

I changed Keyboard_Procedure(). Now, it calls CallNextHookEx() always:

extern "C"
__declspec(dllexport)
LRESULT
CALLBACK
Keyboard_Procedure(_In_ int code, _In_ WPARAM wParam, _In_ LPARAM lParam)
{
	if (code < 0)
    {
		return CallNextHookEx(NULL, code, wParam, lParam);
	}

    switch (wParam)
    {
        case VK_F8:
        {
            // Call ActivateKeyboardLayout()

            // "break" instead of "return TRUE"
            break;
	    }
    }

    // That is called always
    return CallNextHookEx(NULL, code, wParam, lParam);
}

The symptoms are the same. The question is still opened.

Mikola Akbal̆ 75 Reputation points

2023-03-05T03:13:42.47+00:00
Hook.Controller.32/64.exe calls it to set hook:

HHOOK Hook_Handle = SetWindowsHookExW(WH_KEYBOARD, Keyboard_Procedure_Address, Dll_Handle, 0);

Setting is successful. I don't see errors.
Mikola Akbal̆ 75 Reputation points

2023-03-05T03:41:27.65+00:00

What does this mean? How do you toggle an installed hook?

I simply UnhookWindowsHookEx() one of them and SetWindowsHookEx() another one.

Main process of my application monitors foreground window. If it sees that bitness is changed - it sends commands through window messages (WM_APP + ) to communication windows of controllers. It's simply way of communication between processes of solution. It could be UDP or TCP, but I choosed window messages. When Hook.Controller.32/64.exe receives command from main process - it hooks or unhooks.

Hook.Controller.64.exe loads Hook.64.dll into his address space and sets hook for all 64-bit processes. Hook.Controller.32.exe does the same with 32-bit processes. EasyType.exe - main process - controls what Controllers must do. If EasyType.exe sees that bitness of active process is changed - it unhooks one bitness and hooks appropriate. That solves. That works. But it's difficulty.

My application consists of 5 files:

EasyType.exe - main process.

Hook.Controller.64.exe - Hook controller for 64-bit hook dll and 64-bit processes.

Hook.Controller.32.exe - The same for 32-bit. The only difference is name of window class that is used for communication with EasyType.exe.

Hook.64.dll - library that contains hook procedures. It's compiled to amd64.

Hook.32.dll - the same for x86. The only difference is slightly different names of exported functions.

EasyType.exe monitors foreground window. If it sees that bitness changed, it sends command to Controllers. Controllers unhook one bitness and hook another. So, at the moment - hook with only one bitness is installed in the system, not both. That solves my task. But it's difficult. And article says that 64-bit and 32-bit hooks can work simultaneously.
Mikola Akbal̆ 75 Reputation points

2023-03-05T04:55:47.18+00:00
Does the 32-bit hook get installed

I added debug messages to hook dlls.

I see that both - 32-bit and 64-bit - dlls are loaded into corresponding 32-bit and 64-bit process. I see message: "DLL_PROCESS_ATTACH".

I don't see message: "DLL_PROCESS_DETACH". That means that both - 32-bit and 64-bit - dlls continue to stay loaded into corresponding 32-bit and 64-bit process.

But only 32-bit dll reports about F8/F9 key pressing. 64-bit dll doesn't see that pressing. That means hook procedure is not called.

Following will be interesting for you.

===== Experiment 1 =================================

I run EasyType.exe;

I press F9 one time in 32-bit application;

I close EasyType.exe.

Behavior of 32-bit process is correct. It sees pressing of F9. Code is executed in this 32-bit process. The keyboard layout is correctly activated.

The strange: 12 milliseconds later pressing of this F9 appears in the report of Hook.Controller.64.exe. ?? Hook.64.dll is loaded into Hook.Controller.64.exe and Keyboard_Procedure() is executed in process Hook.Controller.64.exe. Can you explain this? It must be hook chain.

I don't understand why at all this 64-bit Keyboard_Procedure() is executed in another process by another thread. When keyboard input is dedicated for this 32-bit application only. That is not input for Hook.Controller.64.exe.

===== Experiment 2 =================================

I run EasyType.exe;

I press F9 one time in 64-bit application;

I close EasyType.exe.

Keyboard_Procedure() in this 64-bit application is not called.

Keyboard_Procedure() is called in Hook.Controller.32.exe and in Hook.Controller.64.exe. ?? And pressing of F9 appears twice in both of them. ?? Report says: F9 is pressed and 44 milliseconds later - it is pressed again. When I pressed it only once.

Reports of Hook.Controller.32.exe and Hook.Controller.64.exe are identical. Pressing in Hook.Controller.64.exe appears few milliseconds later. Must be, 64-bit Controller is called later in a hook chain.

===============================================

That's all. Can you explain why the behavior is so strange?
David Lowndes 4,726 Reputation points

2023-03-05T10:53:34.1333333+00:00

Your original hook code looked OK to me. I'd expect that returning TRUE for the case you handle ought to prevent the other hook from seeing that key.
RLWA32 49,666 Reputation points

2023-03-05T12:13:31.5433333+00:00

From brief observation of my own test -

What seems to be happening when global 32-bit and 64-bit keyboard hooks are installed is that whichever global hook is installed last is the one whose hook procedure is called in the context of a hooked process (i.e., from the injected dll) when the bitness matches. The other installed global hook procedure is called in the context of the installing thread even though a global hook with matching bitness was installed. Interestingly, in such cases process explorer shows that the dll containing the hook procedure was loaded into the process but was apparently not used by the system.

This behavior seems to me to be contrary to the documentation. Its not clear whether this is a Windows bug or a documentation error. This behavior was observed on Win 10 22H2 and also Win 8.1.

You can see the order of hook installation and the context in which hook procedures were called for a 64-bit process and 32-bit process with our favorite target, notepad.exe.
David Lowndes 4,726 Reputation points

2023-03-05T15:35:15.69+00:00

The docs do mention that both 32 & 64-bit hooks may not be necessary:

"If you already have a 32-bit global hooking application and it doesn't need to run in each application's context, you may not need to create a 64-bit version."

Indeed, either a 32 or 64-bit WH_KEYBOARD hook seems to work fine (for a very simple hook) if the process that sets the hook is pumping messages.

"...and be sure to keep pumping messages in the hooking application to avoid blocking normal functioning"
RLWA32 49,666 Reputation points

2023-03-05T15:49:09.1866667+00:00

I agree with the questioner and interpret the very first paragraph in the Remarks section to mean that properly created and installed 32-bit and 64-bit global hooks should not be called out of context for processes of like bitness. Unfortunately, this isn't the first time where documentation has been confusing and ambiguous.
David Lowndes 4,726 Reputation points

2023-03-05T20:13:53.7866667+00:00

It is indeed confusing and I guess it may even depend on the type of hook too. The KeyboardProc documentation mentions:

"This hook may be called in the context of the thread that installed it. The call is made by sending a message to the thread that installed the hook. Therefore, the thread that installed the hook must have a message loop."

In my tests (on Win11 21H2), I also see the hook used is only ever whichever was last set, and only when the foreground window is of the same bitness as the last hook is the hook called from that process.

If you feel that the documentation is incomplete/wrong, use the Feedback link and try to point out the issue to MS.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:09:40.9266667+00:00

Did you mean I should investigate the problem using SoftIce? I think that is not my work. Too much work. I am developer of applied application, not Windows system engineer. To solve the problem should Microsoft. I need working interface, not developing the system.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:14:36.6166667+00:00

This behavior seems to me to be contrary to the documentation. Its not clear whether this is a Windows bug or a documentation error

That looks like bug. My opinion: hook procedure must be called only in hooked process, not in process that installed hook.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:19:27.37+00:00

Indeed, either a 32 or 64-bit WH_KEYBOARD hook seems to work fine

Applied programming often need installing a hook in all processes - 32-bit and 64-bit at the same time. Because applications can be 32-bit and 64-bit. So, proposition of using 32-bit or 64-bit only is inappropriate.

Documentation says that both bitnesses must work at the same time. So, it looks like bug.
David Lowndes 4,726 Reputation points

2023-03-05T23:14:28.0533333+00:00

@Mikola Akbal̆

For the case of the global keyboard hook, why do you need the hook to be called in the process context of the foreground window?
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-06T02:12:53.5933333+00:00

@RLWA32 Could you please show the reproducible sample in order to escalate the question?
Mikola Akbal̆ 75 Reputation points

2023-03-06T03:17:47.2966667+00:00

For the case of the global keyboard hook, why do you need the hook to be called in the process context of the foreground window?

Suspects of spying?

My utility simplifies activating of necessary keyboard layout. It's actual when your native alphabet is not latin. Pressing of Alt+Shift several times with controlling the right-bottom corner of screen makes me tired. My solution is pressing only one key that enables certain keyboard layout.

This layout must be enabled in every window application in the session. That's why it must be executed by the thread of target application.
Mikola Akbal̆ 75 Reputation points

2023-03-06T07:20:13.81+00:00

@Xiaopo Yang - MSFT • Could you please show the reproducible sample in order to escalate the question?

I made reproducible sample. It was difficult. Git twice broke the database during this process :) .

I placed it here:

https://dev.azure.com/acbaile/_git/Reproduce.32.64.Hooks.Problem

It's Visual Studio 2022 Community solution C++. You can view code. It contains debug messages. I removed unnecessary code of my application, simplifed it, translated to English.

I placed instructions in the file "How to reproduce the problem.txt". You can find it here and in the repository.

How to reproduce the problem.txt
Mikola Akbal̆ 75 Reputation points

2023-03-06T07:31:18.8466667+00:00

I tried to run hook controllers in different order.

Resume: Correct behavior of hook has the bitness that is installed last. Bitness that is installed first has incorrect behavior - Keyboard_Procedure() in the context of target process is not called.
Mikola Akbal̆ 75 Reputation points

2023-03-06T12:36:54.8766667+00:00

You may have better success using a WH_GETMESSAGE hook

Yeah. WH_GETMESSAGE works. I think we have to change title of this question. The problem is specific to WH_KEYBOARD.

Is WH_CALLWNDPROCRET OK?
Mikola Akbal̆ 75 Reputation points

2023-03-07T21:53:35.51+00:00

@Xiaopo Yang - MSFT • Could you please show the reproducible sample in order to escalate the question? https://dev.azure.com/acbaile/_git/Reproduce.32.64.Hooks.Problem

Take the repository. I will remove it in a few days.
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-08T01:37:47.68+00:00

Took it. But @RLWA32 's workaround works fine. Do I still need to look into this?
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:09:11.43+00:00
Do your hook functions play by the rules and call CallNextHookEx?

Of course. I have read the article with deep attention. English is not native, and I could misunderstand something. I understood that 32-bit and 64-bit hooks can work simultaneously. Maybe, documentation doesn't explain some aspect of implementing. Maybe, it explains it unclearly.

Does the 32-bit hook get installed - does any API report an error?

No. I monitor all errors.

The code of keyboard hook:

extern "C" __declspec(dllexport) LRESULT CALLBACK Keyboard_Procedure(_In_ int code, _In_ WPARAM wParam, _In_ LPARAM lParam) { if (code < 0) { return CallNextHookEx(NULL, code, wParam, lParam); } switch (wParam) { case VK_F8: { // Call ActivateKeyboardLayout() /* I return TRUE to exclude processing of this key press by another application. If it sets keyboard layout it must not run the debugger. */ return TRUE; } } return CallNextHookEx(NULL, code, wParam, lParam); }

It seems, I guessed. The reason is returning the TRUE? You want to say that 32-bit hook and 64-bit hook are in the same chain? If it is, please, write it to article clearly. Because I got impression that 32-bit and 64-bit hooks work separately.

The impression is strange. Because 32-bit machine code and 64-bit machine code can not call each other. Different machine code. Parameters are different. WPARAM, LRESULT have different length in 32-bit and 64-bit process. How can CallNextHookEx() belonging to 32-bit process call code in 64-bit process? All of these make impression that 32-bit hooks and 64-bit hooks are in the different chains. And article doesn't explain it clearly.

How to solve the following moment? If F8 turns on the keyboard layout, I don't want it does any other action. Visual Studio, for example, uses F-keys actively. I don't want to run a debugger when I want only to turn on layout.
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:11:46.8966667+00:00

@Xiaopo Yang - MSFT - MSFT Took it. But @RLWA32 's workaround works fine. Do I still need to look into this?

Yes. The proposition of @RLWA32 is not acceptable. Please, solve this problem.
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:12:39.6666667+00:00

David Lowndes, RLWA32 - These are not answers.
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-09T06:27:05.88+00:00

@Mikola Akbal̆ I reproduced and will consult this next Monday.

Accepted answer

2 additional answers

Your answer

Viorel 122.9K Reputation points

2023-03-04T09:11:49.94+00:00

What hooks are you set and how did you check them?
David Lowndes 4,726 Reputation points

2023-03-04T10:17:50.6866667+00:00

Were you trying to install a 64-bit & 32-bit hook in the same process?
Note that the documentation says:

"install a 32-bit global hook and a 64-bit global hook, each from appropriate processes"
RLWA32 49,666 Reputation points

2023-03-04T11:34:02.8666667+00:00

I solved this problem by algorithm that chooses appropriate bitness depending on bitness of process that owns foreground window.

Why would you want to install both 64-bit and 32-bit hooks in a particular process? The documentation speaks about using 64-bit and 32-bit hooks in the context of global hooks, not process-specific ones.

One of hooks I turn off, and another I turn on.

What does this mean? How do you toggle an installed hook?

@David Lowndes pointed out that 32-bit and 64-bit hooks need to be installed from appropriate processes. Additionally, the documentation states "The 32-bit and 64-bit DLLs must have different names." Have you done this?
RLWA32 49,666 Reputation points

2023-03-04T20:37:58.6866667+00:00

They are questions to help us understand what was actually done. That's why they are posted as Comments and not as Answers.

The original post was essentially a brief description that can be distilled to "I tried to install 32-bit and 64-bit hooks at the same time but it didn't work. Why?"

I suggest you share a code sample that reproduces the problem. Help us to help you.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:00:18.5833333+00:00

Hooks: WH_KEYBOARD and WH_CALLWNDPROCRET. Identical hooks in 32-bit dll and 64-bit dll. The same C++ code that is compiled in 32-bit dll and 64-bit dll - with different file names. The only difference in C++ code is name of window class for communication window. Application specific window messages are sent to communication windows to control the actions of controllers and main process.

Hook.64.dll - 64-bit dll.

Hook.32.dll - 32-bit dll.

Hook.Controller.64.exe - 64-bit process that installs 64-bit hook.

Hook.Controller.32.exe - 32-bit process that installs 32-bit hook.

Application.exe - main 64-bit process. It doesn't install hooks. Hooks are installed by Controllers with appropriate bitness.

If only one of these hooks is installed - it works. In processes with corresponding bitness.

If both are installed - only 64-bit hook works. 32-bit doesn't work. I don't see activity that must be.

If I press certain key, it activates certain keyboard layout. It works in 32-bit processes when I install only 32-bit hook. It works in 64-bit processes when I install only 64-bit hook. If I install both hooks - 32-bit and 64-bit - in that case 32-bit processes don't activate keyboard layout. Hook procedure in 32-bit dll is not called? What can be reason?
David Lowndes 4,726 Reputation points

2023-03-05T00:10:36.44+00:00

Can you elaborate on what precisely doesn't work? Does the 32-bit hook get installed - does any API report an error?

Do your hook functions play by the rules and call CallNextHookEx?
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:51:20.41+00:00

"install a 32-bit global hook and a 64-bit global hook, each from appropriate processes"

Yes, it is.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:53:07.08+00:00

Why would you want to install both 64-bit and 32-bit hooks in a particular process?

I need global hook - that is installed in every 32-bit and 64-bit process in logon session.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:55:58.3533333+00:00

The documentation speaks about using 64-bit and 32-bit hooks in the context of global hooks, not process-specific ones.

I don't specify certain process or thread to hook. I need global hook. For every process and thread in a logon session. My keyboard layout setter must work in all applications that are run.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:57:22.6366667+00:00

What does this mean? How do you toggle an installed hook?

Are you kidding? SetWindowsHookEx() installs. UnhookWindowsHookEx() removes.
Mikola Akbal̆ 75 Reputation points

2023-03-05T00:58:29.9666667+00:00

@David Lowndes pointed out that 32-bit and 64-bit hooks need to be installed from appropriate processes. Additionally, the documentation states "The 32-bit and 64-bit DLLs must have different names." Have you done this?

Yes. It is. It's shown in other comment.
Mikola Akbal̆ 75 Reputation points

2023-03-05T02:57:55.9266667+00:00

No. My guess was wrong. That doesn't solve.

I changed Keyboard_Procedure(). Now, it calls CallNextHookEx() always:

extern "C" __declspec(dllexport) LRESULT CALLBACK Keyboard_Procedure(_In_ int code, _In_ WPARAM wParam, _In_ LPARAM lParam) { if (code < 0) { return CallNextHookEx(NULL, code, wParam, lParam); } switch (wParam) { case VK_F8: { // Call ActivateKeyboardLayout() // "break" instead of "return TRUE" break; } } // That is called always return CallNextHookEx(NULL, code, wParam, lParam); }

The symptoms are the same. The question is still opened.
Mikola Akbal̆ 75 Reputation points

2023-03-05T03:13:42.47+00:00

Hook.Controller.32/64.exe calls it to set hook:

HHOOK Hook_Handle = SetWindowsHookExW(WH_KEYBOARD, Keyboard_Procedure_Address, Dll_Handle, 0);

Setting is successful. I don't see errors.
Mikola Akbal̆ 75 Reputation points

2023-03-05T03:41:27.65+00:00

What does this mean? How do you toggle an installed hook?

I simply UnhookWindowsHookEx() one of them and SetWindowsHookEx() another one.

Main process of my application monitors foreground window. If it sees that bitness is changed - it sends commands through window messages (WM_APP + ) to communication windows of controllers. It's simply way of communication between processes of solution. It could be UDP or TCP, but I choosed window messages. When Hook.Controller.32/64.exe receives command from main process - it hooks or unhooks.

Hook.Controller.64.exe loads Hook.64.dll into his address space and sets hook for all 64-bit processes. Hook.Controller.32.exe does the same with 32-bit processes. EasyType.exe - main process - controls what Controllers must do. If EasyType.exe sees that bitness of active process is changed - it unhooks one bitness and hooks appropriate. That solves. That works. But it's difficulty.

My application consists of 5 files:

EasyType.exe - main process.

Hook.Controller.64.exe - Hook controller for 64-bit hook dll and 64-bit processes.

Hook.Controller.32.exe - The same for 32-bit. The only difference is name of window class that is used for communication with EasyType.exe.

Hook.64.dll - library that contains hook procedures. It's compiled to amd64.

Hook.32.dll - the same for x86. The only difference is slightly different names of exported functions.

EasyType.exe monitors foreground window. If it sees that bitness changed, it sends command to Controllers. Controllers unhook one bitness and hook another. So, at the moment - hook with only one bitness is installed in the system, not both. That solves my task. But it's difficult. And article says that 64-bit and 32-bit hooks can work simultaneously.
David Lowndes 4,726 Reputation points

2023-03-05T10:53:34.1333333+00:00

Your original hook code looked OK to me. I'd expect that returning TRUE for the case you handle ought to prevent the other hook from seeing that key.
RLWA32 49,666 Reputation points

2023-03-05T12:13:31.5433333+00:00

From brief observation of my own test -

What seems to be happening when global 32-bit and 64-bit keyboard hooks are installed is that whichever global hook is installed last is the one whose hook procedure is called in the context of a hooked process (i.e., from the injected dll) when the bitness matches. The other installed global hook procedure is called in the context of the installing thread even though a global hook with matching bitness was installed. Interestingly, in such cases process explorer shows that the dll containing the hook procedure was loaded into the process but was apparently not used by the system.

This behavior seems to me to be contrary to the documentation. Its not clear whether this is a Windows bug or a documentation error. This behavior was observed on Win 10 22H2 and also Win 8.1.

You can see the order of hook installation and the context in which hook procedures were called for a 64-bit process and 32-bit process with our favorite target, notepad.exe.
David Lowndes 4,726 Reputation points

2023-03-05T15:35:15.69+00:00

The docs do mention that both 32 & 64-bit hooks may not be necessary:

"If you already have a 32-bit global hooking application and it doesn't need to run in each application's context, you may not need to create a 64-bit version."

Indeed, either a 32 or 64-bit WH_KEYBOARD hook seems to work fine (for a very simple hook) if the process that sets the hook is pumping messages.

"...and be sure to keep pumping messages in the hooking application to avoid blocking normal functioning"
RLWA32 49,666 Reputation points

2023-03-05T15:49:09.1866667+00:00

I agree with the questioner and interpret the very first paragraph in the Remarks section to mean that properly created and installed 32-bit and 64-bit global hooks should not be called out of context for processes of like bitness. Unfortunately, this isn't the first time where documentation has been confusing and ambiguous.
David Lowndes 4,726 Reputation points

2023-03-05T20:13:53.7866667+00:00

It is indeed confusing and I guess it may even depend on the type of hook too. The KeyboardProc documentation mentions:

"This hook may be called in the context of the thread that installed it. The call is made by sending a message to the thread that installed the hook. Therefore, the thread that installed the hook must have a message loop."

In my tests (on Win11 21H2), I also see the hook used is only ever whichever was last set, and only when the foreground window is of the same bitness as the last hook is the hook called from that process.

If you feel that the documentation is incomplete/wrong, use the Feedback link and try to point out the issue to MS.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:09:40.9266667+00:00

Did you mean I should investigate the problem using SoftIce? I think that is not my work. Too much work. I am developer of applied application, not Windows system engineer. To solve the problem should Microsoft. I need working interface, not developing the system.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:14:36.6166667+00:00

This behavior seems to me to be contrary to the documentation. Its not clear whether this is a Windows bug or a documentation error

That looks like bug. My opinion: hook procedure must be called only in hooked process, not in process that installed hook.
Mikola Akbal̆ 75 Reputation points

2023-03-05T22:19:27.37+00:00

Indeed, either a 32 or 64-bit WH_KEYBOARD hook seems to work fine

Applied programming often need installing a hook in all processes - 32-bit and 64-bit at the same time. Because applications can be 32-bit and 64-bit. So, proposition of using 32-bit or 64-bit only is inappropriate.

Documentation says that both bitnesses must work at the same time. So, it looks like bug.
David Lowndes 4,726 Reputation points

2023-03-05T23:14:28.0533333+00:00

@Mikola Akbal̆

For the case of the global keyboard hook, why do you need the hook to be called in the process context of the foreground window?
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-06T02:12:53.5933333+00:00

@RLWA32 Could you please show the reproducible sample in order to escalate the question?
Mikola Akbal̆ 75 Reputation points

2023-03-06T03:17:47.2966667+00:00

For the case of the global keyboard hook, why do you need the hook to be called in the process context of the foreground window?

Suspects of spying?

My utility simplifies activating of necessary keyboard layout. It's actual when your native alphabet is not latin. Pressing of Alt+Shift several times with controlling the right-bottom corner of screen makes me tired. My solution is pressing only one key that enables certain keyboard layout.

This layout must be enabled in every window application in the session. That's why it must be executed by the thread of target application.
Mikola Akbal̆ 75 Reputation points

2023-03-06T07:20:13.81+00:00

@Xiaopo Yang - MSFT • Could you please show the reproducible sample in order to escalate the question?

I made reproducible sample. It was difficult. Git twice broke the database during this process :) .

I placed it here:

https://dev.azure.com/acbaile/_git/Reproduce.32.64.Hooks.Problem

It's Visual Studio 2022 Community solution C++. You can view code. It contains debug messages. I removed unnecessary code of my application, simplifed it, translated to English.

I placed instructions in the file "How to reproduce the problem.txt". You can find it here and in the repository.

How to reproduce the problem.txt
Mikola Akbal̆ 75 Reputation points

2023-03-06T07:31:18.8466667+00:00

I tried to run hook controllers in different order.

Resume: Correct behavior of hook has the bitness that is installed last. Bitness that is installed first has incorrect behavior - Keyboard_Procedure() in the context of target process is not called.
Mikola Akbal̆ 75 Reputation points

2023-03-06T12:36:54.8766667+00:00

You may have better success using a WH_GETMESSAGE hook

Yeah. WH_GETMESSAGE works. I think we have to change title of this question. The problem is specific to WH_KEYBOARD.

Is WH_CALLWNDPROCRET OK?
Mikola Akbal̆ 75 Reputation points

2023-03-07T21:53:35.51+00:00

@Xiaopo Yang - MSFT • Could you please show the reproducible sample in order to escalate the question? https://dev.azure.com/acbaile/_git/Reproduce.32.64.Hooks.Problem

Take the repository. I will remove it in a few days.
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-08T01:37:47.68+00:00

Took it. But @RLWA32 's workaround works fine. Do I still need to look into this?
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:09:11.43+00:00

Do your hook functions play by the rules and call CallNextHookEx?

Of course. I have read the article with deep attention. English is not native, and I could misunderstand something. I understood that 32-bit and 64-bit hooks can work simultaneously. Maybe, documentation doesn't explain some aspect of implementing. Maybe, it explains it unclearly.

Does the 32-bit hook get installed - does any API report an error?

No. I monitor all errors.

The code of keyboard hook:

extern "C" __declspec(dllexport) LRESULT CALLBACK Keyboard_Procedure(_In_ int code, _In_ WPARAM wParam, _In_ LPARAM lParam) { if (code < 0) { return CallNextHookEx(NULL, code, wParam, lParam); } switch (wParam) { case VK_F8: { // Call ActivateKeyboardLayout() /* I return TRUE to exclude processing of this key press by another application. If it sets keyboard layout it must not run the debugger. */ return TRUE; } } return CallNextHookEx(NULL, code, wParam, lParam); }

It seems, I guessed. The reason is returning the TRUE? You want to say that 32-bit hook and 64-bit hook are in the same chain? If it is, please, write it to article clearly. Because I got impression that 32-bit and 64-bit hooks work separately.

The impression is strange. Because 32-bit machine code and 64-bit machine code can not call each other. Different machine code. Parameters are different. WPARAM, LRESULT have different length in 32-bit and 64-bit process. How can CallNextHookEx() belonging to 32-bit process call code in 64-bit process? All of these make impression that 32-bit hooks and 64-bit hooks are in the different chains. And article doesn't explain it clearly.

How to solve the following moment? If F8 turns on the keyboard layout, I don't want it does any other action. Visual Studio, for example, uses F-keys actively. I don't want to run a debugger when I want only to turn on layout.
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:11:46.8966667+00:00

@Xiaopo Yang - MSFT - MSFT Took it. But @RLWA32 's workaround works fine. Do I still need to look into this?

Yes. The proposition of @RLWA32 is not acceptable. Please, solve this problem.
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:12:39.6666667+00:00

David Lowndes, RLWA32 - These are not answers.
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-09T06:27:05.88+00:00

@Mikola Akbal̆ I reproduced and will consult this next Monday.

Answer 1

After discussing, it’s better to use with specific threads instead of all threads(global). There is no evidence that WH_KEYBOARD has an issue. If the issue has a big impact on you, please open an incident.

As this issue is complex, please open an incident via 'Contact us' tab at link below so that our engineer can work with you closely: https://developer.microsoft.com/en-us/windows/support/ and please choose the 'Technical Support - Coding/Debugging' for Windows SDK for this issue.

In-addition, if the support engineer determines that the issue is the result of a bug the service request will be a no-charge case and you won't be charged.

Answer 2

RLWA32 49,666

You may have better success using a WH_GETMESSAGE hook to handle WM_KEYDOWN and WM_KEYUP. This hook is allowed to change the message it is passed so you can set it to WM_NULL to prevent subsequent processing of the keyboard input. In my tests both 32-bit and 64-bit hooks were handled in the context of a hooked process of like bitness. Neither hook was called in the context of the installing thread.

Mikola Akbal̆ 75 Reputation points

2023-03-06T23:20:03.0266667+00:00

Yes, this solves my problem. But, I think, Microsoft should repair WH_KEYBOARD.
Mikola Akbal̆ 75 Reputation points

2023-03-07T14:09:34.5566667+00:00

You may have better success using a WH_GETMESSAGE

Oh, I understood. It's make for us more work. :) Please, solve problem with WH_GETMESSAGE by your forces. Because this hook disappears :) . I don't reproduce conditions because nobody pays me for it.

Good idea: can Microsoft give me project work? I mean, certain conditions: I solve this exact problem, it costs some amount of dollars. I have talent of researcher.
RLWA32 49,666 Reputation points

2023-03-07T17:03:05.0066667+00:00

What do you mean by "this hook disappears"? Was your DLL unloaded? Only low level keyboard and mouse hooks are documented as being silently removed by the system if they time out.
Mikola Akbal̆ 75 Reputation points

2023-03-08T07:56:31.4+00:00

You may have better success using a WH_GETMESSAGE

Oh, I understood. It's make for us more work. :) Please, solve problem WH_GETMESSAGE by your forces. Because this hook disappears :) . I don't reproduce conditions because nobody pays me for it.

Good idea: can Microsoft give me project work? I mean, certain conditions: I solve this exact problem, it costs some amount of dollars.
Mikola Akbal̆ 75 Reputation points

2023-03-08T08:01:27.5366667+00:00

What do you mean by "this hook disappears"? Was your DLL unloaded?

I did not ivestigate that. I decided to return to WH_KEYBOARD. It works with additional algorithm of switching bitness, but it already works. It seems hooks have a lot of bugs. I have no time to investigate all of them.

What I saw. WH_GETMESSAGE worked correctly - with both bitnesses installed. But at some moment activating of keyboard layout stopped. That's all information what I have. I understood that windows hooks have a lot of problems, and decided to return to variant that works.

So, your proposition doesn't solve. I can not accept it as answer, because I can not use it. I don't need another hook that works with another problem that I have to spend time to investigate new problem too.

Answer 3

Mikola Akbal̆ 75

At the moment, there is no another solution that I found by myself. WH_KEYBOARD, really, doesn't work with both bitnesses simultaneously. Microsoft, please, solve this problem.

The solution is switching of bitnesses as described in discussing. For example, it can be monitoring of foreground window. When you know bitness of this process, you unhook one bitness and hook another. That works.

Mikola Akbal̆ 75 Reputation points

2023-03-09T09:02:56.8033333+00:00

The community doesn't want covinient keyboard. Okay, I do it for myself. Repair the problem.
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-03-27T08:13:00.5266667+00:00

@Mikola Akbal̆ I have escalated the thread.
Mikola Akbal̆ 75 Reputation points

2023-04-05T01:28:48.0433333+00:00

@Xiaopo Yang - MSFT Please, see the related discussion: https://learn.microsoft.com/en-us/answers/questions/1187595/setwindowshookex(wh-keyboard)-doesnt-work-with-exp
It seems, Windows became worth during the time of my absence among developers :)
Xiaopo Yang - MSFT 12,731 Reputation points Microsoft External Staff

2023-04-06T07:48:05.2833333+00:00

I haven't heard from the engineer after escalating. @Mikola Akbal̆ , It's not supported and not recommended to break down explorer.exe.
Mikola Akbal̆ 75 Reputation points

2023-04-16T21:55:15.3466667+00:00

@Xiaopo Yang - MSFT It's not supported and not recommended to break down explorer.exe.

Did I break down explorer.exe? O_O I wanted only convenience.

Share via

SetWindowsHookEx(WH_KEYBOARD) - 64-bit and 32-bit hooks don't work simultaneously

2 additional answers

Your answer