install4j: Force a launcher (EXE) to use DLLs from bundled JRE folder

Viewed 166

We use install4j 8.0.8 in our application. Since a new release of the application we use JRE 11.0.10 from Azul and found out that small amount of users under Windows 10 were unable to load the application with exception: java.lang.UnsatisfiedLinkError: C:\Users\user\AppData\Local\thinkorswim\jre\bin\awt.dll: Can't find dependent libraries. We were unable to reproduce the issue on our machines.

We've found in Internet some similar issues with other applications and it was said there could be a broken Windows installation (may be some DLLs were corrupted). Many pages contain mentioning of msvcp140.dll.

With Windows Resource Monitor we found out that our application (started with install4j native EXE launcher) loads msvcp140.dll from c:\windows\system32, but JRE 11 contains the DLL inside bin folder. Then we ran our application without the native launcher (just java -jar) and Resource Monitor showed that msvcp140.dll has been loaded from jre\bin folder.

We've asked a user to repeat and they said that the application can be launched with java -jar.

I've played with PATH environment variable and java.library.path via a .vmoptions file and I was unable to force the launcher to use DLLs from the bundled JRE.

Is it possible to tune the native launcher to make it load DLLs from the JRE bin folder?

1 Answers

On Windows, executables always try to load DLLs from their directory first. That is why java.exe will load DLL dependencies from the bin directory before looking in the system32 directory,

The install4j launcher does not call java.exe, but starts the JVM via JNI so it's not the bin directory of the JRE but the directory of the launcher that is looked at first. Unfortunately, it is not possible to change this behavior.

Related