I'm having an issue with the keyboard logger. Every system tested until today is working fine, except a Windows 7 Embedded Standard 32 bit that apparently freaks out with the current build.
What I need to do is record keystrokes entered from the keyboard, until I get a certain number of them. When I do, I call a certain procedure.
I have a hook defined like this:
SetWindowsHookEx(WH_KEYBOARD_LL, keyboardProcedure, GetModuleHandle(NULL), 0);
and a keyboardProcedure callback:
LRESULT CALLBACK SystemKeyboardReadWrite::keyboardProcedure(int nCode, WPARAM wParam, LPARAM lParam)
{
...
}
I'm using Qt 5.2 for this application.
So, in more depth, the problem occurs when you enter the keys too fast or hold a certain key for a longer period of time, which will force the keyboard to send multiple keyboard events. When that happens, the hook will freeze and not send any more events to the callback. (not the entire application, the app will still continue running with the exception of the keylogger)
This problem occurs only on this OS, on no other Windows 7 OS, or Windows XP have I noticed the issue. I have 2 computers with the same setup and they both show the same problem, also I'm developing the app on a Windows 7 professional and it also seems fine.
I'm wondering if this is an issue with my application, or is it something outside of my control.
Thanks everyone for their help.
I don't know Windows Embedded, but I am familiar with Windows 7 and the LowLevel Hooks, both mouse and keyboard.
The symptom of getting kicked off the hook list can be reduced/modified with the LowLevelHooksTimeOut registry value. You have to reboot the system after it is modified. Basically that value says the number of milliseconds that hooks have to interact with the keys.
If you writing your file from inside the hook method, too, that could be the exact time when it times out, too.
For example, you get 100 key strokes, then you write it to a file. If they are holding down the keys across 100 to 101+, and you are taking longer than the maximum time with the hook, then Windows will blacklist your hook call back and kick you off the list of hooks.
The default time on Windows 7 (desktop) is 200 ms, I think. For embedded I wouldn't be surprised if it is less. Also when multiple programs are all hooking the keyboard, it can affect the timing of how long your hook is allowed to access it.
I also have only really used hooks that are established in a dll, and hold onto a global HHOOK handle. Watching all the return codes of your functions may also shed some light onto the situation.
More info on LowLevelHooksTimeout:
Low level Keyboard Hook works on one on Windows 7 x64 and not another
Related
I am writing an application that needs to temporarily disable the Play/Pause button that appears on multimedia keyboards.
Normally, a key can be blocked quite easily by installing a low level keyboard hook (WH_KEYBOARD_LL) where the KeyboardProc intercepts the key (in this case VK_MEDIA_PLAY_PAUSE) and returns 1 instead of calling CallNextHookEx. I have tried this with other keys (including the Windows key VK_LWIN) and this works perfectly. I also have no problems with this method under Windows 7 where all keys, including VK_MEDIA_PLAY_PAUSE get blocked.
Windows 8 is a different story. When my application has input focus, everything works as expected, meaning the VK_MEDIA_PLAY_PAUSE key gets blocked and no other application responds to it. However, when my application loses focus, my hook procedure gets called (this was verified by sending out a OutputDebugString) but other applications respond to key even though I return 1. As soon as my app gets focus again, everything is block as it should.
After some investigation, I found that the multimedia keys not only generate keystrokes but also generate WM_APPCOMMAND messages so I added ShellProc (WH_SHELL) hook with the following hook procedure:
LRESULT __declspec(dllexport)__stdcall CALLBACK ShellProc(int nCode,WPARAM wParam,LPARAM lParam)
{
// Do we have to handle this message?
if (nCode == HSHELL_APPCOMMAND)
{
OutputDebugStringX(">>>>> HSHELL_APPCOMMAND");
// Process the hook if the hNotifyWnd window handle is valid
short AppCommand = GET_APPCOMMAND_LPARAM(lParam);
switch (AppCommand)
{
case APPCOMMAND_MEDIA_NEXTTRACK:
case APPCOMMAND_MEDIA_PLAY_PAUSE:
case APPCOMMAND_MEDIA_PREVIOUSTRACK:
case APPCOMMAND_MEDIA_STOP:
OutputDebugString(">>>>>ShellProc got a media command");
return 1;
}
}
// Call the next handler in the chain
return CallNextHookEx (hsh, nCode, wParam, lParam);
}
This procedure is only getting called when my app has input focus. Whenever I have input focus and return 1 the Play/Pause command gets blocked. As soon as I lose focus the procedure does not get called/hooked.
Anyone have any idea as to what is going on? As I have mentioned, the code works for other keys, just not the multimedia keys. Everything works fine in Windows 7.
Alternatively, can anyone suggest another way of blocking the multimedia keyboards Play/Pause button?
From the MSDN documentation for ShellProc:
HSHELL_APPCOMMAND: The user completed an input event (for example, pressed an application command button on the mouse or an application command key on the keyboard), and the application did not handle the WM_APPCOMMAND message generated by that input. [Emphasis added.]
The emphasized portion suggests that your hook callback only gets called after an application ignores the WM_APPCOMMAND. In other words, you're too late.
To catch the message in flight, I think you need a different type of hook. Perhaps WH_GETMESSAGE or WH_CALLWNDPROC.
But why are you trying to prevent the users from interacting with their applications as they choose?
I've been working on an input event system.
I mapped all the keys on my own keyboard, the scancodes and so on, including both windows keys.
When I press them, the program successfully receives the distinct keydown events for them without any trouble.
When I release the keys, however, the Start Menu pops up, obscuring the program in windows mode, or even minimizing it in fullscreen.
So my problem lies in suppressing that.
Arma 2, a Military Simulator/Game allows commands to be mapped on those keys without any trouble.
Where do I have to catch that event?
Can I do it for my own window as long as it has focus?
Am I going to be stuck with a disabled win-key as long as it is running?
Or something else?
Googling it was mainly fruitless due to Windows key also referring to the product key, and when I did find something, it usually flat out disabled the whole button.
I just want to suppress the popup.
Edit:
I tried
case WM_SYSCOMMAND:
switch(wParam)
{
case SC_TASKLIST:
return 0;
default:
break;
}
But that gave me very odd results.
If I spammed the winkeys and only the winkeys, it seemed to work, as soon as I moved the mouse while doing so, it didn't, the start menu would pop up again.
Edit:
I also tried hooks, but on win7 they get removed if the callback takes too much time, which can happen when large data is loaded, so they suggest a dedicated thread for it, but I think that's overkill for just one key that needs handled.
I just want to know where the Start Menu gets called. My own program? The system?
This is so friggin annoying, I am contemplating trying to reach the people from Bohemia Interactive and ask them how they did it.
Just this one key, sheesh Microsoft...even with "Super key/superkey" search terms, I usually only get flat out disabling methods, from registry changes to third party background programs.
Bah!
This artcile was relating to C# but may point you in the right direction;
From MSDN:
A global hook monitors messages for all threads in the same desktop as
the calling thread. A thread-specific hook monitors messages for only
an individual thread. 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. A thread-specific
hook procedure is called only in the context of the associated thread.
This was the most helpful link in order to answer the question in the above article
The Raw Input API should solve your problem.
http://msdn.microsoft.com/en-us/library/ms645543.aspx
When my WTL C++ application is activated or gets the keyboard focus I need to determine the window handle of the application that was previously activated/had focus. However, the window handles (LPARAM) of both the WM_SETFOCUS and WM_ACTIVATE messages are both NULL (XP, 32 bit).
How can I determine the application that just lost focus when my application is activated? Is there a simple way to do this or will I need to roll a special CBT hook?
An easy way to see exactly what messages are being sent and what their parameters are is to fire up Spy++ and set it to Log Messages while you Alt+Tab to another window.
Consistent with what you've discovered, the lParam for both WM_SETFOCUS and WM_ACTIVATE will be NULL when the previously active window (or the window being active) is not in the same thread.
You might have more luck with WM_ACTIVATEAPP, as David suggested. Once you get the thread identifier, you can try calling the GetGUIThreadInfo function to determine the active window for that thread. This function will work even if the active window is not owned by the calling process.
If your app is anything other than a small utility that the user is not expected to keep open and running for very long, I would shy away from using a CBT hook if at all possible, given the potential performance implications. Unfortunately, interaction like this across process boundaries is difficult.
If you're not afraid of using things that may break with future versions of Windows, you could investigate the RegisterShellHookWindow function. I can't tell you much about it, having never used it myself, but it's an easier way to get the shell messages you would otherwise only receive by installing a hook.
It was around as far back as Windows 2000, but wasn't included in the SDK until XP SP1. It still exists in Windows Vista and 7, as far as I can tell.
Short version:
How can I receive input messages in Windows with C++/C when the window is not active?
Background information:
I'm currently working on an Input System that should not depend on any window, so it can e.g. be used in the console as well.
My idea is to create an invisible window only receiving messages, which is possible using HWND_MESSAGE as hWndParent. It only receives input messages when it's active though, and I don't want this. It should always receive input (unless the application requests it no longer does so, e.g. because it lost focus).
I know this is possible somehow, many applications support global shortcuts (e.g. media players (playback control) or instant messengers (opening the contact list)), I just don't know how. Do you know?
Options:
RegisterHotKey if you need to register just one or a few hotkeys
SetWindowsHookEx with WH_KEYBOARD / WH_KEYBOARD_LL. Use when you need to filter many or all keyboard events. However, the hook code needs to be implemented in a DLL (which is loaded into other processes). You need separate 32 bit and 64 bit versions of the DLL
You need to setup windows keyboard input hook. Here is an example how to do it; it is even easier to do in C++
I'm trying to find a way to detect when focus is changed to another window (without having to poll every X ms).
I've already figured out a way to detect when focus is switched between applications using WH_SHELL and HSHELL_ACTIVATESHELLWINDOW.
The problem is I want to detect when focus is switched between dialog/windows within the same app.
ie. In Notepad, I can determine when the app switches to Notepad, but I cannot detect when the "Open" or "Save" dialogs appear because the focus is still within the same application.
You can use SetWindowsHookEx with a WH_CBT hook type. If you just want to detect focus changes within an application, pass GetCurrentThreadId() as the last parameter, otherwise the hook will be for all threads on the current desktop.
Note that using windows hooks can have an adverse effect on system performance, so the hook should only be installed when necessary and you should do a minimum amount of work in the hook procedure.
Sorry for the delay, I don't have VS installed on this computer so it's a bit hard to find the code.
Use this to hook your code into the system.
HHOOK oldShellHook = SetWindowsHookEx(WH_SHELL, BCK_WndShellProc, hDll, NULL);
if (!info->oldShellHook) {
MessageBox(m_hwnd, L"Failed to load global hook.", strTitle, MB_OK | MB_ICONERROR);
return;
}
And this your hook. Depending on what you're doing, use nMsg to figure out when you want to apply your custom logic.
LRESULT CALLBACK BCK_WndShellProc(int nMsg, WPARAM wParam, LPARAM lParam) {
...
}
Read the MSDN docs for SetWindowsHookEx() to make sure you return the expected values, otherwise you can lock up the whole system.
I use code similar to this on my Breadcrumb Killer and Spasm (Show all programs on Start menu) programs and it seems to work fine.
How about the "Computer Based Training API"; SetWindowsHookEx with WH_CBT which will enable you to receive HCBT_SETFOCUS (among others)