We've recently made some structural changes to our large application. It's been being built and launched with Launch4J for a long time. We're using a 1.7 JVM installed in our app directory.
With our latest changes, the Launch4J generated .exe no longer works.
When we run it, it immediately pops up with a error dialog:
Title:Java Virtual Machine Launcher
Message: A Java Exception has occurred.
As far as I can tell, our app never even starts.
the Launch4J log file starts like this:
Version: 3.6
CmdLine: C:\Program Files\EFI\Metrix\Metrix.exe --l4j-debug-all
WOW64: yes
Resource 101: An error occurred while starting the application.
Resource 8: .
Working dir: C:\Program Files\EFI\Metrix\.
...
That "Resource 101:" line is the only info I have.
How can I find out exactly what the error was?
Ok, finally tracked this down. Due to a bad merge, one of our .jar files got left out of the classpath, so the app was getting a classnotfoundexception during startup.
Seems like this is in the kind of error that Launch4J should report in a useful way.
Related
We're experiencing a strange issue - has anybody seen anything similar?
We have a Java/JavaFX desktop application that has been running successfully on a Windows platform (Server 2012) for almost a year.
Recently we moved the application to a different Windows platform (Server 2019, virtual machine).
The app is installed on a shared drive and is started several times a day. It initially runs successfully but at some point in the day will no longer start.
The command line is:
java -p WolfToolkit.jar;WolfToolkit_mods -m com.mycompany.wolftoolkit/com.mycompany.start.StartGUI
WolfToolkit_mods is a folder containing jars for the required modules. When the start-up error occurs, Java.exe reports thatvarying required modules cannot be found. After a lot of diagnostic testing, it appears that Java.exe can no longer detect any of the jar files in the WolfToolkit_mods folder even though Windows Explorer shows the correct content.
If I copy folder WolfToolkit_mods to WolfToolkit_mods2 and change the command to
java -p WolfToolkit.jar;WolfToolkit_mods2...
then the app starts correctly.
If I re-copy just one of the jar files into WolfToolkit_mods and use the original command, then only that file is visible. If all files are re-copied then the app runs correctly.
So, the behaviour is as if Java suddenly views WolfToolkit_mods as being empty and only detects each jar file when it is copied back in. Meanwhile Windows sees no problems. I should also mention that on rare occasions Java.exe suddenly starts reporting that WolfToolkit.jar is "Module format not recognized". Again, re-copying the file resolves the issue.
Any ideas on what this could be or how to diagnose? Thanks.
Windows Server 2019 Standard v10.0
JVM: OpenJDK 64-bit Server v11.0.10+9
This looks to have been caused by the virus checker which was quarantining all .jar files as "suspicious". Presumably when java.exe was trying to read the files on the module path the virus checking software intervened and the effect was that java.exe couldn't locate module-info and so reported missing modules.
Thanks to those who took the time to respond.
My company sells a Java app that mysteriously stopped working for one of our customers. It had been working, but now won't start. The error he gets when trying to start the app is: "java.awt.AWTError: Assistive Technology not found...". I've researched the issue and I think it's caused by some other java app which incorrectly installed “java se accessbridge” and ended up corrupting all java apps on his PC. See:
https://www.avnirvana.com/threads/java-install-error-any-ideas-on-the-fix.2178/
Exception in thread "main" java.awt.AWTError: Assistive Technology not found: com.sun.java.accessibility.AccessBridge error
https://docs.oracle.com/javase/accessbridge/2.0.2/setup.htm#uninstalling-jab
I've had the customer uninstall our app, uninstall all copies of Java on his PC, and delete all copies of WindowsAccessBridge.dll found in ‘%WINDOWSHOME%\SYSWOW64’ and ‘%WINDOWSHOME%\SYSTEM32’. Now, he gets the same error from Install4j when trying to re-install our app. I have not asked him to try to re-install Assistive Technology-AccessBridge since our app does not require it and the installation appears convoluted and requires a number of manual steps.
There does appear to be a workaround. According to this article:
https://deciphertools.com/blog/2016-05-09-assistive-technology-not-found/
you can keep the jre from loading AccessBridge by adding:
-Djavax.accessibility.assistive_technologies
-Djavax.accessibility.screen_magnifier_present=false
To the app's vmoptions file. I would have him add this to our vmoptions file, but he can't get the installer to run since it gets the same error.
My question is twofold:
What other things can I have the customer do to remove Assistive Technology-AccessBridge?
Failing that, how can I modify install4j's vmoptions file so he can install our app and modify its vmoptions file?
The installer does not read a .vmoptions file for security reasons. You can pass VM parameters on the command line like this:
installer.exe -J-Djavax.accessibility.assistive_technologies -J-Djavax.accessibility.screen_magnifier_present=false
I haven't been able to find a specific answer to what could be causing this issue though I am hoping it is something quite simple.
Issue.
I have installed version 10.0.0.Final from the Wildfly website and extracted into C:\Program Files\wildfly-10.0.0.Final.
I then navigate to C:\Program Files\wildfly-10.0.0.Final\bin directory via windows command prompt and execute the standalone.bat command.
Wildfly doesn't start and I get the following exception:
java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
If anyone has encountered this error message before, then your guidance would be greatly appreciated.
Thanks!
Ben
The error appears to be a result of either file permissions on the JBoss home directory, lack of space available, or a missing directory.
Relevant posts include:
Starting WildFly 8.2 under a user with limited permissions
Which suggests setting the JBOSS_BASE_DIR property to the root folder of the JBoss installation.
https://github.com/jboss-dockerfiles/wildfly/issues/24
Suggests this can occur if the root folder does not have enough space allocated for the user (typically running in Unix environments).
Error in starting Wildfly 8.0 server with JDK 1.8
The logs/boot.log didn't exist. The author manually created the file which then revealed a permission issue on the log file (more likely on the entire Jboss installation folder).
The issue was caused due to the command prompt. As I am using windows 10, I needed to be using Command Prompt (Admin),rather than just the normal cmd hence the permission issues alluded to previously by pczeus.
After using Command Prompt (Admin), I was able to start the server.
I created a Play app for students to use in an assignment for my user interface course. They don't need to modify it, just access it via AJAX. I used "activator dist" to package it up in a JAR file; they download it to their computers, unzip it, and run it locally.
It has worked well for everyone except one student. I'm at my wit's end for debugging and am appealing to the community for ideas.
The exception is:
Exception in thread "main" java.lang.NoSuchMethodError: ch.qos.logback.classic.LoggerContext.getFrameworkPackages()Ljava/util/List;
at play.api.Logger$.configure(Logger.scala:268)
at play.api.Logger$.configure(Logger.scala:232)
at play.api.inject.guice.GuiceApplicationBuilder.applicationModule(GuiceApplicationBuilder.scala:73)
at play.api.inject.guice.GuiceBuilder.injector(GuiceInjectorBuilder.scala:126)
at play.api.inject.guice.GuiceApplicationBuilder.build(GuiceApplicationBuilder.scala:93)
at play.api.inject.guice.GuiceApplicationLoader.load(GuiceApplicationLoader.scala:21)
at play.core.server.ProdServerStart$.start(ProdServerStart.scala:52)
at play.core.server.ProdServerStart$.main(ProdServerStart.scala:27)
at play.core.server.ProdServerStart.main(ProdServerStart.scala)
Things we've checked:
He's running Java 1.8.0_45. It was compiled with Java 1.8.0_66. He has reinstalled Java (which I'm assuming is 1.8.0_66 or greater). No change.
The md5 checksum of the download jar file matches the original.
lib/ch.qos.logback.logback-classic-1.1.3.jar exists and has the same size on his machine as on mine.
We've installed scala/Play/Activator on his machine, copied over the sources and tried compiling from scratch on his machine. Same error.
I've looked in the script prepared by "activator dist". I believe it's calling the same version of java as what we see from the command line. That is, I don't think we're being confused by two copies of the java runtime.
This is on a MacBook Pro (pre-Retina) with El Capitan.
Ideas?
I have a Java app that use a bunch of JNI calls to execute low level stuff on Windows. When I make the JVM crash voluntarily, I noticed that it is not producing any hs_err_pid.log file which would be very useful for debugging.
Here is the behavior:
When I run it from Eclipse ==> The file is created in the current working dir
When I compile my app and run the .exe ==> The file is created in the current working dir
When I run the installer and run my app from the .exe in C:\Program Files\..., I still get the error message in the console that tells me the JVM crashed and a crash report has been created in C:\Program Files\MyApp\hs_err_pid3060.log, but the file does not exist.
Any idea on what's causing this behavior?
Maybe it's caused by insufficient privilege of your app. The file writing by jvm has been blocked by the OS. You can try running your app with admin privilege and see if it works.