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 freezes my computer when debugging code in IntelliJ #264

Open
ZGorlock opened this issue Jul 25, 2019 · 5 comments
Open

jnativehook freezes my computer when debugging code in IntelliJ #264

ZGorlock opened this issue Jul 25, 2019 · 5 comments

Comments

@ZGorlock
Copy link

ZGorlock commented Jul 25, 2019

I am using jnativehook for a small purpose in a much larger application in IntelliJ. When I am debugging my code with jnativehook registered, my mouse freezes for 10 to 15 seconds before returning control to me. After this it is fine until I step to the next line of code, etc, at which point it does the same thing again. This is very hard to work with and it does not happen when the hook is not registered on the global screen. Is there some setting I can use to prevent this behavior?

EDIT:
I am using version 2.1.0 from Maven:

com.1stleg
jnativehook
2.1.0

@kwhat
Copy link
Owner

kwhat commented Jul 26, 2019

Hi,

It's kind of the expected behavior when the hook is registered and debugger starts because the debugger will pause the event delivery thread, which in turn blocks the OS event delivery queue on Windows and Mac OS X. Work arounds for this are difficult. Basically, the only way to fix this issue would be to detect the debugger attachment in code, and then unregister the hook before handing off to the debugger. There is no way that I know of to detect debugger attachment in Java, however, there are a number of "anti-debugging techniques" that might work in C. These "techniques" are generally for detecting native debuggers like Ida and SoftICE, so I have no idea if they will work with the Java debugger from JNI. There is already another bug on this bug tracker to address this issue, but it's not a major priority at the moment. After I make another 2.1 release or two, I will play around with this and see if I can get something working; at least for Windows. I do not have access to a mac right now, so development on that side is probably going to be on hold longer. If you have some free time, please feel free to hack around on the code and see if you can get something like a printf or log message to come out when the debugger is attached. There are a lot of debugger detection to prevent reverse engineering articles out on the internet to reference, and I can always answer questions. Hopefully, I will be adding a Dockerfile to create a cross-compiler to the 2.1 branch shortly, so compiling the library from source should get much easier. I hope this explanation helps address some of your frustration.

Best,
Alex

@kwhat
Copy link
Owner

kwhat commented Jul 26, 2019

I just did a quick search again, it maybe this easy

 if(IsDebuggerPresent())
 {
     // unregister the hook.
 }

https://en.wikibooks.org/wiki/X86_Disassembly/Debugger_Detectors

@patrick-brielmayer
Copy link

Try to only suspend the current thread!
Capture

@rom4ster
Copy link

rom4ster commented Feb 1, 2024

Hi,

It's kind of the expected behavior when the hook is registered and debugger starts because the debugger will pause the event delivery thread, which in turn blocks the OS event delivery queue on Windows and Mac OS X. Work arounds for this are difficult. Basically, the only way to fix this issue would be to detect the debugger attachment in code, and then unregister the hook before handing off to the debugger. There is no way that I know of to detect debugger attachment in Java, however, there are a number of "anti-debugging techniques" that might work in C. These "techniques" are generally for detecting native debuggers like Ida and SoftICE, so I have no idea if they will work with the Java debugger from JNI. There is already another bug on this bug tracker to address this issue, but it's not a major priority at the moment. After I make another 2.1 release or two, I will play around with this and see if I can get something working; at least for Windows. I do not have access to a mac right now, so development on that side is probably going to be on hold longer. If you have some free time, please feel free to hack around on the code and see if you can get something like a printf or log message to come out when the debugger is attached. There are a lot of debugger detection to prevent reverse engineering articles out on the internet to reference, and I can always answer questions. Hopefully, I will be adding a Dockerfile to create a cross-compiler to the 2.1 branch shortly, so compiling the library from source should get much easier. I hope this explanation helps address some of your frustration.

Best, Alex

How do you explain me spamming Alt tab and shaking the mouse being able to free the mouse cursor ?
Also could this be because the lib despite me not actually reacting to motion, is listening to it? In theory listening to clicks only should ignore motion events right? What point does the addNativeMouseMotionListener function serve if I am going to be listening to those events anyways?

I am on windows btw

@rom4ster
Copy link

rom4ster commented Feb 1, 2024

I just did a quick search again, it maybe this easy

 if(IsDebuggerPresent())
 {
     // unregister the hook.
 }

https://en.wikibooks.org/wiki/X86_Disassembly/Debugger_Detectors

This workaround is sound unless you want to debug something dependent on the actual library.

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

No branches or pull requests

4 participants