A customer is using Windows Server 2008 64 bit and the Oracle JDK version 1.6.33 64 bit. Recently, the following error occurred when a (any) Java application was started;
Problem Event Name: APPCRASH
Application Name: java.exe
Application Version: 6.0.330.5
Application Timestamp: 4fed0a6a
Fault Module Name: jvm.dll
Fault Module Version: 22.214.171.124
Fault Module Timestamp: 4fed2ec7
Exception Code: c0000094
Exception Offset: 0000000000309132
OS Version: 6.1.7601.2.1.0.400.8
Locale ID: 1043
Additional Information 1: 9930
Additional Information 2: 993087b8a26c90b698b0aaa7c0c9a119
Additional Information 3: 45d8
Additional Information 4: 45d86e82cdfe3714a97bde810a82a78e
Even just starting java.exe -version caused this exception. De-installing all present JDK's/JRE's and installing different (32 bit and 64 bit) versions, did not solve this problem. When we downgraded to a JDK 1.5 version however, the problem did not occur anymore but using a version 1.5 JDK was not a viable option.
The Exception Code: c0000094 is an INT_DIVIDE_BY_ZERO exception, so not much help there in clarifying the problem.
What we tried
There was no traceable change leading to this error.
We tried a clean install of the entire server (Windows reinstallation) and the JVM worked. Also after completely updating Windows, it still worked. We tried this locally with Virtualbox in a Virtual Machine instead of using the image/configuration of the machine on which the problem originally occurred. Multiple environments experienced the same problem. Also based on the below, our estimate is that this error is related to local (customer specific) policies (otherwise undoubtedly Google would have more information on this problem).
We encountered several errors when using Process Monitor; http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
What we saw was that in jvm.dll, different behavior started to occur. We could however not pinpoint the cause of this change of behavior. Decompiling the dll and running it with breakpoints on the server with Visual Studio, was not an option.
When we installed JRockit JDK, the problem was solved. To make the new JDK the default JDK used, several environment settings needed updating. We also use a Tomcat service which needed to be updated to use the new JDK.
First download the JRockit JDK;
Start the installer and specify the installation directory
Don't install Demo's, samples and sources (unless of course you will use them)
Install the public JRE (you might need the JRE some day and not the complete JDK)
Choose a directory to install the JRE
Update environment variables
Right mouse click the Computer icon, Properties (as you can see, I need a new laptop...).
Advanced system properties
Make sure no JAVA_HOME is present in the User variables. If JAVA_HOME is present under user variables, remove it.
If present, update and if not present, create the JAVA_HOME environment variable under System variables. Set it to be equal to the JDK installation directory. In this case; C:\Program Files\Java\jrockit-jdk1.6.0_33-R28.2.4-4.1.0.
Update the Path System variable and set as the first entry the bin directory of the JDK. In this case; C:\Program Files\Java\jrockit-jdk1.6.0_33-R28.2.4-4.1.0\bin. Start a new command prompt (Start, cmd) and give java -version to test the Path variable and the newly installed JDK.
Update Tomcat service
We use Tomcat 6 on the Windows 2008 server. When we changed the JDK, Tomcat wouldn't start anymore when we started it from the Windows Services screen. Tomcat usually autodetects the JDK present on the system based on the JAVA_HOME, but in case of JRockit, this auto setting wouldn't work.
The JVM can be specified manually though. See; http://tomcat.apache.org/tomcat-6.0-doc/windows-service-howto.html
In case of JRockit, the following command updated the service to use the correct JDK;
tomcat6.exe //US//Tomcat6 --Jvm="C:\Program Files\Java\jrockit-jdk1.6.0_33-R28.2.4-4.1.0\jre\bin\jrockit\jvm.dll"
Tomcat6 here is the name of the service. The path to the jvm.dll file might differ depending on the location you specified when installing JRockit
When mysterious JVM errors start to occur when using Windows Server 2008, consider using JRockit and make sure the JVM is known to the programs using it.