I have an application I've written that needs to block certain key input. I use a WH_KEYBOARD_LL global key hook to do this. Recently I discovered that it no longer blocks key input for DInput in Vista or Win7. I'm interested if anyone knows what has changed in DInput for the global keyhook not to block key input anymore. It is quite often suggested on these forums (especially by Evil Steve) to use Windows messages for keyboard input instead. While I have always agreed with him it does raise an interesting question about DInput for Vista/Win7 in that something about it's method of reading input has changed. To quote Evil Steve; "(DInput) creates a seperate thread to just read data from the keyboard using raw input". But when my app is running on Vista/Win 7 it *can* block standard Raw Input key readings but *not* DInput key reads. On XP it blocks both. So it seems something about the way it's reading keyboard has changed. BTW This doesn't appear to be a UAC issue as I've tried running the app as Administrator as well as turning off UAC.

I have created a set of binaries to prove that there is some sort of bug in Vista / Win7 relating to WH_KEYBOARD_LL global key hook. The bug seems to only effect DInput7 and not DInput8. I have not tested other versions of DInput.

You can download my test applications @ DInputBlockTest.zip

Inside Vista/Windows 7:

1. Launch DInput7.exe and DInput8.exe
2. Press the SPACE bar and you will see the apps output that you pressed SPACE to the console
3. Now launch KeyHook.exe
4. Press the SPACE bar and you will see the space key is now blocked in both DInput7.exe and DInput8.exe

Now close everything by pressing ESC

1. This time launch KeyHook.exe first
2. Now launch DInput7.exe and DInput8.exe
3. Press the SPACE bar and notice that only DInput8.exe's keys are being blocked

Here is a screenshot showing how DInput7.exe does not have it's keys blocked.



You can run these apps in either order on XP and the key hook will always block the input. So I guess the question is, how can I have my global key hook running before a DInput7 app launches and still block it's input?

In the archive I posted is a console app called RawInput.exe that shows that WH_KEYBOARD_LL does indeed block Raw Input / WM_INPUT messages.

The mystery here is why it doesn't block DInput7 keyboard input in Win7/Vista while it does for DInput8.

The WH_GETMESSAGE does look interesting though..

I noticed your edit, and you're right it doesn't explain the reason why it works differently in XP.

If you look at dinput.dll in a hex editor you can see the API function "GetRawInputData" referenced in it. So the mystery continues?

Thanks adeyblue that is really helpful. If you have any ideas on a workaround for this I'm all ears. Incidently how did you discover that info?

According to MSDN:

Quote:The SetWindowsHookEx function always installs a hook procedure at the beginning of a hook chain.

So dinput.dll is using a hook instead of Raw Input because of a version issue and this hook is created at the top of the hook chain and thus prevents my app from blocking keys. So the question now is; is it possible to always stay at the beginning of a hook chain?

I found an interesting compatibility app called the IgnoreAltTab Fix

Quote:This fix works by calling the SetWindowHookEx(WH_KEYBOARD_LL, ...) function to install a low-level keyboard hook, which then implements a LowLevelKeyboardProc function to handle key presses and filter out the following key combinations:

Now the interesting part:

Quote:This fix attempts to stay at the end of the hook chain by hooking as early as possible and by allowing previous keyboard hooks to attempt to process the keyboard events before the fix processes them out.

Unfortunately it's doing the opposite of what I want, and that is to stay at the top of the hook chain. This program attempts to stay at the end of the hook chain which would naturally occur if you install the hook "as early as possible".

Quote:The IgnoreAltTab compatibility fix intercepts the RegisterRawInputDevices API, which causes the call to fail with an ERROR_INVALID_PARAMETER code and prevents the delivery of the WM_INPUT messages. This delivery failure forces the included hooks to be ignored and forces DInput to use Windows-specific hooks.

This is also interesting, and proves that DInput will fall back on using a keyboard hook if RegisterRawInputDevices fails. I'm not sure why they would do this for this particular app though, because in my experience Raw Input reading is easier to block using WH_KEYBOARD_LL than a global hook is. If they are forcing DInput to use hooks then how are they staying at the beginning of the hook chain to block the key presses?

[Edited by - Headkaze on October 15, 2009 7:41:33 AM]