search

devshift / jnativehook

Automatically exported from code.google.com/p/jnativehook
0 stars 0 forks source link

Stops catching events when multiple open #43

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
Can't seem to reproduce when trying to but continues to happen when I am 
testing a program

But my process for testing this program right now is

1. change some code
2. export as executable jar
3. run to test
4. after maybe 20 - 30 minutes keys stop being caught

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
1.1.4
Windows 7

Please provide any additional information below.

Saw the issue before for another version and used the temporary solution of 
logging off/restarting computer

When this occurs I have run the JNativehook jar as well and instead of showing 
all actions no actions come up

http://imgur.com/fhgPwSF

If anything else would help ask I will try to provide the information

Original issue reported on code.google.com by Killma...@gmail.com on 28 Apr 2013 at 2:30

GoogleCodeExporter commented 9 years ago 
Not sure how to edit but forgot to change title after trying multiple of the 
same program at once. That was my original guess because I would notice it 
occur after I opened the same .jar twice while it was running

Original comment by Killma...@gmail.com on 28 Apr 2013 at 2:33

GoogleCodeExporter commented 9 years ago 
You are not the first person to report issues with the hook stopping on windows 
(see bug 42) but I haven't been able to track down the cause of the issue.  
Basically some other application is causing the hook to stop and because most 
applications don't come with source code or even debugging symbols, its next to 
impossible for me to figure out why. Please check your running programs and let 
me know if you can isolate which one is causing the hook to stop. I am able to 
start 2 or more instances of the jar without issue.

Original comment by a...@1stleg.com on 28 Apr 2013 at 6:34

GoogleCodeExporter commented 9 years ago 
I kept looking around for issues similar to this and I kept finding people 
saying Windows 7 is the issue with the hooks stopping. They said to change 
LowLevelHooksTimeout in registry to a higher value after trying this I haven't 
had the issue not sure if just coincidence. Will check processes running 
when/if the issue occurs again.

Original comment by Killma...@gmail.com on 28 Apr 2013 at 6:46

GoogleCodeExporter commented 9 years ago 
Do you have a LowLevelHooksTimeout set?  Where is that reg key located?

Original comment by a...@1stleg.com on 28 Apr 2013 at 7:03

GoogleCodeExporter commented 9 years ago 
It is located HKEY_CURRENT_USER\Control Panel\Desktop
I don't recall the default value for this but I currently have it at 10000 
decimal

Original comment by Killma...@gmail.com on 28 Apr 2013 at 7:20

GoogleCodeExporter commented 9 years ago 
What happens if you delete that key?  I dont have one set ;)

Original comment by a...@1stleg.com on 28 Apr 2013 at 7:23

GoogleCodeExporter commented 9 years ago 
Okay deleted it, restarted, and checked to make sure it was deleted and it was. 
So far nothing noticeable has happened I will try to get the hook to stop.

Original comment by Killma...@gmail.com on 28 Apr 2013 at 7:44

GoogleCodeExporter commented 9 years ago 
I have done a lot of reading and it looks like LowLevelHooksTimeout is at least 
half of this problem for Windows 7 and later.

The hook procedure should process a message in less time than the data entry 
specified in the LowLevelHooksTimeout value in the following registry key:
HKEY_CURRENT_USER\Control Panel\Desktop

The value is in milliseconds. If the hook procedure times out, the system 
passes the message to the next hook. However, on Windows 7 and later, the hook 
is silently removed without being called. There is no way for the application 
to know whether the hook is removed.

So the Microsoft is pulling out hooks that take to long to process.  The hook 
in JNativeHook is pretty fast and should never take 10000 milliseconds unless 
the system is under some serious load.  I am still not sure what removing that 
key will do, but at least I build some tests to check.

There really isn't a "fix" for this problem.  The only work around I have found 
is to run the hook a separate thread, but that is how it is currently 
implemented.  The only part that maybe holding stuff up is the 
ConvertVirtualKeyToWChar, but that should only cause the keyboard hook to fail 
if it timed out.

The only alternative would be to use Windows Raw Input API (Basically HID) 
(http://msdn.microsoft.com/en-us/library/ms645536(v=vs.85).aspx) to grab input 
but that is only compatible with Windows XP and later.  If I decide to go that 
route, it would have to wait until version 1.2 of the library.

If you want to help speed up the process and know C/C++, feel free to try and 
get the raw input working with JNativeHook.  Even a simple test program to grab 
raw input would help speed this up.

Original comment by a...@1stleg.com on 29 Apr 2013 at 4:30

GoogleCodeExporter commented 9 years ago 
I have done some more testing over the last week and I have been unable to 
reproduce the problem.  I have even tried sleeping/nop for over 12 seconds on 
each callback and was unable to trigger a hook timeout.  The only other thing I 
can think of trying would be to increase the thread priority for the hook.  
BTW, Did removing the registry key improve anything for you?

Original comment by a...@1stleg.com on 10 May 2013 at 11:18

GoogleCodeExporter commented 9 years ago 
I have not had any issues since removing the key. Hooks have not timed out. 
Only thing I am not sure of is if deleting it or setting it to the 10000 is 
what has been dealing with the issues.

Original comment by Killma...@gmail.com on 11 May 2013 at 12:28

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago

Original comment by a...@1stleg.com on 3 Jul 2013 at 5:40

GoogleCodeExporter commented 9 years ago 
Issue 53 has been merged into this issue.

Original comment by a...@1stleg.com on 3 Jul 2013 at 5:40

GoogleCodeExporter commented 9 years ago 
Issue 46 has been merged into this issue.

Original comment by a...@1stleg.com on 3 Jul 2013 at 5:40

GoogleCodeExporter commented 9 years ago 
Version 1.2 should allow for better debugging of what exactly is going on here. 
 It will be a few more weeks until I have a developer preview for Windows.  
When it is available I will post it here.

Original comment by a...@1stleg.com on 3 Jul 2013 at 5:42

GoogleCodeExporter commented 9 years ago 
Quick question for those of you this bug effects.  Does the bug occur after 
debugging your application?  Could the Java debugger be triggering this bug?

Original comment by a...@1stleg.com on 4 Jul 2013 at 3:32

GoogleCodeExporter commented 9 years ago 
I do not recall if the catching stops when ran without the IDE but once it 
stopped catching even compiled it wouldn't work until computer restarted.

I am using eclipse myself for comparison to others with this problem.

Original comment by Killma...@gmail.com on 4 Jul 2013 at 4:24

GoogleCodeExporter commented 9 years ago 
I just hit this same issue. I accidentally ran an extra instance of my 
application in my IDE, and the hooks suddenly stopped working.
I am using the same environment as the OP, using 1.1.4 also, and I suspect I 
will need a computer restart to resolve. I was not debugging.
This wouldn't be so bad if calls to unregister and re-register hooks resolved 
it, but a computer restart is quite severe.

Original comment by louis.bu...@gmail.com on 24 Nov 2013 at 3:50

GoogleCodeExporter commented 9 years ago 
I have come across this issue myself but I am not sure it is entirely related 
to multiple instances, or at least that alone is not enough to cause it. I 
accidentally ran multiple instances previously and did not encounter the 
problem. It showed up for me when I ran a new instance by itself. To your 
question about the debuggger, for me it was caused by running it with the 
debugger attached, but applies to instances without the it.

Original comment by Joseph.T...@gmail.com on 3 Dec 2013 at 4:08

GoogleCodeExporter commented 9 years ago 
Yes, I now hit it on a daily basis. Even with single instances and no debugger. 
I start and stop my application frequently. I have the relevant 
register/unregister and finalize hooks in the application. I have been running 
the app via my IDE, as it's still in development.
It takes quite a long time before I run into the issue, but eventually I'll 
start the app and nothing gets triggered. I just wish there was a way to reset 
the state without restarting my machine.

Original comment by louis.bu...@gmail.com on 3 Dec 2013 at 5:13

GoogleCodeExporter commented 9 years ago 
I got this issue while working with a JavaFX app, I can't see any pattern 
before the hook fails. I have the debugger running and left it running 
overnight and the hook was still working, it's happens randomly and rebooting 
is the only solution.

Original comment by Tom91...@gmail.com on 11 Jan 2014 at 4:31

GoogleCodeExporter commented 9 years ago 
Please re-test with 1.2.0-Beta1.  Be sure to check console output for clues 
about why its stopping.  Debug symbols have also been included in case you want 
to attach a debugger.

Original comment by a...@1stleg.com on 22 Jan 2014 at 7:27

GoogleCodeExporter commented 9 years ago 
Issue 47 has been merged into this issue.

Original comment by a...@1stleg.com on 22 Jan 2014 at 7:35

GoogleCodeExporter commented 9 years ago 
Testing with 1.2.0 Beta1, the same issue but with log:

This is right after a failed hook:

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_auto_repeat_rate [39]: SPI_GETKEYBOARDSPEED: 22.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_auto_repeat_delay [53]: SPI_GETKEYBOARDDELAY: 1.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_multiplier [67]: SPI_GETMOUSE[2]: 1.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_threshold [81]: SPI_GETMOUSE[0]: 6.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_threshold [83]: SPI_GETMOUSE[1]: 10.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_sensitivity [98]: SPI_GETMOUSESPEED: 10.

一月 24, 2014 1:15:43 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_multi_click_time [112]: GetDoubleClickTime: 200.

一月 24, 2014 1:15:43 上午 org.jnativehook
SEVERE: hook_thread_proc [68]: SetWindowsHookEx() failed! (0X7E)

Note: I don't have the log of the hook failing because mouse movements flood 
the console too quickly. I'll redirect console output to a file and post 
results again.
Also, should I use google code to report future bugs or GitHub?

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 5:23

GoogleCodeExporter commented 9 years ago 
for "This is right after a failed hook", I mean right after I killed and 
restarted my app

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 5:25

GoogleCodeExporter commented 9 years ago 
Here's a normal app launch for comparison:

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_auto_repeat_rate [39]: SPI_GETKEYBOARDSPEED: 22.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_auto_repeat_delay [53]: SPI_GETKEYBOARDDELAY: 1.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_multiplier [67]: SPI_GETMOUSE[2]: 1.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_threshold [81]: SPI_GETMOUSE[0]: 6.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_acceleration_threshold [83]: SPI_GETMOUSE[1]: 10.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_pointer_sensitivity [98]: SPI_GETMOUSESPEED: 10.

一月 24, 2014 1:39:44 上午 java.lang.ClassLoader$NativeLibrary load
INFO: hook_get_multi_click_time [112]: GetDoubleClickTime: 200.

start hook // my debug message, ignore
glance up // my debug message, ignore
一月 24, 2014 1:39:52 上午 org.jnativehook
INFO: hook_event_proc [366]: Mouse moved to 1136, 404.

一月 24, 2014 1:39:52 上午 org.jnativehook
INFO: hook_event_proc [366]: Mouse moved to 1138, 406.

一月 24, 2014 1:39:52 上午 org.jnativehook
INFO: hook_event_proc [366]: Mouse moved to 1139, 408.

.... goes on as long as I touch my mouse....

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 5:41

GoogleCodeExporter commented 9 years ago 
Please use git hub to report new bugs, old bugs can stay here until they are 
resolved.  The error it is reporting looks like its related to too many global 
hooks being installed.  There appears to be an undocumented limit of 32 hooks 
on all Windows platforms.

Now I am not sure how your going to figure out how many hooks you have 
installed.  I have just wasted 2 hours of my life fighting with windows driver 
signing to try and answer that question.  Good luck.

Original comment by a...@1stleg.com on 23 Jan 2014 at 6:31

GoogleCodeExporter commented 9 years ago 
If I simply terminate the app(terminate JVM), is the hook automatically 
unregistered? Because it seems possible that after multiple launches(don't 
remember how many, but pretty close to 32+) the hook accumulates. I only 
install one hook in my app and this is how I did it:

    // remove all previous hook first, not sure if it's needed
    GlobalScreen.unregisterNativeHook();
    GlobalScreen.registerNativeHook();

    GlobalScreen.getInstance().addNativeKeyListener(new NativeKeyListener() {
        ... the listener...
    });

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 6:40

GoogleCodeExporter commented 9 years ago 
Ok try this, download http://www.airesoft.co.uk/files/MsgHookLister.zip and 
unpack it.

Reboot windows and press F8 to access the boot menu.  Select "Disable Driver 
Signature Enforcement"

Run a command console as administrator.

then run MsgListerApp /i followed by MsgListerApp /h

Paste the output here.

Original comment by a...@1stleg.com on 23 Jan 2014 at 6:44

GoogleCodeExporter commented 9 years ago 
I just installed 35 hooks with 8 running instances.... they appear to continue 
working and the also automatically unregistered on close for me as well.

Original comment by a...@1stleg.com on 23 Jan 2014 at 6:49

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Umm, the result is quite long...see result.txt

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 6:56

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm trying to install more than 32 hooks

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 6:57

GoogleCodeExporter commented 9 years ago 
At add 24 hooks, it fails. see result.txt

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 7:03

Attachments:

GoogleCodeExporter commented 9 years ago 
Actually, this time, not sure if it's the MsgHookListener, but I was able to 
run my app without any problems when I kill all (remaining)running instances of 
my app. Before, rebooting is the only solution...

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 7:09

GoogleCodeExporter commented 9 years ago 
How are you ending up with so many processes?  Is the debugger leaving 
something hanging?

Original comment by a...@1stleg.com on 23 Jan 2014 at 8:21

GoogleCodeExporter commented 9 years ago 
No, I was just trying to create as much instances as possible to make it fail; 
normally I would work with one instance only. It seems that if registered hooks 
exceed certain numbers, it will start to fail.

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 8:32

GoogleCodeExporter commented 9 years ago 
I should note that I do use the following JNA calls in my app for Window 
monitoring:

public static interface WinEventProc extends StdCallCallback {
    void callback(HANDLE hWinEventHook, int event, HWND hWnd, int idObject, int idChild,
        int dwEventThread, int dwmsEventTime);
} // http://msdn2.microsoft.com/en-us/library/ms697317(VS.85).aspx

public static native HWINEVENTHOOK SetWinEventHook(int eventMin, int eventMax,
                HANDLE handle, WinEventProc winEventProc, int idProcess, int idThread, int dwflags);

public static native void UnhookWinEvent(HWINEVENTHOOK hook);

public static native LRESULT SendMessageW(HWND hWnd, int msg, WPARAM wParam, 
LPARAM lParam);

Original comment by Tom91...@gmail.com on 23 Jan 2014 at 8:35

GoogleCodeExporter commented 9 years ago 
Issue 46 has been merged into this issue.

Original comment by a...@1stleg.com on 19 Feb 2014 at 6:12

GoogleCodeExporter commented 9 years ago 
I am experiencing the same issue, except the hook doesn't get terminated, but 
simply doesn't return anything.

Original comment by SkillTr...@gmail.com on 23 Feb 2014 at 4:04

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Attached is the latest nightly.  Is this still a problem for any of you?  I 
doubt there will ever be a fix for having more than 32 hooks installed.  The 
only thing I will be able to fix is if the jar is leaving a hook hanging for 
some reason.

Original comment by a...@1stleg.com on 12 May 2014 at 3:30

Attachments:

GoogleCodeExporter commented 9 years ago 
I have downloaded the latest version yesterday and i am facing the same 
pronblem.Is there any fix?

Original comment by dummy.b...@gmail.com on 22 Aug 2014 at 8:42

GoogleCodeExporter commented 9 years ago 
What version do you mean by the latest version?  1.1 will not even attempt to 
address this problem, you will need one of the 1.2 nightly builds.  The biggest 
problem here is I don't know what is causing the problem nor can I reproduce it 
so I cant even being trying to work around it.

Unless the native event dispatcher was overridden with a non-threaded 
dispatcher using setEventDispatcher, this is probably caused by too many hooks 
being installed and *not* by the callback taking too long to return as 
previously thought.  This library ONLY INSTALLS A SINGLE HOOK, so if 
JNativeHook is responsible for this problem, it is *probably* a result of one 
of the following scenarios:

A) You are using the hooks in a way that is causing them to continue running 
*AFTER* your program terminates.  You should be able to confirm this by looking 
at the number of JVM's that are currently running in the task manager.  If the 
JVM terminates, there should be no way that install hook could continue 
running.  To check for this, look at how many running java processes you have 
in the task manager.

B) The GlobalScreen.getInstance() is not returning a singleton in your 
implementation.  This should be pretty easy to test, just log the hashcode on 
the GlobalScreen each time you request an instance of it.

C) You're IDE is doing something special.  If you're IDE is loading your 
project's dependencies in some unique and special way that is causing them to 
run multiple times or to continue running/debugging after you have finished.  
You should be able to confirm this by closing all processes related to your IDE 
and Java.  Note that the IDE debugger may cause JNativeHook to terminate 
unexpectedly if dispatchEvent(NativeInputEvent e) takes to long to return when 
called from the native code because java execution is paused by the debugger.

D) You have lots of other hooks installed by other software on your system.  If 
there are other applications running that are haphazardly installing hooks, it 
will prevent JNativeHook form working, and their is nothing I can do to resolve 
the issue.  You can confirm hook pollution using the method outlined in comment 
#43. (https://code.google.com/p/jnativehook/issues/detail?id=43#c29)

Unless someone can figure out how to reliably cause the problem, I can't do any 
meaningful debugging on my end.  The library always appears to terminate 
correctly under all of my tests.  I have attached the latest nightly for 
testing.

Original comment by a...@1stleg.com on 22 Aug 2014 at 6:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Updated nightly builds.  Do any of you happen to be experiencing issue #88?

Original comment by a...@1stleg.com on 23 Aug 2014 at 8:02

Attachments:

GoogleCodeExporter commented 9 years ago 
I have attached a nightly that address issue #88.  Its a long shot, but it may 
also address this problem by limiting the number of unique libraries using 
hooks on the system.  It doesn't address why the hooks are never unregistered 
unless this bug is caused by a JVM deadlock in 
http://docs.oracle.com/javase/7/docs/api/java/io/File.html#deleteOnExit() 
because the file is in use on Windows.

Original comment by a...@1stleg.com on 24 Aug 2014 at 6:20

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey; using this for one of my projects and trying to get the program compatible 
with windows 8.1. I have windows 7 at work and the project compiles fine; 
however at home i get the same issue running with windows 8.1. So the only 
factor that i can see that may be the issue is that the hook fails on newer 
versions of windows. 

It doesnt seem to be a compile time issue as it runs fine on windows 7 when 
compiling with 8.1; it seems to be a hooking issue at run time on windows 8.1 
at the function SetWindowsHookEx(). Hope I could help more. 

Your latest build still has the same issue.

Original comment by blakenoo...@gmail.com on 25 Aug 2014 at 4:18

GoogleCodeExporter commented 9 years ago 
Just to add with the latest nightly build i get a expection on compile time.
Caused by: java.lang.NullPointerException
    at org.jnativehook.GlobalScreen.loadNativeLibrary(GlobalScreen.java:515)
    at org.jnativehook.GlobalScreen.<init>(GlobalScreen.java:75)
    at org.jnativehook.GlobalScreen.<clinit>(GlobalScreen.java:56)
    ... 15 more

Original comment by blakenoo...@gmail.com on 25 Aug 2014 at 5:54

GoogleCodeExporter commented 9 years ago 
Thanks for the response blakenoodles, Are you unpacking the jar into a 
different project?  The NullPointerException sounds like it couldn't find the 
manifest in the Jar that it was expecting. 
https://github.com/kwhat/jnativehook/blob/d95486a2d2a47b721cfc1b8cc8647448120729
aa/src/java/org/jnativehook/GlobalScreen.java#L515

Windows 8.1 is the version of windows I am currently testing on so something 
really really wired is going on here.  I have a fresh install with MSYS2 and 
JDK 1.8.11 installed.  The project compiles and runs on my end.  I will post 
another nightly when I figure out why Windows refuses to set the 
jnativehook.button.multiclick.iterval value to what it should be.

Original comment by a...@1stleg.com on 25 Aug 2014 at 9:00

GoogleCodeExporter commented 9 years ago 
Updated nightly that solves a few of the unpacking problems in the previous 
one.  Please retest.

Original comment by a...@1stleg.com on 27 Aug 2014 at 4:40

Attachments: