RC3 crashes on Win7 using 32 bit Java

[GoogleCodeExporter]

When I run the NativeHookDemo included with 1.1.0 RC3 it crashes java on my 
machine. Works fine with 1.1.0 RC2.

Used the following command:
java -jar JNativeHook.jar

Java Version: 1.6.0_24 - 32bit
OS Version:   Windows7

The crash log is attached.

Original issue reported on code.google.com by awbra...@gmail.com on 26 Jul 2012 at 8:22

Attachments:

• hs_err_pid5792.log

[GoogleCodeExporter]

What does the 32 VM return for System.getProperty("os.arch")?  If its 64-bit 
the jar is loading the wrong library which makes me wonder how rc2 worked.

Original comment by alex%1st...@gtempaccount.com on 27 Jul 2012 at 4:41

[GoogleCodeExporter]

Also check System.getProperty("sun.arch.data.model") and see if that value 
differs from System.getProperty("os.arch").

Original comment by alex%1st...@gtempaccount.com on 27 Jul 2012 at 4:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here you go
------------------
os.arch=x86
sun.arch.data.model=32

Here's my java verison info
----------------------------------------
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

Here's a full listing of properties
----------------------------------------
awt.toolkit = sun.awt.windows.WToolkit
file.encoding = Cp1252
file.encoding.pkg = sun.io
file.separator = \
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = .
java.class.version = 50.0
java.endorsed.dirs = C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\endorsed
java.ext.dirs = C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\ext;C:\windows\Sun\Java\lib\ext
java.home = C:\Program Files (x86)\Java\jdk1.6.0_24\jre
java.io.tmpdir = C:\Users\Andrew\AppData\Local\Temp\
java.library.path = C:\Program Files
(x86)\Java\jdk1.6.0_24\bin;.;C:\windows\Sun\Java\bin;C:\windows\system32;C:\wind
ows;C:\Program
Files (x86)\CollabNet\Subversion;C:\Program Files\Microsoft
SDKs\Windows\v7.1\Bin\;C:\Program Files\Common Files\Microsoft
Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft
Shared\Windows Live;C:\Program Files
(x86)\Java\jdk1.6.0_24\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wb
em;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Common
Files\Intel\WirelessCommon\;C:\Program Files (x86)\Windows
Live\Shared;C:\Java\apache-ant-1.8.2\bin;C:\Java\groovy-1.8.1\bin;C:\Java\grails
-2.0.1\bin;C:\Program
Files (x86)\install4j5\bin;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program
Files (x86)\QuickTime\QTSystem\;C:\Java\wineconvoytools;C:\Program Files
(x86)\PostgreSQL\8.4\bin;C:\Java\android-sdk\platform-tools;C:\Java\apache-maven
-3.0.4\bin
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.6.0_24-b07
java.specification.name = Java Platform API Specification
java.specification.vendor = Sun Microsystems Inc.
java.specification.version = 1.6
java.vendor = Sun Microsystems Inc.
java.vendor.url = http://java.sun.com/
java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
java.version = 1.6.0_24
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) Client VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Sun Microsystems Inc.
java.vm.specification.version = 1.0
java.vm.vendor = Sun Microsystems Inc.
java.vm.version = 19.1-b02
line.separator =

os.arch = x86
os.name = Windows 7
os.version = 6.1
path.separator = ;
sun.arch.data.model = 32
sun.boot.class.path = C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\resources.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\rt.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\sunrsasign.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\jsse.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\jce.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\charsets.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\lib\modules\jdk.boot.jar;C:\Program Files
(x86)\Java\jdk1.6.0_24\jre\classes
sun.boot.library.path = C:\Program Files (x86)\Java\jdk1.6.0_24\jre\bin
sun.cpu.endian = little
sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386
i86
sun.desktop = windows
sun.io.unicode.encoding = UnicodeLittle
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.management.compiler = HotSpot Client Compiler
sun.os.patch.level = Service Pack 1
user.country = US
user.dir = C:\Users\Andrew\Desktop
user.home = C:\Users\Andrew
user.language = en
user.name = Andrew
user.timezone =
user.variant =

Andrew

Original comment by awbra...@gmail.com on 27 Jul 2012 at 6:13

[GoogleCodeExporter]

Thanks Andrew.  Pretty sure I know where the problem is but I cant test until I 
get back from defcon.  Should have a fix by Monday.

Original comment by alex%1st...@gtempaccount.com on 28 Jul 2012 at 2:28

• Changed state: Accepted

[GoogleCodeExporter]

Alright, good news and bad news.  The good news is I am fairly certain I know 
what is causing the problem.  When running under 32-bit mode on 64-Bit Windows 
dll's are loaded from SysWow64 instead of the System32 directory.  The problem 
is that these DLL's are not purely 32-bit.  Apparently they contain *SOME* 
64-bit pointers (probably due to kernel design decisions) hence the need for 
__ptr64 on Wow64 targets.  Now for the bad news.  As far as I know GCC and 
subsequently MinGW do not support mixing pointer size (i.e. __ptr64).  

At this point I am not sure how to move forward.  The easy solution would be to 
use 64-bit Java on 64-bit Windows.  Other options include having Microsoft 
*FIX* the ToUnicode function that is included in the user32 library (See bug 
11) or figuring out a way to hack in 64-bit pointers with GCC.  Using MSVC to 
build the project is probably going to be to much of a headache for this 
project.  Even if it was used it would require a 3rd windows library or at the 
very least duplicating all of the structures in the WinUnicodeHelper header.   

If anyone has other ideas I am all ears on this one.

Original comment by alex%1st...@gtempaccount.com on 31 Jul 2012 at 11:40

[GoogleCodeExporter]

Update:  I am trying a different approach of access the data keyboard layout 
structures on Windows.  Instead of using the static structure outlined in the 
header I am trying to access the items dynamically using the offsetof macro.  
If it works, it will both reduce the size of the windows dll's and work on 
Wow64 with the same x86 binary.  The branch can be found at 
https://jnativehook.googlecode.com/svn/branches/dynamic_wow64/JNativeHook 
although it probably wont compile.  I will post updates as I figured this out.

Original comment by a...@1stleg.com on 6 Aug 2012 at 10:40

[GoogleCodeExporter]

Original comment by a...@1stleg.com on 13 Aug 2012 at 11:41

• Changed state: Started

[GoogleCodeExporter]

I believe I finally have a viable solution to this problem.  Please test the 
attached JAR and let me know if you have any problems.

Original comment by a...@1stleg.com on 5 Sep 2012 at 4:15

Attachments:

• JNativeHook.jar

[GoogleCodeExporter]

That seems to do the trick on 32 bit Java on Windows. Didn't test any other
platforms yet.

Andrew

Original comment by awbra...@gmail.com on 5 Sep 2012 at 2:37

[GoogleCodeExporter]

Excellent!  I tested Windows XP and Win7 64 and Wow64.  It appears to be stable.

Original comment by a...@1stleg.com on 5 Sep 2012 at 4:28

• Changed state: Fixed