3 Replies Latest reply on Jun 29, 2010 8:26 AM by 843829

    Access violation at 0x6d801017 in java.exe

      History, so you can guess why it bothers me at all:
      When debugging the C++ part of my JNI application occasionally an error

      First-chance exception at 0x6d801017 in javaw.exe: 0xC0000005: Access violation writing location 0x003e0d00.

      pops up in Visual Studio.
      There's no usable call stack, and it happens occasionally only. Ignoring does not seem to hurt anything.

      By reducing everything suspicious and trying to find the trigger for this access violation, I noticed it does not have anything to do with my native code. I don't need to reference any native method or even load my library at all.
      But it seems to be related to Garbage Collection.

      My test now looks like this:
      public class TestGCException {
           public static void main(String[] args) {
           final static Runtime rt=Runtime.getRuntime(); 
           static String runFinalize() {
                // can be embedded in code or in Expressions window to be run at every debug step
                return "Finalized at " + (new java.util.Date(System.currentTimeMillis()));     
           public static void TestGCOnly() {
                //java.util.Properties sysProps = System.getProperties();
                try { 
                     System.out.print("Press <Enter> after Attach to process javaw.exe :");
                } catch(java.io.IOException iox){};
                System.out.println("Starting Test");
                try {
                     int loops = 5;
                     while (loops-- > 0) {
                          for (int i = 0; i < 100; i++) {
                                    Long l = new Long(123456789);
                                    Long l2 = -l;
                                    l = l2 * 2;  // just to avoid "never read" warnings in Eclipse
                } catch (InterruptedException e) {
                System.out.println(" Done");
      It runs fine, but Visual Studio 2008, when attached, reports about 20 such access violations in those 500 loops.

      If interesting, here are some of the System Properties:
      os.name=Windows XP
      java.vm.name=Java HotSpot(TM) Client VM
      java.vendor=Sun Microsystems Inc. (: that's why I post here :)
      Usually I run it in Eclipse Ganymede, but that behavior also shows up when run from a command prompt like
           java -cp . TestGCException

      Is there more to say than "Ignore that message, and try to avoid (debugging) native code " ?

      Edited by: DataFiddler on Sep 25, 2009 8:45 AM
        • 1. Re: Access violation at 0x6d801017 in java.exe
          I tried the latest jdk version (1.6.0_16) and the java -server option, which both did not make a significant difference:

          "First-chance exception at 0x6db61017 in java.exe: 0xC0000005: Access violation writing location 0x003e0d80."

          I also noticed the -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC options, also without difference.
          I submitted a bug report -without response yet-

          Am I totally wrong, accusing JVM GC as the source of the problem ?
          • 2. Re: Access violation at 0x6d801017 in java.exe
            I have the same problem. I tried several versions of the JVM: update 1, 7, 16 and 17.

            Access violations are raised at what seems to be random times. I tried your repro above and can confirm access violations are raised.

            Because the JVM handles (and swallows) these errors, I can't debug DLL components accessed through JNI in an optimal manner, since this disturbs the VC++ debugger. If my code does an access violation, the debugger won't tell me where - the application just stops, and the debugging session ends.

            Worse, we want to trap all system exceptions in our application in order to make sure we close database connexions properly and release locks, but we can't, as we cannot detect whether an access violation is expected (JVM) or not (our code).
            • 3. Re: Access violation at 0x6d801017 in java.exe
              Same here: First-chance exception at 0x6d801017 in javaw.exe: 0xC0000005: Access violation writing location 0x001d0a00

              Easy to trigger with the jnlp samples Passwordstore or FrameDemo2

              VERY ANNOYING.