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

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

Post by Filmor » Thu, 16 Jun 2005 00:42:02

t 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

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
Data\Sun\Java\Deployment\ 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

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 Here's the
munged version of the "corrupted" file on my system:
#Tue Jun 14 10:36:18 EDT 2005
deployment.javaws.splash.index=C\:\\Documents and
deployment.javaws.splash.cache=C\:\\Documents and
#Java Web Start jre's
#Tue Jun 14 10:36:18 EDT 2005
#Java Plugin jre's
#Tue Jun 14 10:36:18 EDT 2005

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

Post by Rolan » Thu, 16 Jun 2005 02:06:31

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


Check in your Windows registry at
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.5
the value of
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.


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


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

Post by darrel » Fri, 17 Jun 2005 05:14:53

n Tue, 14 Jun 2005, Filmore wrote:

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.

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.

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


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

Post by Cris Fuhrm » Fri, 17 Jun 2005 23:58:35

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:

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 file.

Help fight spam by "educating" the lax, zombie-hosting ISPs: