JDK-8191176 : JavaFX Self-Contained Application fails with error "Failed to find library: jvm.dll"
  • Type: Bug
  • Component: deploy
  • Sub-Component: packager
  • Affected Version: 8u151,10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2017-11-04
  • Updated: 2018-01-09
  • Resolved: 2017-12-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8
10Fixed 8u162Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

A DESCRIPTION OF THE PROBLEM :
A library loading error occurs at application startup.

REGRESSION.  Last worked in version 8u144

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
javafxpackager.exe -makeall -appclass Main
Run dist\bundles\Main\Main.exe

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No error.
ACTUAL -
A library loading error occurs.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
[Error 1]
Main.exe - System Error
The program can't start because MSVCR100.dll is missing from your computer. Try reinstalling the program to fix this problem.

[Error 2]
Failed to find library.
...\Main\runtime\bin\server\jvm.dll

[Error 3]
Main.exe
Failed to locate JNI_CreateJavaVM

[Error 4]
Main.exe
Failed to launch JVM

(Error 1 is not shown on Windows Server 2016)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.stage.Stage;

public class Main extends Application {

    public static void main(String[] args) {
        Application.launch(args);
    }

    @Override
    public void start(Stage stage) {
        final Scene scene = new Scene(new Group(), 640, 480);
        stage.setScene(scene);
        stage.show();
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Copy runtime\bin\msvcr100.dll to the folder where Main.exe exists.


Comments
I am building an enterprise software which is widely distributed, and manually copying some DLL is an impossible operation as a show stopper for our clients. For anyone seeking a solution, I extracted the "msvcr100.dll" from Java and added it to my application source. When using the JavaPackager when building my JavaFX project (using InnoSetup), I simply add these lines in the setup.iss script in order to place the file next to the application.exe : [Files] Source: "YOUR_APPLICATION\app\msvcr100.dll"; DestDir: "{app}"; Flags: ignoreversion It's working for me.
09-01-2018

I recommend manually copying the DLLs, but maybe Victor has an additional suggestion. Note that the release date for JDK 8u162 is Jan 16.
08-01-2018

Do we have a work-around for those using JDK8u152? I'm deploying a JavaFX application using Javapackager and this is a show stopper. Should I manually add msvcr100.dll next to the application.exe using InnoSetup? Or should I just modify a classpath somehow?
08-01-2018

Approved to push to 8u-dev for 8u172.
14-12-2017

http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/8abbfbe9fe9b
14-12-2017

Request to backport the change to 8u-dev. Webrev for 8u-dev: http://cr.openjdk.java.net/~vdrozdov/JDK-8191176/webrev.8udev.00/
14-12-2017

Yes, the change is verified on a clean Win machine.
13-12-2017

Looks good to me. I presume you have verified it on a Windows platform without Visual Studio? +1
13-12-2017

new webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8191176/webrev.01/ (only changed the filter)
13-12-2017

Using copyMSVCDLLs(ver) we copy only vcruntime<VS_VER>.dll and msvcp<VS_VER>.dll (for 10 VS_VER is 140). Actually my initial intent was to copy only 18 api-ms-*.dlls files. However, if I start the app using -Djavafx.verbose=true, the log is following: $ ./output2/Test/Test.exe JavaFX launchApplication method: launchMode=LM_CLASS System.loadLibrary(api-ms-win-core-console-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-datetime-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-debug-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-errorhandling-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-file-l1-1-0) succeeded Loaded E:\workspace\fx-10-dev4\rt\modules\jdk.packager\src\test\examples\fxapp\output2\Test\api-ms-win-core-file-l1-2-0.dll from java.library.path Loaded E:\workspace\fx-10-dev4\rt\modules\jdk.packager\src\test\examples\fxapp\output2\Test\api-ms-win-core-file-l2-1-0.dll from java.library.path System.loadLibrary(api-ms-win-core-handle-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-heap-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-interlocked-l1-1-0) succeeded System.loadLibrary(api-ms-win-core-libraryloader-l1-1-0) succeeded it still loads some dlls from the folder which contains the launcher.
13-12-2017

1. Can you say why msvcr120.dll is not already copied by copyMSVCDLLs(String VS_VER)? In any case it seems fine to add msvcr along with mscvp as a pattern to copy. 2. I think it might be cleaner and more future proof to use a pattern to match these files. Perhaps you could consider changing the following: files.filter(p -> Pattern.matches("(vcruntime|msvcp)\\d\\d\\d.dll", p.toFile().getName().toLowerCase())) to something like this: files.filter(p -> Pattern.matches("^(vcruntime|msvcp|msvcr|ucrtbase|api-ms-win-).*\\.dll$", p.toFile().getName().toLowerCase())) and then you wouldn't need the hard-coded list of 40+ files.
13-12-2017

In order to launch the app generated by jdk10 (on clean windows system), I had to copy api-ms-win*.dlls + ucrtbase.dll. Therefore, the similar problem exists for 10 as well.
13-12-2017

webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8191176/webrev.00/
13-12-2017

The issue does exist on clean Windows machine. In order to launch the app the following dlls (from runtime/bin) should be copied to the folder that contains Main.exe: api-ms-win-core-file-l1-2-0.dll api-ms-win-core-file-l2-1-0.dll api-ms-win-core-localization-l1-2-0.dll api-ms-win-core-processthreads-l1-1-1.dll api-ms-win-core-synch-l1-2-0.dll api-ms-win-core-timezone-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-multibyte-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll ucrtbase.dll msvcr100.dll
11-12-2017

In looking more closely at JDK-8187366, I don't think this is a duplicate. That fix did not change production bits in any way. It was only a help for developers who build JavaFX.
11-12-2017

This might require testing on a clean system that doesn't have VS 2017 (or any earlier Visual Studio) installed.
11-12-2017

I couldn't reproduce the problem for 8u172 on my Win 10 machine. Probably it was fixed by JDK-8187366.
11-12-2017

Oh, yes, I see what you mean. That's possible and worth testing.
11-12-2017

I meant it could potentially fix the problem.
11-12-2017

The fix for JDK-8187366 went into 8u-dev (for 8u172) after 8u152 (it isn't even in 8u162), so that wouldn't have cause this regression.
11-12-2017

it might be related with JDK-8187366
11-12-2017

Raising to P2 as this is a regression with no known workarounf.
11-12-2017

Verfied again on Windows 10 Enterprise build 1709 with respective JDK versions and could confirm the issue as reported. A "Failed to find library: jvm.dll" and subsequent error dialogs popped up as described when checked with JDK 8u151/8u152. See attached screenshot for reference. Note: Didn't observe errors w.r.t msvcr100.dll Please note the application run fine post error messages. Results: =========== 8u144: OK 8u151: FAIL 8u152: FAIL 8u162 ea b03: FAIL 9: OK 10 ea b33: OK This seems a regression introduced in JDK 8u151. 1. Save attached Main.java and compile, > javac src/main.java 2. Run javapackager command, javapackager.exe -makeall -appclass Main 3. Run executable, dist/bundles/Main/main.exe
11-12-2017

This is likely a regression from the VS 2017 upgrade which was done as part of the WebKit upgrade for 8u151.
30-11-2017

Reported with: JDK 8u152 Windows Server (2008 R2/2012/2012 R2/2016), evaluation versions. JavaFX self-contained application failed to run with missing msvcr100.dll error Checked this on Windows 10 (64-bit) with JDK 8u144 and 8u152 and couldn't reproduce the issue as reported. The application run fine without an error. Results: ========= 8u144: OK 8u152: OK To verify run the attached test case, compile and run - javapackager.exe -makeall -appclass Main Run dist\bundles\Main\Main.exe Note: javafxpackager.exe has been renamed javapackager.exe From the description it appears to be system specfic issue. This still need to be checked for Windows server environment. Checking with submitter if the issue exists on Windows environment other then windows server (2008/2012 or 2016).
14-11-2017