How to understand and fix EXCEPTION_ACCESS_VIOLATION when calling jni method when using packer in exe file javafxpackager and x86_64 version of java?

Question

Java

I'm on the task of developing a java application installer that uses the rhvoice speech synthesis voice engine . The main goal is to eliminate the requirement for administrator rights. This means you can't use the sapi version of the engine, as it requires privilege escalation to install it.
The solution is quite simple, the necessary code is already in the rhvoice project for android, you need to make a minimum of formal changes in order to build the jni library for windows (they are assembled immediately for both x86 and x86_64 architectures).
In general, both dlls are built, and the java application successfully uses them and everything works on both architectures if you run the application using the java virtual machine.
But if you assemble the resulting application (a set of jar files, rhvoice language pack data and compiled dlls) using javafxpackager (this is a regular javafx application for building an exe version that uses jvm.dll that comes with java) or the same packr , then when you start The 64-bit version throws an exception (the 32-bit version works without problems):

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff83fa36b2d, pid=110316, tid=0x0000000000019f60
#
# JRE version: OpenJDK Runtime Environment (8.0_201-b09) (build 1.8.0_201-1-ojdkbuild-b09)
# Java VM: OpenJDK 64-Bit Server VM (25.201-b09 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [RHVoice.64.dll+0x6b2d]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
...
Stack: [0x000000dd61600000,0x000000dd61ad0000],  sp=0x000000dd61acf030,  free space=4924k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [RHVoice.64.dll+0x6b2d]
C  0x000002990001962e

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.github.olga_yakovleva.rhvoice.TTSEngine.doGetVoices()[Lcom/github/olga_yakovleva/rhvoice/VoiceInfo;+0
j  com.github.olga_yakovleva.rhvoice.TTSEngine.getVoices()Ljava/util/List;+1
j  com.github.olga_yakovleva.rhvoice.Test.go()V+17
j  com.github.olga_yakovleva.rhvoice.Test.main([Ljava/lang/String;)V+34
v  ~StubRoutines::call_stub

When using different versions of rhvoice, the error occurs in different situations, most often almost immediately after the first jni method is called, but if you insert debugging information in the rhvoice dll code, you can see that the code starts and runs for some time. With some combinations of versions, I got this same error inside one of the java dlls.
Tried different versions of oracle java from 100th to latest. I tried the latest version of openjdk, an unofficial build for windows - the result is identical, the 32-bit version works, but the 64-bit version crashes with an exception.
Unfortunately, I don’t really understand how I can identify the cause of such a fall and fix the error, if there is one in the rhvoice code. I can't use the debugger, or I don't know how to set up an environment for it, I suppose this requires debug versions of everything and java and my library, etc.?
ps A few years ago (in 2014) when I solved this problem, the 64-bit version worked on windows 7 and seems to work on windows 8. Unfortunately, the dlls compiled then do not work on windows 10. Attempts to pick up compiler versions (used vs2013, tried vs2015 and now vs2017), versions of oracle java and even the operating system in which the build is being made, were not successful, but showed that the result strongly depends on all these parameters, i.e. critical even if you build under win7 and run under win10.
upd. the problem can be said to be solved using the release tag rhvoice (last year's release), but the question of how, in principle, you can debug applications launched in this way,..

Answer 1

Have you tried building with Launch4j ?

Answer 2

If I solved this problem some time ago, I found a bug in the rhvoice code, the pointer was saved to a 4-byte variable (and then transferred to an 8-byte long java), when 8 bytes are needed immediately for 64-bit systems.
The rhvoice developers were informed about this, but the bug has not yet been fixed, it 's here , long needs to be replaced with auto