Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jnativehook doesn't capture keyboard events while working inside a VM #30

Closed
gce84 opened this issue Dec 16, 2014 · 36 comments
Closed

jnativehook doesn't capture keyboard events while working inside a VM #30

gce84 opened this issue Dec 16, 2014 · 36 comments
Labels

Comments

@gce84
Copy link

gce84 commented Dec 16, 2014

JNativeHook doesn't catch keystrokes when working inside a virtual machine (in full-screen and windowed mode either).
In 1.2.0-RC4 demo it logs "keyCode=69 keyText=Num Lock" when switching between VM and local desktop.

Checked with VMware Horizon View Client and JNativeHook 1.1.4 and 1.2.0-RC4.
Probably related to https://code.google.com/p/jnativehook/issues/detail?id=35

@kwhat kwhat added the bug label Dec 16, 2014
@kwhat
Copy link
Owner

kwhat commented Dec 16, 2014

I suspect it is grabbing the keyboard at a lower level than the Windows API provides with SetWindowsHookEx(). I am not sure how to confirm that, or if this is something that can even be fixed.

@gce84
Copy link
Author

gce84 commented Dec 16, 2014

I see. Thanks!

Update:
I've set my java application to re-register native hook while I was waiting inside VM window (GlobalScreen.unregisterNativeHook() / GlobalScreen.registerNativeHook()) and after that it begun capturing keystrokes normally.

@kwhat
Copy link
Owner

kwhat commented Dec 16, 2014

Awesome, thanks for that update. I suspected that may work in google code bug 35. Now I just need to figure out how to reliably detect that type of application programmatically. If you do find more info, please post here.

@kwhat
Copy link
Owner

kwhat commented Dec 17, 2014

I had some extra time today so I looked into this further. I think it maybe possible using SetWinEventHook() and a couple of different techniques. I am going to hack together a test and see if it seems to work. Will you be able to test something in a couple days?

@gce84
Copy link
Author

gce84 commented Dec 18, 2014

Yes, sure.

Sorry for the late reply!

@gce84
Copy link
Author

gce84 commented Dec 20, 2014

Update:

Same behavior for full-screen RDP. However keystroke tracking seems to work fine with windowed mode RDP, no need to re-register hook.

@kwhat
Copy link
Owner

kwhat commented Dec 22, 2014

Alright, I finally had a few min to hack this together. Try this jar on a Windows 64-bit computer and see if it restarts the hook and if it works after restart. It should take about 60 seconds and then start working again. I'll tune the performance if later if it works. Please note that it will not work on 32bit Windows.

@gce84
Copy link
Author

gce84 commented Dec 22, 2014

I've checked the jar, but it didn't work completely as expected.

First I've launched NativeHookDemo, switched to VM window and tried to make some keystrokes. As previously, keyboard events were not tracked (mouse clicks were logged fine). Then I've tried to wait inside a VM window for restart, but nothing changed. I was waiting for at least 4 minutes.

However, I've noticed that keystrokes are tracked fine when I manage to set focus to VM window BEFORE NativeHookDemo logs this:
SEVERE: hook_run [697]: SetWindowsHookEx() successful.

If I switch to another window and then back to VM, NativeHookDemo logs this:
WARNING: Recieved Event: 0X9 at 158092656 <> 158092656
and then stops tracking keystrokes.

Also there were these records in the log:
WARNING: ****Timer Expired!!!!
but it seems that they did not follow any time interval and I was not able to get any while waiting inside VM window.

@kwhat
Copy link
Owner

kwhat commented Dec 22, 2014

Thanks for testing! I have pushed a branch with my hacks to the libuiohook project in case you want to experiment.

So what should happen is when you get a "WARNING: Recieved Event: 0X9 at ######## <> ########" I have a timer start with a 60 second wait. If an input event occurs, mouse or keyboard, the timer is killed and will never fire. If no event is received, you will see the "WARNING: ****Timer Expired!!!!" and the hook will be re-installed and you will see "SEVERE: hook_run [697]: SetWindowsHookEx() successful." Dont worry about "SEVERE: hook_run [697]: SetWindowsHookEx() successful." That was just a test message to make sure the hook started and I saw the message.

Now, what you are describing with the keyboard hook stops working in the vm but the mouse still does means the time was killed so the hook never reset. There are a couple of tweaks I want to test so probably 2 more jars. Thanks again for working though this!

@kwhat
Copy link
Owner

kwhat commented Dec 22, 2014

Alright, I replaced the jar @ http://public.callutheran.edu/~abarker/JNativeHook/JNativeHook.jar with a new one. This has 2 times 1 for the keyboard and 1 for the mouse. Please test and let me know what kind of results you get. The timeout is 1 second so you shouldn't have to wait long.

@gce84
Copy link
Author

gce84 commented Dec 23, 2014

Thanks for the update!

I've downloaded the jar and NativeHookDemo seems to work fine, except for one case:

  1. VM window is minimized
  2. Try to maximize it and set focus on it

However, if I set focus to another window and then back to VM window (either windowed or full-screen mode) it starts to log keystrokes normally. So the only issue I've found so far is when VM window is minimized.

Update: key tracking stops when switching between full-screen and windowed mode in VM window.

@kwhat
Copy link
Owner

kwhat commented Dec 23, 2014

Did you switch to a 32 bit VM?

@kwhat
Copy link
Owner

kwhat commented Dec 23, 2014

Oh sorry I was on my phone in the wrong spot. OK awesome, I think we can listen for minimize events. I'll post a new jat soon.

@gce84
Copy link
Author

gce84 commented Dec 23, 2014

Yes, I used 32 bit java in the first place, sorry!

@kwhat
Copy link
Owner

kwhat commented Dec 25, 2014

Is there anytime it stops logging mouse input? If so, can you provide console output with notes about where it stops and starts again. If it never stops I think we have a winner.

@gce84
Copy link
Author

gce84 commented Dec 25, 2014

No, mouse tracking was just fine all the time.

The only issue remaining with the last update which I've tested is when VM window is minimized / switched between full-screen and windowed modes.

@kwhat
Copy link
Owner

kwhat commented Dec 25, 2014

I uploaded a new jar to the same location. Give it a test and let me know. Thanks again for all of this testing and have a happy holiday!

@gce84
Copy link
Author

gce84 commented Dec 25, 2014

I've tested it, but, comparing to the previous jar, it doesn't track keystrokes inside VM again (it seems that it doesn't re-SetWindowsHook like in the previous patch).

Thanks and have a great holidays too!

@kwhat
Copy link
Owner

kwhat commented Dec 25, 2014

I just tweaked the jar and re-uploaded to the same url. It should reload both the mouse and keyboard on the two listeners. Lets see if that works.

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

I've check the new one, but it still doesn't capture keyboard activity (mouse clicks are fine like all the time).

Last .jar that worked fine (except minimize/resize issue) was downloaded on 12/23/2014.

@kwhat
Copy link
Owner

kwhat commented Dec 26, 2014

Ok I have attached a new build that goes back to the original almost working version. This build will not fix any issue but on the command line you should see something like "SEVERE: win_hook_event_proc [656]: * Testing window event: 0X#####" followed by a possible "* Keyboard Restart" or "*** Mouse Restart" message within 3 seconds if no global input of the relevant type was was received. Hopefully this will give me a good indicator of when I should restart each hook.

Could you please run though the use cases where the hook could stop working and note the console log for the action? For example, if you maximize the app and hit a letter but doesn't register with JNativeHook, grab the window event hex value(s) you receive and note if the keyboard and/or the mouse hook restarted. Just make sure you give the new window both types of input during that 3 second pause. You should end up with some combination of the following.

# On Maximize, 
win_hook_event_proc [660]: *** Testing window event: 0X8.
win_hook_event_proc [660]: *** Testing window event: 0X9.
keyboard_timer_proc [596]: *** Keyboard Restart.
mouse_timer_proc [625]: *** Mouse Restart.

Thanks again for doing all of this testing. I don't have a Windows box or the vmware software so this is a tremendous help!

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

First I've tested the .jar locally, without VM window. Here are the results:

I've clicked mouse button - got keyboard and mouse restart

Dec 26, 2014 10:11:51 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 3519, 210.

Dec 26, 2014 10:11:51 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 3519, 210.

Dec 26, 2014 10:11:51 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 3519, 211.

Dec 26, 2014 10:11:55 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 26, 2014 10:11:55 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_pressed [348]: Button 0  pressed 1 time(s). (3519, 211)

Dec 26, 2014 10:11:55 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X8.

Dec 26, 2014 10:11:56 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [370]: Button 1 released 1 time(s). (3519, 211)

Dec 26, 2014 10:11:56 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [393]: Button 1 clicked 1 time(s). (3519, 211)

Dec 26, 2014 10:11:56 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X9.

Dec 26, 2014 10:12:00 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: keyboard_timer_proc [596]: *** Keyboard Restart.

Dec 26, 2014 10:12:01 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: mouse_timer_proc [625]: *** Mouse Restart.

Then I've pressed key after previous keyboard and mouse restart - got NO restarts at all

Dec 26, 2014 10:12:08 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_pressed [208]: Key 0XE04D pressed. (0X27)

Dec 26, 2014 10:12:08 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: keycode_to_unicode [651]: Using keyboard layout 0X0000000004090409.

Dec 26, 2014 10:12:08 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_released [264]: Key 0XE04D released. (0X27)

And last I've clicked mouse then immediately pressed a key (before restarts) - got mouse restart only

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_pressed [348]: Button 57421  pressed 1 time(s). (3519, 211)

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X8.

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [370]: Button 1 released 1 time(s). (3519, 211)

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [393]: Button 1 clicked 1 time(s). (3519, 211)

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X9.

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_pressed [208]: Key 0XE04D pressed. (0X27)

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: keycode_to_unicode [651]: Using keyboard layout 0X0000000004090409.

Dec 26, 2014 10:12:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_released [264]: Key 0XE04D released. (0X27)

Dec 26, 2014 10:12:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: mouse_timer_proc [625]: *** Mouse Restart.

Dec 26, 2014 10:12:35 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 26, 2014 10:12:35 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 3519, 210.

After that I've tested it with VM window and here is what I've got:

  1. There are NO keyboard and mouse restarts after a mouse click when inside a VM window.
  2. Nevertheless, if there was a keyboard restart outside VM window (after local mouse click) keystrokes tracking works perfectly
  3. Having keystroke tracking working normally inside VM window and then just moving a mouse cursor outside VM window and back makes tracking stop (I've got two-monitor configuration, one is for full-screen VM, other is for local Windows)
    As keyboard restart doesn't take place, as mentioned in section 1, tracking does not resume after mouse clicks inside a VM window.
    But if I make a mouse click on any local area and get a keyboard restart (after no activity timeout), key tracking begins working normally inside VM window again.

Glad if I can help!
It is you are the one to thank for your efforts!

@kwhat
Copy link
Owner

kwhat commented Dec 26, 2014

3. Having keystroke tracking working normally inside VM window and then just moving a mouse cursor outside VM window and back makes tracking stop (I've got two-monitor configuration, one is for full-screen VM, other is for local Windows)

Do you get any "*** Testing window event: " in that situation? It seems like some of the events I was expecting are not actually fired which explains a lot. I have uploaded a nearly identical jar with a much wider range of events to consider. See if the above situation gives you some new testing window event data. It seems like event 0X09 will get us 90% of the way there, I just need to get that mouse enter event when in full screen mode.

File is in the same spot ;)

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

Got it :)

Update:
Keyboard restarts inside a VM window, but only once - when the first click happens when I active a VM window. Here are the steps:

  1. I press some random keys/click mouse locally, get restarts
  2. then I click inside a VM window and get a mouse click event in the logs
  3. if I press some keys inside a VM window before the idle timeout expires, they are not tracked
  4. I continue to randomly press keys
  5. after timeout expires (as I suppose) I see a 'keyboard restart' event and after that key logging begins.

Again, in case if mouse cursor moved out of VM window and then again back in, keystroke tracking is stopped and needs a mouse click outside VM.

Thing to mention that mouse click inside VM restarts keyboard only (without mouse like on local machine).

@kwhat
Copy link
Owner

kwhat commented Dec 26, 2014

Again, in case if mouse cursor moved out of VM window and then again back in, keystroke tracking is stopped and needs a mouse click outside VM.

No new "*** Testing window event: 0x####" events when the mouse moves between? That's not a good sign ;(

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

If I continue to click mouse button inside VM window after tracking was stopped (because of lost focus) it doesn't lead to keyboard restart. Only first click for window activation is successful. Then it needs to get outside the window.

@kwhat
Copy link
Owner

kwhat commented Dec 26, 2014

Are you on IRC? Freenode.net #jativehook

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

Actually there is such event after the mouse click (activation of VM window):

Dec 27, 2014 12:14:44 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [370]: Button 1 released 1 time(s). (2648, 737)

Dec 27, 2014 12:14:44 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [393]: Button 1 clicked 1 time(s). (2648, 737)

Dec 27, 2014 12:14:44 AM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X9.

Dec 27, 2014 12:14:46 AM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: keyboard_timer_proc [596]: *** Keyboard Restart.

Dec 27, 2014 12:14:49 AM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: mouse_timer_proc [625]: *** Mouse Restart.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2647, 737.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2644, 741.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2639, 748.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2631, 757.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2622, 768.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2608, 786.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2598, 804.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2577, 830.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2560, 851.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2543, 876.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2525, 892.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2510, 905.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2502, 911.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2499, 912.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2497, 912.

Dec 27, 2014 12:14:50 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_mouse_moved [434]: Mouse moved to 2496, 912.

Dec 27, 2014 12:14:52 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: hook_get_multi_click_time [138]: GetDoubleClickTime: 550.

Dec 27, 2014 12:14:52 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_pressed [348]: Button 0  pressed 1 time(s). (2496, 912)

Dec 27, 2014 12:14:52 AM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [660]: *** Testing window event: 0X8005.

Dec 27, 2014 12:14:52 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [370]: Button 1 released 1 time(s). (2496, 912)

Dec 27, 2014 12:14:52 AM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_button_released [393]: Button 1 clicked 1 time(s). (2496, 912)

Dec 27, 2014 12:14:57 AM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: keyboard_timer_proc [596]: *** Keyboard Restart.

@gce84
Copy link
Author

gce84 commented Dec 26, 2014

Sorry, not on IRC. Might be available on Skype or Hangouts.

@kwhat
Copy link
Owner

kwhat commented Dec 26, 2014

So here is a little background of how I am trying to "solve" this problem. The Windows API doesn't provide any kind of notification that a hook was moved, or disabled, or unhooked so I have tapped into the Window event loop to try and figure out if I can restart the hook manually on a particular window event. Thats what those "*** Testing window event: 0X9" messages are. If I cant find a event that happens when the mouse moves out of that window, there is no way I can know when to restart the hook.

This jar listens for every event except 3 of the most common events and restarts on EVENT_OBJECT_FOCUS, EVENT_SYSTEM_CAPTUREEND and EVENT_OBJECT_NAMECHANGE. This one might work if we are lucky. If it doesn't see if there is a useful *** Testing window event: near when the events stop working. Note it will say *** Queuing Restart on window event: when it is considering a hook restart. The only way that gets canceled is if it got another event on the hook.

I am on hangouts as well, under my email. It will probably be easier than using the msg board.

Just put up a new jar at the same location.

@gce84
Copy link
Author

gce84 commented Dec 28, 2014

I've checked the latest jar and finally it works fine!

I've checked the events in the logs and it appears that the needed event is EVENT_OBJECT_NAMECHANGE 0x800C

Keystrokes were captured normally after approximately a second when mouse pointer was moved back and forth from VM window. Also worked for minimizing and full-screen/windowed modes switching.

Here is the part of logs when I moved mouse pointer inside VM window:

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X11E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [664]: *** Queuing Restart on window event: 0X800C.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [664]: *** Queuing Restart on window event: 0X800C.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X11E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X11E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: keyboard_timer_proc [596]: *** Keyboard Restart.

Dec 28, 2014 1:31:23 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

I've checked the NativeHookDemo also and it works fine too.

Also, logs were constantly updated with lots of these messages,

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X11E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X11E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

Dec 28, 2014 12:57:25 PM org.jnativehook.GlobalScreen$NativeHookThread enable
SEVERE: win_hook_event_proc [683]: *** Testing window event: 0X800E.

even if there was no activity at all.

@kwhat
Copy link
Owner

kwhat commented Dec 30, 2014

Awesome! I have put together 1 last test that removes the delay and all of the extra events. The jar is at the same location for download. It seems like the windows hook restart is really quick but lookout for any input lag or cpu spikes. Let me know how it works out, if everything goes well Ill merge it into the trunk. Thanks again for all the testing!

@antogerva
Copy link

Greetings,
I keep getting this error:
hook_thread_proc [97]: SetWindowsHookEx() failed! (0X7E)

I believe this happen if I use the code provided in JNativeHook v1.2.0-RC4(NativeHookDemo) too many time where I execute GlobalScreen.registerNativeHook() without calling GlobalScreen.unregisterNativeHook().

So far, the only way to fix this problem on windows is to reboot, but I'm sure there's a background process that could be killed to fix the issue... any idea? Thought, I didn't try this link yet...

@kwhat
Copy link
Owner

kwhat commented Dec 31, 2014

I think this goes back to a very old bug that just doesn't seem to want to go away. Calling GlobalScreen.registerNativeHook() multiple times on a running hook should just result in checking the ishookrunning function and returning. Have you tried creating a small test program to check if you can reproduce the problem reliably? Try using verbose logging and see if anything useful pops up.

This wouldn't happen to occur after running the java debugger while the hook is attached, would it? Maybe after starting the debugger 20 or 30 times? Its possible that your debugger (::cough::couch:: eclipse?) is pausing code execution on the hook, causing Windows to scold your application by dropping the hook. I don't know what happens when the hook is dropped but I do know it happens in Windows 7+. There is some spotty documentation on the subject but nothing that has gotten me so far as duplicating the problem. If the hook is being dropped, you may notice symptoms while debugging like when execution is paused for 5 min at a break point, and when you resume the hook stopped working causing you to reg-register it? I haven't done extensive testing on the library in a java debugger so I have no idea what will happen when you attach a Java debugger to a low level system hook ;)

The link you mentioned isn't going to fix the problem, but it may prevent you form noticing it in some situations like what I outlined above. Its still going to start complaining about 0X7E except now may start complaining about it after the hook was already registered.

@gce84
Copy link
Author

gce84 commented Jan 1, 2015

I've tested the latest jar and it works just fine! I wasn't able to notice any significant delay, keystroke tracking works immediately (previous jar had a ~1 second delay). So I think the issue might be considered as closed.

Many thanks for your efforts!

@kwhat
Copy link
Owner

kwhat commented Jan 1, 2015

Perfect, I'll merge it today and hopefully ill have a new RC up shortly and thanks for all you help testing. @antogerva If you discover how to reproduce the bug, please open a new report. If it is related to debugging, I maybe able to detect something in the native code to pause the hook while the debugger is attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants