Diagnosing crashes in Windows

You generally see a crash either as an unrecoverable exception thrown by Java™ or as a pop-up window notifying you of a General Protection Fault (GPF). The pop-up window usually refers to java.exe as the application that caused the crash. Crashes can occur because of a fault in the Java runtime, or because of a fault in native (JNI) code being run in the Java process.

Try to determine whether the application has any JNI code or uses any third-party packages that use JNI code (for example, JDBC application drivers). If this is not the case, the fault must be in the runtime environment.

Try to re-create the crash with minimal dependencies (in terms of JVM options, JNI applications, or profiling tools).

In a crash condition, gather as much data as possible for the IBM® service team for Java. You should:
  • Collect the Javadump. See Using Javadumps in the J9 VM reference for details.
  • Collect the core dump. See Setting up and checking your Windows environment for details.
  • Collect the snap trace file. See Tracing Java applications in the J9 VM reference for details.
  • Run with the JIT turned off. See Diagnosing a JIT or AOT problem in the J9 VM reference for details. If the problem disappears with the JIT turned off, try some JIT compile options to see if the problem can be narrowed down further.
  • Try adjusting the garbage collection parameters. See Memory management in the J9 VM reference for details. Make a note of any changes in behavior.
  • If your problem is occurring on a multiprocessor system, test your application on a uniprocessor system. You can use the BIOS options on your SMP box to reset the processor affinity to 1 to make it behave like a uniprocessor. If the problem disappears, make a note in your bug report. Otherwise, collect the crash dump.