Bug in javaw.Exe ???

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
LVL 49
Who is Participating?
lcwidingConnect With a Mentor Commented:
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.
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.
DanRollinsAuthor Commented:
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
in the Azureaus directory (in case that means something)

-- Dan
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Giant2Connect With a Mentor Commented:
>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.
I suppose you are so scatterring files that you used the wrong ones together.
Use only ONE JAVA version at a time.
grim_toasterConnect With a Mentor Commented:
--> 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.
--> 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.
lcwidingConnect With a Mentor Commented:

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.
grim_toaster, the fact that you have things well organised is no indication
for the "situation" on other systems.
DanRollinsAuthor Commented:
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
sudhakar_koundinyaConnect With a Mentor Commented:
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

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.
DanRollinsAuthor Commented:
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.
DanRollinsAuthor Commented:
Thanks for all of the help.  I have upped the point level and split the points.
-- Dan
thanks mate :-)
All Courses

From novice to tech pro — start learning today.