SOLVED: Access denied when loading chrome_elf.dll

[joachimdurchholzsix]

(SEE SOLUTION AT END OF POST)

The call to CefApp.getInstance(CefSettings) gives me this:

Code: Select all

java.lang.UnsatisfiedLinkError: C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll: Access is denied
   at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_162]
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) ~[na:1.8.0_162]
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) ~[na:1.8.0_162]
   at java.lang.Runtime.loadLibrary0(Runtime.java:870) ~[na:1.8.0_162]
   at java.lang.System.loadLibrary(System.java:1122) ~[na:1.8.0_162]
   at org.cef.SystemBootstrap$1.loadLibrary(SystemBootstrap.java:24) ~[jcef-1.0.jar:na]
   at org.cef.SystemBootstrap.loadLibrary(SystemBootstrap.java:36) ~[jcef-1.0.jar:na]
   at org.cef.CefApp.<init>(CefApp.java:145) ~[jcef-1.0.jar:na]
   at org.cef.CefApp.getInstance(CefApp.java:221) ~[jcef-1.0.jar:na]
   at org.cef.CefApp.getInstance(CefApp.java:208) ~[jcef-1.0.jar:na]
   at com.rolotec.vega.block.jcef.JavaCef.initialize(JavaCef.java:38) ~[classes/:na]


The file exists. It was freshly created by a git checkout, so it should be readable (even writable).
I know that DLLs can have dependencies and the real problem may be in a depended-on dll; I am assuming that these all live in the same directory as chrome_cef.dll or in the swiftshader subdirectoy.
The files are not in a temporary directory.
I checked that all .dll files are renameable (not the .pak files though).
I don't see any error messages from the virus scanner (I just ran a test on the dll directory and all subdirectories).
The virus scanner does not report any problems with any of the files in the directory and subdirectories.

I'm out of ideas what might be causing this; what should I check next?
I'd like to exclude that it's a depended-on dll; how do I find out what dll load action is actually failing here?

Regards,
Jo

SOLUTION: The .dlls lost they executable permission because they went through a git repository, and the permission bits were lost in the commit that added them.

[joachimdurchholzsix]

Okay, one thing is off the table: chrome_cef.dll doesn't declare any dll dependencies beyond Windows DLLs, so the issue is likely with chrome_cef.dll itself, not some other dll.

Other things I tried, with no success:
- Load dlls from the current directory (same error)
- Try Cygwin's strace (no useful output, seems it can only handle Cygwin executables)

[magreenblatt]

Check if your antivirus is interfering. You should be able to exclude the directory from scanning.

[joachimdurchholzsix]

I did a manual antivirus check on the dlls, everything checked out fine.
(I don't control the antivirus and cannot exclude directories from antivirus control, sadly.)

[joachimdurchholzsix]

Another potential reason eliminated: No alternate streams on the files (via streams64.exe).
Windows uses alternate streams to record where a file was downloaded from, and if present it will refuse to load code that has such an origin record).
However, the dlls I use don't have alternate streams. (I don't know for sure whether this mechanism is in force for dlls; I'd expect it to, but I never checked.)

Still grasping for straws...

[joachimdurchholzsix]

Another observation: The run.bat file with the command

Code: Select all

java -cp "./bin;./bin/*" -Djava.library.path=./bin/lib/win64 tests.detailed.MainFrame


runs just fine.

This is driving me up the wall. The files are the same, the current directory has been verified and seems correct, java.library.path is set... oh. Wait.

-Djava.library.path=./bin/lib/win64 tests.detailed.MainFrame works.
-Djava.library.path=bin/lib/win64 tests.detailed.MainFrame does not.

WTF???
Because if I enter an invalid directory path, I get a different error message.
Now this is starting to look like a weird and wonderful JVM bug to me... let me check my own application.
(And Kudos for releasing a test application. I would never have thought about leaving out that initial ./ section, believing it to be redundant.)

[joachimdurchholzsix]

Hm. Nope. The failure when running without the ./ prefix on java.library.path was because I had a typo and ran it with a Java that didn't support 64 bits, but java-cef was built for 64 bits, which canot work.

So... run.bat works provided I substitute in the right JDK Java, but my application does not.

Some more experiments:

Running my application with no java.library.path: java.lang.UnsatisfiedLinkError: no chrome_elf in java.library.path
Running my application with -Djava.library.path=invalidinvalidinvalid/./src/main/resources/lib (which does not exist): java.lang.UnsatisfiedLinkError: no chrome_elf in java.library.path
Running my application with -Djava.library.path=./src/main/resources/lib (the correct path): java.lang.UnsatisfiedLinkError: C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll: Access is denied

Here's from the DOS command line, commands composed by pasting the file name from the "Access is denied" message:

C:\Users\tkd6u\Downloads\tmp\java-cef\win64>dir C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll
Volume in drive C is SYSTEM
Volume Serial Number is 18B3-D7FA

Directory of C:\Daten\develop\id-gui\src\main\resources\lib

08.06.2020 08:41 956'416 chrome_elf.dll
1 File(s) 956'416 bytes
0 Dir(s) 171'574'964'224 bytes free

C:\Users\tkd6u\Downloads\tmp\java-cef\win64>copy C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll dummy-copy
1 file(s) copied.

C:\Users\tkd6u\Downloads\tmp\java-cef\win64>

The first command verifies that the file exists, the second that the file is readable.
What else might cause an "Access is denied"?

Is there a way to tell chome_elf.dll that it should log something to stdout when it is initialized?
At least I'd know whether it's "just Windows" that's sabotaging the load, or maybe something that happens during the chrome_elf.dll initialization?
(My C++ is extremely rusty so I didn't dare look into the source code - yet.)

[magreenblatt]

How does the run.bat command-line differ from your application command-line? Are you calling CefApp.startup as shown in the sample apps?

[joachimdurchholzsix]

The code just does

Code: Select all

cefApp = JavaCef.initialize();
cefClient = cefApp.createClient();

I recognize that this isn't quite right because that's missing initialization on Mac and Linux, but we're on a proof of concept that's just for Windows where CefApp.startup does nothing (or so the debugger tells me).

Checking for other differences to the sample app... hm, no, I don't see any relevant difference.

I reorganized the code; now main() does this:

Code: Select all

        try {
            CefApp.startup(args);
            CefApp.CefVersion cefVersion = CefApp.getInstance().getVersion();
            LOGGER.info("Chromium browser engine: java-cef initialized, using version: {}", cefVersion);
        } catch (Throwable t) {
            LOGGER.error("Could not initialize the Chromium browser engine: java-cef", t);
        }


Same output:

2020-06-09T07:48:17.319+0200 [main ] [ERROR] com.rolotec.vega.base.MainFrame - Could not initialize the Chromium browser engine: java-cef
java.lang.UnsatisfiedLinkError: C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll: Access is denied
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_162]
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) ~[na:1.8.0_162]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) ~[na:1.8.0_162]
at java.lang.Runtime.loadLibrary0(Runtime.java:870) ~[na:1.8.0_162]
at java.lang.System.loadLibrary(System.java:1122) ~[na:1.8.0_162]
at org.cef.SystemBootstrap$1.loadLibrary(SystemBootstrap.java:24) ~[jcef-1.0.jar:na]
at org.cef.SystemBootstrap.loadLibrary(SystemBootstrap.java:36) ~[jcef-1.0.jar:na]
at org.cef.CefApp.<init>(CefApp.java:145) ~[jcef-1.0.jar:na]
at org.cef.CefApp.getInstance(CefApp.java:221) ~[jcef-1.0.jar:na]
at org.cef.CefApp.getInstance(CefApp.java:208) ~[jcef-1.0.jar:na]
at com.rolotec.vega.block.jcef.JavaCef.initialize(JavaCef.java:38) ~[classes/:na]
at com.rolotec.vega.block.jcef.JavaCef.initialize(JavaCef.java:24) ~[classes/:na]
at com.rolotec.vega.base.MainFrame.startGui(MainFrame.java:183) [classes/:na]
at com.rolotec.vega.base.MainFrame.main(MainFrame.java:56) [classes/:na]

startGui isn't the first initialization in main, there's also logging and networking startup before that.
To exclude that possibility, I also temporarily changed main() to be this:

Code: Select all

    public static void main(String... args) {
        CefApp.startup(args);
        JavaCef.initialize();
        System.out.println("Success!");
    }


Same result:

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll: Access is denied
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.cef.SystemBootstrap$1.loadLibrary(SystemBootstrap.java:24)
at org.cef.SystemBootstrap.loadLibrary(SystemBootstrap.java:36)
at org.cef.CefApp.<init>(CefApp.java:145)
at org.cef.CefApp.getInstance(CefApp.java:221)
at org.cef.CefApp.getInstance(CefApp.java:199)
at com.rolotec.vega.base.MainFrame.main(MainFrame.java:51)

[joachimdurchholzsix]

Note the stack trace: The error happens during System.loadLibrary, for "chrome_elf".
To me, this looks like Windows doesn't like to load chrome_elf.dll for some reason; I checked a few reasons why that might be the case but my knowledge of DLL loading in Windows goes only so far. In particular, I have no idea to to investigate what exactly Windows dislikes about the DLL.

Another attempt, just to minimize the example:

Code: Select all

    public static void main(String... args) {
        System.loadLibrary("jawt");
        System.loadLibrary("chrome_elf");
    }

Fails with the same problem:

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Daten\develop\id-gui\src\main\resources\lib\chrome_elf.dll: Access is denied
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at com.rolotec.vega.base.MainFrame.main(MainFrame.java:51)

The same happens if I leave out the call to load jawt.dll.