我只是追加 虚拟机 C:\Program Files\Java\jre6\bin\javaw.exe
在eclipse.ini中，然后我尝试再次启动eclipse，并得到这个错误。告诉我怎么解或者链接能解出来。
这是eclipse。ini
-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize 256m
--launcher.defaultAction
openFile
-vm
C:\Program Files\Java\jre6\bin\javaw.exe
-vmargs
-Xms40m
-Xmx384m
谢谢你！
当前回答
我面对sts 3.8.4同样的问题，所以我尝试了不同的设置，但运气不好， 我重新安装jdk，尝试了，但同样的问题。 最后我下载了sts 3.8.2 n它运行没有任何问题。 使用windows 8, 64位操作系统。 谢谢
其他回答
无论何时看到此错误，请转到Configuration目录并检查刚才生成的日志文件。它应该有适当的异常堆栈跟踪。我的情况是，我安装了一个更新的32位JRE(或JVM)，这是添加到路径的默认Java。我的Eclipse安装是64位的，这意味着它需要一个64位VM来运行它的本机SWT库。因此，我只是卸载了32位JVM，并将其替换为64位JVM。
我想知道他们是否会改进这种报告机制，而不是在某个目录中默默地生成日志文件。
当然，最好不是Eclipse 3.1。Java . x和Java 7。我通过升级到Eclipse 3.8.x解决了这个问题。
当PATH环境变量指向错误的java安装时，就会发生这种情况。
转到您保存Eclipse的文件夹。查看启动日志中的配置文件夹。它会给你一个比“退出代码13”更好的诊断。
In my opinion the most answers here regarding different architectures of Eclipse and Java are simply wrong and this can be easily checked using e.g. Process Monitor under Windows. The -vm option is there to run a specific version of java and the point of it is, that the configured process is started and runs all the Java code on its own, that's why you configure up to java.exe. In that case you DON'T need to have the same architecture for Eclipse and Java, but can happily mix both 32 Bit and 64 Bit. You only CAN'T mix both, if you DON'T use -vm, but let Eclipse load Java natively into its own process using jvm.dll and such. That latter behavior is Eclipse's default, but not the case anymore if you properly configure -vm in eclipse.ini.
如果你不相信我，你可以自己用Eclipse和Java的不同体系结构做一些测试，并正确地配置-vm。最后，这正是提问者在对公认答案的评论中所描述的:
不能运行Eclipse;JVM终止。退出代码= 13
他说64位JDK现在正在工作，但在他的截图中可以看到他的Eclipse是32位的，因为启动器的路径。库是32位的。
And now for the reason I came here: Ony of my customers had some problems loading one of our Eclipse/OSGI based applications as well and Java exited with exit code 13. In the end it showed that the problem was not about -vm or the architectures of Java and eclipse.exe, but instead he was simply missing config.ini and I guess eclipse.exe wasn't aware what to load or such. After we recognized that and put a config.iniback in place, the app loaded fine with using -vm and a 64 Bit JRE7 in combination with a 32 Bit eclipse.exe.
