The Java Runtime Environment cannot be loaded from <\bin\server\jvm.dll>

Thread view:

Filmore - 14 Jun 2005 16:42 GMT

It happened again to me today on my Windows XP SP2 system. When I tried
to open any Java Applet (tried several that worked before) in Firefox
(or IE), I got the following error in a pop-up window:

The Java Runtime Environment cannot be loaded from
<\bin\server\jvm.dll>

Previously I got around this problem by re-installing the JRE. This
time, it didn't help. Searching with Google revealed lots of people
asking for help on this very issue, but only one of the answers worked
for me:

Delete (or rename) the folder C:\Documents and
Settings\[USERNAME]\Application Data\Sun - it will be recreated
properly when your restarted browser goes back to load an Applet.

In my case, I renamed the folder. I compared the differences, and one
thing I noticed was that the C:\Documents and
Settings\[USERNAME]\Application
Data\Sun\Java\Deployment\deployment.properties file contained outdated
information, regarding installations of JREs I had long since removed.
In the past, re-installing the JRE seemed to fix the problem, but I'm
beginning to believe that I was just lucky. This "corruption" has been
on my system for a long time. Why is the 1.4.2_06 stuff still in this
file (I removed it long ago from my system)? In fact, I have had this
same problem on my machine at work (some OS).

Also, playing with the Java control panel didn't help. It only showed
my 1.5.0_03 JRE installation, since I had uninstalled all the other
versions.

I understand that Java has to run on many platforms and that it's a
challenge. But it seems Sun could/should do a better job with Windows
XP SP2 installs, at least regarding deployment.properties. Here's the
munged version of the "corrupted" file on my system:

#deployment.properties
#Tue Jun 14 10:36:18 EDT 2005
javaplugin.console=hide
deployment.browser.path=C\:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE
deployment.browser.vm.mozilla=true
deployment.javaws.proxy.http=[munged]
deployment.javaws.player.bounds=384,304,512,416
javaplugin.jre.type=JDK
deployment.system.tray.icon=true
deployment.proxy.http.port=8080
deployment.javaws.proxy.httpport=8080
deployment.javaws.proxy.httpproxyoverride=
deployment.proxy.http.host=[munged]
javaplugin.jre.version=1.4.2_06
deployment.console.startup.mode=SHOW
deployment.javaws.player.manager=0
deployment.browser.vm.iexplorer=true
javaplugin.proxy.usebrowsersettings=false
javaplugin.jre.path=C\:\\j2sdk1.4.2_06
deployment.javaws.proxy.setting=NONE
deployment.javaws.whenInstall=0
deployment.javaws.splash.index=C\:\\Documents and
Settings\\[USER]\\Application
Data\\Sun\\Java\\Deployment\\cache\\javaws\\splash\\splash.xml
deployment.javaws.version=javaws-1.4.2_06
deployment.javaws.player.mode=1
javaplugin.exception=true
deployment.version=1.5.0
deployment.javapi.lifecycle.exception=true
deployment.javaws.splash.cache=C\:\\Documents and
Settings\\[USER]\\Application
Data\\Sun\\Java\\Deployment\\javaws\\cache\\splashes\\splash.xml
#Java Web Start jre's
#Tue Jun 14 10:36:18 EDT 2005
deployment.javaws.jre.0.product=1.5.0_03
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.platform=1.5
deployment.javaws.jre.0.path=C\:\\Program
Files\\Java\\jre1.5.0_03\\bin\\javaw.exe
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.osarch=x86
#Java Plugin jre's
#Tue Jun 14 10:36:18 EDT 2005
deployment.javapi.jre.1.5.0_03.path=C\:\\Program
Files\\Java\\jre1.5.0_03
deployment.javapi.jre.1.5.0_03.osname=Windows
deployment.javapi.jre.1.5.0_03.osarch=x86
deployment.javapi.jre.1.5.0_03.args=

Reply to this Message

Roland - 14 Jun 2005 18:06 GMT

> It happened again to me today on my Windows XP SP2 system. When I tried
> to open any Java Applet (tried several that worked before) in Firefox
[quoted text clipped - 22 lines]
> file (I removed it long ago from my system)? In fact, I have had this
> same problem on my machine at work (some OS).

Because this information (i.e. that there's a deployment.properties file
in someone's directory) isn't recorded during the installation of a
JDK/JRE.

> Also, playing with the Java control panel didn't help. It only showed
> my 1.5.0_03 JRE installation, since I had uninstalled all the other
[quoted text clipped - 4 lines]
> XP SP2 installs, at least regarding deployment.properties. Here's the
> munged version of the "corrupted" file on my system:

[snip]

Check in your Windows registry at
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.5
the value of
RuntimeLib
On my system (W2K/JRE1.5.0_03) it is
C:\Program Files\Java\jre1.5.0\bin\client\jvm.dll

Further you might want to have a look at a file called 'jvm.cfg' which
is typically found a *JDK* subdirectory
C:\Program Files\Java\jdk1.5.0\jre\lib\i386
Make sure that the line
-client KNOWN
is the first line in the file.

Signature

Regards,

Roland de Ruiter
` ___ ___
`/__/ w_/ /__/
/ \ /_/ / \

Reply to this Message

Cris Fuhrman - 16 Jun 2005 15:58 GMT

>> This "corruption" has been
>> on my system for a long time. Why is the 1.4.2_06 stuff still in this
[quoted text clipped - 4 lines]
> in someone's directory) isn't recorded during the installation of a
> JDK/JRE.

Yabut it seems that the install *should* update the file, since I didn't
create it and it contains information that's causing problems. Perhaps
the source of the problem is related to the transition from 1.4 to 1.5
and how this file is managed. Anyway, I did some searching and found
that there were similar problems documented in a Sun bug here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4922602

What's disturbing is that the bug says it's closed/fixed. Perhaps the
issues between 1.5.x updates have been fixed, but I still had the
problem with the latest JRE and the outdated info from 1.4.x.

Again, the workaround is to nuke the deployment.properties file.

Signature

Help fight spam by "educating" the lax, zombie-hosting ISPs:
http://pages.infinit.net/filmore/educateYourISP.htm

Reply to this Message

"." - 15 Jun 2005 21:14 GMT

Welcome to the wonderful world of Windows Installer Issues. Every company
I have worked at that tries to do clean installations on Windows ends up
with a bunch of garbage left over. A lot of the Windows installers try to
'share' information by putting it in the registry, "Program Files\common"
or the user's application data directory. The problem is the number of
combinations someone might have for installed products grows
exponentially. After you have shipped four or five versions of a product,
trying to ensure you have tested all possible install/uninstall
combinations becomes more time consuming than testing the acutal product,
on average.

Add to that people who knew the Windows 3.1 install method and never
bothered to learn the latest way. Plus companies that try to support
everything from Windows 95 to Windows XP have to resolve that how you
install on Windows 9x is different from Windows NT and that is different
from Windows 2000/XP.

Bottom line, I have gotten into the habit of cleaning out my machine once
or twice a year. If I uninstall something I scan the computer and the
registry for anything related to it after I uninstall. For example, if I
had 1.4.2_07 installed in C:\java\jdk_1.4.2_07 then I'd do a find in files
on the entire computer for files matching *.* that contain
C:\java\jdk_1.4.2_07 and remove them. Then I'd scan the registry for the
same string and remove those entries as well.

It is not quite that simple however. Sometimes I need to edit the files.
Other times I need to delete more than just one file/key. I might need to
delete a folder. It all depends on the product.

Mind you, I deal with this as part of my job. So I'm paid to know this
stuff. If I worked in any other field I'd scrap the machine.

> Also, playing with the Java control panel didn't help. It only showed
> my 1.5.0_03 JRE installation, since I had uninstalled all the other
[quoted text clipped - 3 lines]
> challenge. But it seems Sun could/should do a better job with Windows
> XP SP2 installs, at least regarding deployment.properties.

Applying service packs occasionally affect installation. Also Microsoft
will sometimes ship something that they claim is the same as applying a
service pack but is not, e.g. Windows 98 SP1 is supposed to be the same as
Windows 98 Second Edition but they are not.

This means that the end user sees:

Windows 98
Windows NT
Windows 2000
Windows XP Home
Windows XP Professional

Most don't realize there are server versions of some of these OS (NT
Server, Windows 2003 Server, etc.). Additionally, there are many different
service packs for each OS as well. On one project I worked on there were
something like 20 different images we worked with but the end user saw it
as 3.

This is my pet peeve about Windows development.

> Here's the munged version of the "corrupted" file on my system:
>
[quoted text clipped - 48 lines]
> deployment.javapi.jre.1.5.0_03.osarch=x86
> deployment.javapi.jre.1.5.0_03.args=

Signature

Send e-mail to: darrell dot grainger at utoronto dot ca

Reply to this Message

The Java Runtime Environment cannot be loaded from <\bin\server\jvm.dll>

Free Magazines