How to Fix Eclipse Exit Code 13: 32-bit vs 64-bit Java on Windows

By the end of this page, you will understand what Eclipse exit code 13 usually means, how 32-bit and 64-bit Java must match Eclipse, how to verify your Java installation on Windows, and how to configure the correct javaw.exe path so Eclipse can start successfully.

Eclipse is a Java-based application, so it needs a compatible Java Runtime Environment (JRE) or Java Development Kit (JDK) to launch.

The key idea behind this error is architecture compatibility:

• A 64-bit Eclipse must run with a 64-bit Java.
• A 32-bit Eclipse must run with a 32-bit Java.
• If they do not match, Eclipse often fails with exit code 13.

In the question, Eclipse is installed in this folder:

C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\

The x86_64 part strongly suggests that Eclipse is 64-bit.

But the Java path being used is:

C:\Program Files (x86)\Java\jre7\bin\javaw.exe

On Windows, Program Files (x86) is typically where 32-bit applications are installed. That strongly suggests the selected Java is 32-bit.

That mismatch is the most likely cause of the error.

Why this matters in real programming:

• IDEs like Eclipse, IntelliJ IDEA, and older Android tooling depend on the local Java installation.
• Build tools, servers, and command-line utilities often fail when the wrong Java version or architecture is used.
• Understanding how to verify runtime paths and system architecture is an essential debugging skill.

So this is not only an Eclipse problem. It is a general lesson in how programs depend on the correct runtime environment.

Think of Eclipse and Java like a plug and a socket.

• A 64-bit Eclipse is a plug shaped for a 64-bit socket.
• A 32-bit Java is a different socket shape.
• Even though both are "Java-related," they do not fit together.

Another way to think about it:

• Eclipse is the car.
• Java is the fuel type it requires.
• If the car needs diesel and you give it petrol, the engine will not start.

Exit code 13 is Eclipse's way of saying, "I found Java, but I cannot run correctly with this one."

When Eclipse needs a specific Java installation, you can point to it with the -vm option.

Core syntax:

eclipse.exe -vm "C:\path\to\javaw.exe"

A more reliable approach is to place the Java path in eclipse.ini instead of editing the shortcut.

Example:

-vm
C:\Program Files\Java\jdk1.7.0_xx\bin\javaw.exe

Important rules:

• -vm must be on its own line in eclipse.ini
• The Java path must be on the next line
• Use javaw.exe, not java.exe
• The Java architecture must match the Eclipse architecture

Example: incorrect setup

Eclipse: C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\
Java:    C:\Program Files (x86)\Java\jre7\bin\javaw.exe

This is likely wrong because:

• x86_64 indicates 64-bit Eclipse
• Program Files (x86) usually indicates 32-bit Java

Example: correct setup

Consider this situation:

Eclipse folder: C:\Program Files\Eclipse-SDK-4.2-win32-x86_64\
Java path:      C:\Program Files (x86)\Java\jre7\bin\javaw.exe

Here is what happens step by step:

1. You start eclipse.exe.
2. Eclipse looks for a Java runtime.
3. Because -vm was provided, Eclipse uses:

   C:\Program Files (x86)\Java\jre7\bin\javaw.exe
   

4. Eclipse begins launching with Java.
5. Eclipse's launcher detects its own architecture:

   -arch x86_64
   

6. The selected Java is likely 32-bit because it is under Program Files (x86).
7. Eclipse and Java do not match.
8. Launch fails, and Eclipse reports:

   Java was started but returned exit code=13
   

Fixed version

If you change the Java path to a 64-bit installation, for example:

C:\Program Files\Java\jre7\bin\javaw.exe

then the sequence becomes:

1. Eclipse starts.
2. Eclipse uses the 64-bit javaw.exe.
3. Java architecture matches Eclipse architecture.
4. The launcher can continue normally.

This concept appears in many real development tasks.

IDE setup

• Eclipse, IntelliJ, NetBeans, and Android Studio all depend on a compatible Java runtime.
• A wrong architecture or wrong path can prevent the IDE from launching.

Build tools

• Maven and Gradle use Java under the hood.
• If JAVA_HOME points to the wrong installation, builds may fail or use the wrong version.

Application servers

• Tomcat, Jetty, and older enterprise servers may fail to start if the configured JVM is missing or incompatible.

Native integration

• Tools that load platform-specific libraries often require architecture alignment.
• A 64-bit app cannot load a 32-bit native library, and vice versa.

CI and deployment machines

• On a build server, a deployment script might break because Java 8 is expected but Java 17 is installed, or because the wrong architecture is used.

The main lesson is that many tools rely on an external runtime, and when startup fails, checking the runtime path and version is one of the first things developers do.

In real projects, developers usually avoid hard-to-debug startup issues by using a few common patterns.

Explicit configuration

Instead of relying on whatever Java happens to be first on the machine, teams often configure the exact runtime path.

Examples:

• eclipse.ini for Eclipse
• JAVA_HOME for build tools
• tool-specific config files for local development

Environment validation

A setup script may check:

• Java is installed
• the version is acceptable
• the architecture matches requirements

Example idea in a batch script:

java -version
if errorlevel 1 echo Java is not installed correctly.

Guard clauses

Developers often fail early when the environment is wrong.

For example:

• stop startup if Java is missing
• print a clear message if the version is unsupported
• refuse to run with a mismatched architecture

Consistent tooling

In teams, it is common to standardize on:

• one JDK version
• one architecture
• one install path convention

This reduces "works on my machine" problems.

Prefer JDK for development

For development tools, many teams use a JDK rather than only a JRE because:

1. Assuming 64-bit Windows means Java is automatically 64-bit

This is a very common mistake.

You can have:

• 64-bit Windows
• 64-bit Eclipse
• but still a 32-bit Java installation

In the question, the Java path is:

C:\Program Files (x86)\Java\jre7\bin\javaw.exe

That strongly suggests 32-bit Java.

2. Using the wrong folder as proof

Beginners often judge only by the download they think they selected.

Instead, verify the actual installed Java by running:

java -version

Look for:

64-Bit Server VM

3. Editing only the shortcut when Eclipse also reads eclipse.ini

Sometimes startup options are duplicated or overridden.

A cleaner setup is often to edit eclipse.ini.

Broken idea:

"eclipse.exe" -vm "some\path\javaw.exe"

This can work, but it is easier to manage in eclipse.ini.

4. Using java.exe instead of

Quick diagnosis

• exit code=13 often means Eclipse and Java do not match
• 64-bit Eclipse needs 64-bit Java
• 32-bit Eclipse needs 32-bit Java

Strong clues on Windows

• C:\Program Files usually means 64-bit
• C:\Program Files (x86) usually means 32-bit
• x86_64 in the Eclipse folder usually means 64-bit Eclipse

Check Java version

java -version

Look for:

64-Bit Server VM

Recommended Eclipse config

-vm
C:\Program Files\Java\jdk1.7.0_xx\bin\javaw.exe

Good rules

• Use javaw.exe
• Put -vm before -vmargs in eclipse.ini
• Keep Java and Eclipse architectures the same
• Prefer a JDK for development

Likely fix for this specific case

Why does Eclipse say "Java was started but returned exit code=13"?

Most often, Eclipse found Java but could not use it because the Java architecture does not match Eclipse, or the configured JVM path is wrong.

How do I know whether my Java is 32-bit or 64-bit?

Run:

java -version

If the output contains 64-Bit Server VM, it is 64-bit.

How do I know whether my Eclipse is 32-bit or 64-bit?

Check the download name or installation folder. A name like x86_64 indicates 64-bit Eclipse.

Is Program Files (x86) always 32-bit?

On 64-bit Windows, that folder is normally used for 32-bit applications, so it is a strong clue that the installed Java is 32-bit.

Should I use a JRE or a JDK with Eclipse?

For development, a JDK is usually better because it includes development tools and is the standard choice for Java IDEs.

Should I configure Java in the shortcut or in eclipse.ini?

eclipse.ini is usually the cleaner and more reliable option.

Can I have both 32-bit and 64-bit Java installed?

Yes. That is why checking the exact path matters. Eclipse may use a different Java installation than the one you expect.

• Java JDK vs JRE — helps explain which Java package is better for development tools.
• Environment variables — useful for understanding JAVA_HOME and path configuration.
• Command-line debugging — important for checking installed versions and executable paths.
• Runtime compatibility — explains why applications must match the correct platform or architecture.
• IDE configuration — relevant because tools like Eclipse often rely on config files such as eclipse.ini.
• File paths on Windows — helps beginners understand Program Files vs Program Files (x86).
• Reading error messages — teaches how to use startup logs and stack traces to diagnose problems.