JDK-6211536 : Java Runtime Enviroment cannot be loaded from .
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_06,5.0,6
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-12-22
  • Updated: 2010-04-02
  • Resolved: 2006-04-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6Resolved
Related Reports
Duplicate :  
JDK-6394635 - The Java Runtime Environment cannot be loaded from <\bin\server\jvm.dll>
Description
Users informed us that during the JRE installation process, they got the following message"Java Runtime Enviroment cannot be loaded from </bin/hotspot/jvm.dll>". Below is a sample of what the user complaints: 

When I download Java Plug In I ge the following,
Java Plug In Fatal Error
Java Runtime Enviroment cannot be loaded from </bin/hotspot/jvm.dll>.
Can you tell me what I'm doing wrong.

###@###.### 2004-12-22 00:49:29 GMT
###@###.### 2004-12-23 16:43:27 GMT
###@###.### 2004-12-23 16:46:24 GMT
Comments
EVALUATION I have tried to reproduce this bug for many times, but never can produce it.Today I used b01,b30 and b76 ,and set the broken jre path in deployment.properties and registry, the installation worked well in every condition. I don't know if someone can reproduce it now. If you can,please export"HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\" and mail it with deployment.properties to me.
24-03-2006
WORK AROUND Remove your deployment.properties file. It is usually located at: c:/documents and settings/$username/Application Data/Sun/Java/Deployment ###@###.### 2005-07-21 16:19:03 GMT
06-06-2005
EVALUATION The problem could be either caused by corrupted registry keys, or incompleted installation. We need more info from the submitter to further evaluate. ###@###.### 2004-12-22 18:48:20 GMT The registry corruption is likely to be caused by missing registry keys: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\<version> HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\<version> ###@###.### 2004-12-24 21:31:41 GMT This bug might be a duplicate of 4922602. The deployment.properties file is not updated properly. We should ask the customer to regenerate their properties file. ###@###.### 2005-1-02 03:20:40 GMT According to the JDC comments, the problem is caused by NtfsDisable8dot3NameCreation registry key being changed, and apparently it causes InstallShield to fail: http://support.installshield.com/kb/view.asp?articleid=Q107182 http://community.installshield.com/archive/index.php?t-56904.html http://community.installshield.com/archive/index.php?t-1070.html Other products using InstallShield also reported similar failure: http://service1.symantec.com/SUPPORT/ent-security.nsf/ppfdocs/2002091810595048?OpenDocument&ExpandSection=5 http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_13615 Reassign to Bill for further evaluation. ###@###.### 2005-03-23 08:42:52 GMT I do not believe this has anything to do with Installshield. The problem is in the CJavaJNI.cpp file, when we are looking for the vm directory. If either of these registries are corrupt: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\<version> HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\<version> or of the jre image is corrupt, an error will occur. There is nothing we can do about this. In 1.4.2, we used to check to see if there was a hotspot directory and default to that. But the hotspot directory was removed in 1.3, so we never should have checked for it. We no longer check for it in 5.0, so I'm going to close this as not reproducible. ###@###.### 2005-06-06 14:33:20 GMT Looking into it further, this seems to be a problem with a corrupt deployment.properties file. In 1.4.2, it pops up the error message: "cannot be loaded from </bin/hotspot/jvm.dll>". In 5.0, it just hangs when it tries to load the applet. The user can resolve this problem by removing the deployment.properties file. We need to find out how the deployment.properties file gets corrupt, and fix that problem. Also, it might be a good idea to validate that the deployment.properties file is valid while loading it, rather than just hanging when the applet tries to load. ###@###.### 2005-07-21 16:19:02 GMT replacing your deployment.properties file with the following will allow you to reproduce. Though, I'm unsure how the deployment.properties file got corrupt: #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= #END OF FILE I've confirmed that this is the line that corrupts the file, and if it is removed, the applet will load correctly: deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre1.5.0_03\\bin\\javaw.exe ###@###.### 2005-07-21 16:21:36 GMT Xiaobin has fixed this problem in 5.0 for when the Java Plugin string in the deployment.properties file is corrupt. The webrev is at: http://javaweb.sfbay.sun.com/~xl116366/webrev/4922602/ However, the problem still exists if the javaws string is corrupt. Even when loading an applet, it still checks the javaws key. I believe the same change should be done in the GetJREKey function of the following javaws file: deploy/src/javaws/share/native/configurationFile.c
22-12-2004