Minecraft Exit Code 1

Exit code 1 is a Unix convention meaning 'terminated with an error'. Every program on your computer can return it. Minecraft returns it whenever the Java process dies for any reason at all.

So a version mismatch produces exit code 1. A missing library produces exit code 1. Running out of memory, a corrupted download, a graphics driver fault — all exit code 1. The launcher shows you the number because that is all it has; it did not read the log either.

The fix, therefore, is never 'fix exit code 1'. It is to open the log, find the actual error, and fix that. Everything below is about doing so quickly.

Two files matter and they live in different places. The crash report is written when the game dies with a Java-level fault it can describe, and lands in the crash-reports folder. latest.log records everything from the session and exists whether or not a crash report was produced.

Start with latest.log, because exit code 1 frequently occurs without a crash report at all.

On Windows the folder is %appdata%\.minecraft\logs. On macOS it is ~/Library/Application Support/minecraft/logs. If you use Prism, MultiMC or the CurseForge app, the logs are inside that instance's folder rather than the shared one — use the launcher's own log button, which is faster anyway.

Open the file and read from the top for the first line containing ERROR or FATAL or a stack trace. Do not scroll to the bottom.

Modded crashes cascade. One mod fails to initialise, that breaks the registry it was writing to, and thirty other mods then fail because the registry is broken. The bottom of the log is the wreckage. The top has the thing that actually went wrong.

The relevant section is usually within the first fifty lines of the first error. Everything after it is consequence.

This is the most common single cause and it is worth checking first because it takes ten seconds.

Fabric reports it clearly, naming the mod and what it required. Forge and NeoForge often just refuse to start with a message about an incompatible mod set, which is less helpful but points the same direction.

Open the named mod's page, check which Minecraft versions and which loader it supports, and either replace the file with the right build or change your profile to match. A file called something-1.20.1.jar sitting in a 1.21.4 profile will do this every time.

If you recently updated Minecraft, or the launcher updated it for you, this is almost certainly your answer.

Many mods need shared libraries, and the log names the missing one directly, which makes this the easiest cause to fix.

On Fabric, Fabric API is required by most mods and is the usual culprit. Cloth Config provides settings screens. Architectury lets a mod ship for several loaders.

Download the named library from Modrinth, matching your Minecraft version and loader exactly, and put it in the mods folder. Dependencies occasionally have their own dependencies; work down the chain, which terminates quickly.

A subtlety worth knowing: if you have Fabric API installed but built for a different Minecraft version, mods will report it as missing even though the file is visibly there. Check the version, not just the presence.

This one usually appears as java.lang.OutOfMemoryError and behaves differently from the others. The game normally starts fine and dies later, when loading a world or generating new terrain.

The default allocation is 2GB, which handles perhaps forty small mods. A hundred-mod pack wants four to six. Raise it in the launcher's installation settings by editing the JVM arguments and changing -Xmx2G to -Xmx6G.

Do not allocate everything you have. Past roughly two-thirds of physical memory you starve the operating system, and Java's garbage collector performs worse on very large heaps rather than better. On a 16GB machine, 6GB to 8GB is the ceiling worth using.

Minecraft versions need specific Java versions: 21 for 1.20.5 and newer, 17 for 1.18 through 1.20.4, 8 for the 1.16 and 1.12.2 era.

The official launcher bundles the correct runtime, so this rarely bites there. It bites with third-party launchers, or when a system-wide Java installation takes precedence over the bundled one.

The signature is UnsupportedClassVersionError naming a class file version. 65.0 means the mod was built for Java 21. 61.0 is Java 17. 52.0 is Java 8. Match the runtime to the number and the crash stops immediately.

Less common but genuinely does happen, particularly with large mods on unreliable connections.

The signature is an error about a malformed archive, an unexpected end of file, or a zip entry that cannot be read. The mod is present, correctly named, and internally broken.

Delete the file and download it again from the source. If it happens repeatedly with the same mod, try the other platform — most mods publish on both Modrinth and CurseForge.

This is also worth suspecting if you copied a mods folder from someone else over a network share or a messaging app, some of which silently truncate large files.

Occasionally latest.log simply ends, mid-line, with no error at all. That means the Java process was killed rather than crashing — it never got the chance to write anything.

Three things do this. The operating system reclaiming memory under pressure, which points back to allocating too much. Antivirus software terminating Java, which is worth checking if you recently installed security software. And graphics driver faults, which usually leave something in the system event log even when Minecraft's log is silent.

Updating graphics drivers is the cheapest thing to try and resolves a surprising share of these.

If the log points at a class rather than a mod, or names something that turns out to be innocent, bisect rather than reading further.

Move half your mods out of the folder. Launch. If it still crashes, the culprit is in the half that remains; if it starts, the culprit is in the half you removed. Halve the guilty group and repeat.

Twelve launches identifies one mod out of a thousand. In practice you will find it in five or six, and it is far faster than reading a stack trace you do not recognise.

Keep dependencies together when you split — moving Fabric API out will make everything fail and tell you nothing.

Servers produce the same code for a different set of reasons, and the log is in a different place: the server's own logs folder, not your Minecraft directory.

The most common server cause is the EULA. A freshly installed server writes eula.txt with the value false and refuses to start until you change it to true. It prints a clear message about this, but it scrolls past quickly in a console window that closes immediately.

The second is a port conflict. If something else is already using 25565, the server fails to bind and exits. Change the port in server.properties or stop whatever else is holding it.

The third is a mismatch between server-side and client-side mods, though this usually produces a connection error rather than a startup failure. If the server starts and players cannot join, look at the mod lists rather than the exit code.

Three responses to exit code 1 are common and all three waste time.

Reinstalling Minecraft does not help. The problem is in the mods folder, which a reinstall usually leaves intact anyway, and you lose your settings and profiles for nothing.

Deleting the whole mods folder and starting over does technically work, but it throws away the information about which mod was responsible. Bisecting takes five minutes and leaves you knowing something.

Allocating enormous amounts of memory as a first response is counterproductive. If you are not seeing an OutOfMemoryError, memory is not your problem, and over-allocating creates new ones.

The only reliable move is opening the log. Every other approach is guessing, and the log is thirty seconds away.