Solved

Bug in javaw.Exe ???

Posted on 2004-10-28
2,028 Views
Last Modified: 2011-10-03
I found myself using an application program that is writtne in JAVA -- it is the U/I for IBM DB2 database management.  The tools worked great at the office, but at home, I kept getting these constant "illegal access in javaw.Exe" crashes.

The program would crash when I did such common things as right-click on something in a tree view to bring up a context menu.  I noticed that when it it did not crash, it sometimes left some part of the screen containing random data -- a block of color at a random part of the screen -- that sort of thing.

I reinstalled several times, yada yada...  then because I figured out that it must be screen-related, I tried something...  I disabled my second video monitor.  Shazaaam!  I stopped getting javaw errors immediately.

Thus, it is my opinion that there is some error in the javaw screen handling that gets broken when it is run in a multiple-monitor environment.

Has anyone heard of this?  Does anyone know of a fix (other than disabling secondary monitors)?

-- Dan
0
Question by:DanRollins
    16 Comments
     
    LVL 4

    Expert Comment

    by:lcwiding
    You did not mention what version(s) of Java you tested this with, as well as what operating systems. It is possible that this could be an issue with the version of DirectX that is installed on your system, as Java will use that, if it is installed, to improve graphics (most things will end up using DirectX, dircetly or indirectly, on the newer OS'es). Or it could be the display driver as well. See if there is a newer display driver available for your system, and if so, if that fixes the problem.

    Scaning through the Snu Java bug database, there are issues with dual monitors, but nothing like this, and some of those sound tied to bad display drivers.
    0
     
    LVL 49

    Author Comment

    by:DanRollins
    Thanks for the input,  lcwiding.
    I agree.. It is almost certainly related to interaction between the java system and the display driver.

    But the point is that no other program I use crashes like that.  So it would surely boil down to a "problem in java" even if I don't have the most recent video drivers.

    As to the version....
    I see that I have three different copies of the file javaw.exe scattered around my hard disk.  NONE of them have a version resource ... which borders on "criminal negligence" in my opinion.

       WinNT\System32                                  45KB   6/3/2004
       Program Files\Java\j2re1.4.2_04\bin       29KB   2/22/2004
       Program Files\IBM\SQLLIB\java\jdk\bin   13KB   4/25/2002

    Since I was running the IBM program, I assume that the oldest of the three files was the one that malfed.  Maybe if I just get rid of that file (or that dir) then a newer version will be used by the IBM software. ... what do you think?

    I run only one other Java program ... Azureaus... and it presumably uses the copy oin WinNT/System I do see a file named
         javaw.exe.manifest
    in the Azureaus directory (in case that means something)

    -- Dan
    0
     
    LVL 12

    Assisted Solution

    by:Giant2
    >NONE of them have a version resource
    To see the version of java you must call the java program passing argument -version (or -v following the older/newer version).
    So, go to each directory where you have java.exe and call:
    java -version

    From your last post seems you have jdk1.4.2_4 (one of the latest SunVersion for Java).
    But you have even an IBM/SQL... and I really believe your IBM program uses this last one.
    So let you see this version of Java.

    I realize these things:
    IBM release its products generally using their own java (IBMVersion). I think you could have in the directory IBM/SQL... an IBMVersion of Java or a SUNVersion maybe not really good with your double screen environment.

    The solution I see is to try and use the latest version of SUNJava (1.4.2_05 or 1.5).
    If the error is the same, try to use the IBMVersion (in IBM/SQL...).
    If the error is the same (hope it isn't) try to reinstall the JavaSun (and/or the JavaIBM) and retry the previous 2 try.
    If the error is the same... I believe there is no solution.

    Hope this could help you.
    Bye, Giant.
    0
     
    LVL 24

    Expert Comment

    by:sciuriware
    I suppose you are so scatterring files that you used the wrong ones together.
    Use only ONE JAVA version at a time.
    ;JOOP!
    0
     
    LVL 7

    Assisted Solution

    by:grim_toaster
    --> Since I was running the IBM program, I assume that the oldest of the three files was the one that malfed.  Maybe if I just get rid of that file (or that dir) then a newer version will be used by the IBM software. ... what do you think?

    Bad idea, the most likely problem is that your machines PATH environment variable has been set up to have the windows one before the others, therefore the windows one will be used (or one of the others, installers tend to place their paths in random ordering).

    What I would suggest, is run the "java -version" command from a standard DOS prompt (in a folder that does not have a java in it, e.g. c:\), on your work and your home machine to see which one each is using.  If the versions are the same then you've got problems, however, if not then you will need to ensure that the location of the correct jvm is before all of the others in that path environment variables.
    0
     
    LVL 7

    Expert Comment

    by:grim_toaster
    --> Use only ONE JAVA version at a time.
    Not true, I've got 7 different versions on my machine (for various testing purposes).  Provided, that the default one is the first one in your path, and you reference all of the others by full path then everything will be fine.
    0
     
    LVL 4

    Assisted Solution

    by:lcwiding
    Dan,

    I agree with you about the lack of version resources in the executable files. They finally changed that with version 1.5.

    That said, as Giant2 recommended, use "java -version" in each directory, assuming that there is a "java.exe" in the same folder as the javaw.exe. You cannot go by the file dates, as that ismore often the date the file was placed there, or if it was installed by another application, a date they specified.

    I won't disagree that this could well be a java problem, but I have seen issues with display drivers that only some applications encounter. I cannot say for certain why your application would encounter this issue when other Java applications do not.

    As for having mutliple versions of Java installed, that is not a problem. I usually have 8+ versions installed on my system, because of testing requirements. Each release looks to the Windows registry to correctly locate the files for that particular Java release, so the only issue is making sure which version is launched.
    0
     
    LVL 24

    Expert Comment

    by:sciuriware
    grim_toaster, the fact that you have things well organised is no indication
    for the "situation" on other systems.
    ;JOOP!
    0
     
    LVL 49

    Author Comment

    by:DanRollins
    The java.exe in System32 is

    C:\WINNT\system32>java -version
    java version "1.4.2_05"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
    Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)

    The one in the IBM directory is:
    C:\Program Files\IBM\SQLLIB\java\jdk\bin>java -version
    java version "1.3.1"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1)
    Classic VM (build 1.3.1, J2RE 1.3.1 IBM Windows 32 build cn131-20020403 (JIT ena
    bled: jitc))

    The one that starts from a random directory is the 1.4.2_05 one

    The one that is running when the IBM U/I is up is the one in the IBM directory (I verified this by right-clicking javaw.exe in Task Manager and choosing "Debug"  The VisualStudio debugger shows -- as expected -- that java-related DLLs are loaded from the IBM bin dir).

    When I run my other Java-based app, the
         C:\Program Files\Java\j2re1.4.2_04\bin\javaw.exe
    is the one that is active.

    =-=-=-=-=-=-=--=-=-=
    Is there a safe way to force the IBM software to use the more recent version of the Java VM?

    -- Dan
    0
     
    LVL 14

    Assisted Solution

    by:sudhakar_koundinya
    Normal Procedure Dan

    set path=%path%;  C:\Program Files\Java\j2re1.4.2_04\bin;

    set JAVA_HOME=C:\Program Files\Java\j2re1.4.2_04

    set classpath%classpath%; C:\Program Files\Java\j2re1.4.2_04\jre\lib\rt.jar;

    >>C:\Program Files\Java\j2re1.4.2_04\jre\lib\rt.jar
    may be  C:\Program Files\Java\j2re1.4.2_04\lib\rt.jar so check  the correct path and execute the application
    0
     
    LVL 4

    Expert Comment

    by:lcwiding
    Dan,

    When launchig the IBM U/I, how is that done? And is the IBM javaw.exe in the same directory as the jar for the U/I? If so, you will probably want to also renam that javaw.exe to __javaw.exe in addition to setting the path as sudhakar recommended. You might also want to set the default application for JAR files in widows explorer to the 1.4.2_05 JRE by right clicking on a JAR file in windows explorer, select open with..., and browse for the 1.4.2_05 javaw.exe program.
    0
     
    LVL 49

    Author Comment

    by:DanRollins
    The IBM programs, such as DB2 Control Center, are launched by a sort of maze of batch files... but it looks like they end up at a command like:

       db2javit -j:CC -s: -i: -l: -o:"-Xmx128m -Xms32m" -a:"%1 %2 %3 %4 %5 %6 %7 %8"

    and  db2javit.exe is in the
         C:\Program Files\IBM\SQLLIB\BIN
    directory where that old version of javaw.exe exists.  I think that it is setting the environment and launching the app becasue even if I set the path, the older javaw.exe is the one that gets executed.

    =-=-=-=-=-=-=-=-=-=-=-=-=
    The good news is that the problem seems to have disappeared -- though it was a reliable (repeatable) error when I asked this question.
    0
     
    LVL 4

    Accepted Solution

    by:
    Given what you have found, it is good to hear the problem seems to have gone away. The only way to change the JRE that is launched might bo to do as I suggested, which is to rename the old javaw.exe, and perhaps copy one of the newer ones into this folder.

    The other possiblity is that something else that was run on the system, either at the same time or just before, you launched the IBM applicatino may have put the system into a state that caused the error. This could be especially true with an application that makes strong use of DirectX, like a game or advanced graphics or video package.
    0
     
    LVL 49

    Author Comment

    by:DanRollins
    Thanks for all of the help.  I have upped the point level and split the points.
    -- Dan
    0
     
    LVL 14

    Expert Comment

    by:sudhakar_koundinya
    thanks mate :-)
    0
     
    LVL 12

    Expert Comment

    by:Giant2
    :)
    0

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Lean Six Sigma Project Manager Certification

    There are many schools of thought around successful project management, but few as highly regarded as the Six Sigma and Lean methods. With 37 hours of learning, this training will explain concrete processes for increasing efficiency and limiting wasted time and effort.

    An old method to applying the Singleton pattern in your Java code is to check if a static instance, defined in the same class that needs to be instantiated once and only once, is null and then create a new instance; otherwise, the pre-existing insta…
    This was posted to the Netbeans forum a Feb, 2010 and I also sent it to Verisign. Who didn't help much in my struggles to get my application signed. ------------------------- Start The idea here is to target your cell phones with the correct…
    Viewers learn about the third conditional statement “else if” and use it in an example program. Then additional information about conditional statements is provided, covering the topic thoroughly. Viewers learn about the third conditional statement …
    This tutorial covers a practical example of lazy loading technique and early loading technique in a Singleton Design Pattern.

    913 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    14 Experts available now in Live!

    Get 1:1 Help Now