What does this error mean?

What it means

Only one program at a time can listen on a given TCP port. Something else on this machine already owns port 25565 (or whatever server-port is set to), so the new server process cannot claim it and shuts down immediately. Nine times out of ten the culprit is a previous copy of the same server that never fully exited.

How to fix it

• Look for a leftover server first. Check Task Manager for a java.exe or javaw.exe process and end it. A window closed with the X button rather than the stop command often leaves one running.
• Find the owner on Windows: run netstat -ano | findstr :25565 in Command Prompt. The last column is the PID - match it in Task Manager's Details tab.
• Find the owner on Linux: sudo ss -lptn 'sport = :25565'.
• Or move the server. Change server-port in server.properties to something free like 25566, forward the new port, and have players connect with your-ip:25566.

This is the same underlying situation as COAL-015, reported by a different part of the startup sequence.

What it means

On startup the server claims its port so it can accept connections. This message means the claim was refused. Almost always that is because another process already holds the port - see COAL-002 for finding and freeing it - but two other causes are worth knowing.

How to fix it

• Something else has the port. The common case: kill the leftover java process, or change server-port.
• The configured server-ip does not exist on this machine. If it is set to an address this machine does not hold - a public IP on a NATed VPS, or a stale LAN address - the bind fails. Leave server-ip blank; that is the correct value for nearly every server and means "listen on everything".
• Permission on a low port. On Linux, ports below 1024 require root. Stay on 25565 or another high port.

This error is about the local machine only. If the server starts fine and players still cannot connect, that is a port forwarding problem instead - see the port forwarding guide.

What it means

The server asked Java for more memory and there was none left inside the heap it was given at startup. This is not about how much RAM your machine has - it is about the ceiling set by the -Xmx flag the server was launched with. Once the server reaches that ceiling the JVM throws this error, and the server usually dies within seconds.

It shows up in one of two situations: the allocation was simply too small for the pack and player count, or a mod is leaking memory and would eventually fill any allocation you gave it.

How to fix it

• Raise the allocation. Rough guide: 2-3 GB for vanilla with a few friends, 4-6 GB for a light mod list, 8 GB or more for a large modpack. In Coalstack that is the Memory Allocation slider on the Server page's Performance tab; by hand it is the -Xmx6G value in your start script.
• Do not allocate everything. Leave at least 2 GB for the operating system. Giving an 8 GB machine an 8 GB heap makes crashes more likely, not less.
• Check whether it climbs back up. If the server runs out again a few hours after every restart no matter how much you give it, that is a leak in a mod rather than an allocation problem. A healthy server's memory use sawtooths as garbage collection runs; a leaking one only ever goes up.
• Suspect the heavy mods first. World-generation mods, dynamic maps, and chunk pregenerators are the usual causes. Remove recently added ones one at a time.

If you are running 32-bit Java you cannot allocate more than roughly 1.5 GB no matter what you set - install a 64-bit JDK, which the Java version guide walks through.

What it means

This happens before Minecraft even loads. The JVM tries to reserve the whole heap up front, the operating system refuses, and Java exits instantly. Note the difference from COAL-001: there the server ran and later filled its heap, here it never started because the heap could not be handed out in the first place.

How to fix it

• Lower the allocation to something the machine can actually spare. On 8 GB of RAM, ask for 4-6 GB, not 8.
• Close other memory users - a Minecraft client on the same machine easily takes 2-4 GB by itself.
• Check you are on 64-bit Java. Run java -version; if it does not say 64-Bit, that is your ceiling, and no amount of free RAM will get you past roughly 1.5 GB.
• On a VPS, check the plan's real memory. A 2 GB instance cannot host a 4 GB heap even though the numbers look close.

What it means

This is a level below a normal Minecraft crash: the Java process died at the native level, so there is no Java stack trace and no crash report. On Windows the same thing appears as EXCEPTION_ACCESS_VIOLATION. The causes are native code (a mod shipping its own compiled library), a faulty JVM install, or failing hardware.

How to fix it

• Open the hs_err_pid*.log the message points to. The "Problematic frame" line near the top names the library that crashed - if it is a .dll or .so belonging to a mod, that is your answer.
• Update or reinstall Java. Use a current LTS build (Temurin 17 or 21, matching your Minecraft version). A half-installed or very old JVM causes this more often than people expect.
• Remove recently added mods one at a time, starting with anything that does hardware-adjacent work.
• If the crash moves around at random, test your RAM with MemTest86. A native crash with no consistent frame is a classic bad-memory symptom, especially on a machine that also misbehaves outside Minecraft.

What it means

Mods declare what they need. This message is the loader listing the requirements it could not satisfy, and it is unusually helpful: each row names the mod that is missing (Mod ID), the mod that wants it (Requested by), the version range that would work (Expected range), and what is actually installed (Actual version, where [MISSING] means nothing at all).

How to fix it

• If Actual version is [MISSING], install the named mod. Search the Mod ID on Modrinth or CurseForge and take the build for your exact Minecraft version and loader.
• If a version is listed but out of range, you have the right mod at the wrong version - update or downgrade it into the expected range.
• Or remove the requesting mod if you do not actually want it. The Requested by column tells you which one to pull.
• Fix every row before restarting. The list is complete, so there is no reason to discover the next one on the next boot.

The Fabric equivalent of this message is COAL-019.

What it means

Fabric Loader checked your mod set, decided it could not be loaded, and stopped. This exception is the stop itself, not the reason. Fabric always prints the reason in plain English immediately above this line - a missing dependency, a version conflict, or a duplicate mod.

How to fix it

Scroll up until you find the human-readable block Fabric printed just before this. It normally reads as a bullet list of unmet requirements, sometimes followed by a suggested fix. Work from that, not from this exception. The likely targets:

• COAL-019 - a mod requires a version of another mod that is missing
• COAL-018 - Fabric printed a solution you can follow verbatim
• COAL-008 - the same mod installed twice

What it means

Every mod claims a unique ID, and two files in the mods folder are claiming the same one. The loader will not guess which you meant. In practice this is either an old version you forgot to delete when updating, or the same jar downloaded twice under names like somemod.jar and somemod (1).jar.

How to fix it

• Delete the older jar. The error names both files - keep the newer, remove the other.
• Sort the mods folder by name and look for near-identical pairs and any (1) suffixes. Dragging in an update without deleting the old jar is the most common way to land here.
• Check for a nested copy. A mod shipped inside a modpack plus one you installed manually counts as two.
• Never rename a jar to disable it. Renaming to somemod.jar.disabled works; renaming to somemod-old.jar leaves it fully active.

What it means

Code tried to use a class that was not on the classpath when it ran. The class name after the colon is the missing piece and the most useful thing on the line - read it before anything else. A path starting with net/minecraft/client/ means a mod is reaching for client-only code that a dedicated server does not ship at all.

How to fix it

• If the class is under org/lwjgl, you have a client-only mod on the server - COAL-017 covers that case in full.
• If it is under net/minecraft/client, same story: the mod named in the stack trace below the error is client-side only. Remove it from the server's mods folder.
• Otherwise it is a missing library. The package name usually gives away which mod owns it - install that library mod at a version matching your Minecraft version.
• Check for a version mismatch. A class that exists but moved between versions produces this too, so make sure every mod targets your exact Minecraft version.

What it means

A class was requested by name and the loader could not find it. For server troubleshooting this is the same situation as COAL-009 - the difference is only in how the lookup was made, and it very often appears as the Caused by: line underneath one.

How to fix it

Fix it as you would COAL-009: work out what the missing class belongs to, then install the mod or library that provides it, at a version matching your Minecraft version and loader.

• A package under net/minecraft/client or org/lwjgl: a client-only mod is on the server.
• A recognisable library name: install that library mod.
• A mod you just updated: it likely needs a newer version of one of its dependencies.

What it means

Mixin is how most modern mods modify Minecraft: at load time they patch specific methods in the game's own code. Those patches are written against one exact version. If the method moved, changed shape, or vanished - because you are running a different Minecraft version than the mod was built for - the patch cannot be applied, and the mod aborts the launch rather than run half-patched.

How to fix it

• The mod ID is in the message - somemod in the example above. That is your culprit; there is no need to bisect the mod list.
• Check its supported Minecraft version on Modrinth or CurseForge and install the build for your server's exact version. "Works on 1.21" is not the same as 1.21.1.
• Update its dependencies too. When a mod mixes into another mod's code rather than Minecraft's, an outdated copy of that other mod produces the same failure.
• If two optimisation mods are fighting over the same method, removing one usually resolves it - a common outcome between competing performance mods.

What it means

LWJGL is the library Minecraft uses to talk to your graphics card. A dedicated server renders nothing, so it does not ship LWJGL at all. When a mod that only makes sense on a client - a rendering or optimisation mod, a shader loader, a HUD mod - is placed in the server's mods folder, it immediately reaches for LWJGL and the server dies on startup.

This is not a broken mod or a broken server. It is a mod in the wrong place.

How to fix it

Remove the client-only mod from the server's mods folder. It still works fine - install it in your own Minecraft client instead, where it belongs. The stack trace under the error names the mod; in the example above, Sodium.

Client-only mods that most commonly end up on a server by mistake:

• Rendering and performance: Sodium, Rubidium, Embeddium, Iris, Oculus, OptiFine
• Shaders: every shader pack, and the loaders that run them
• Visual and HUD: minimap mods, zoom mods, tooltip and inventory HUD mods, animation and particle mods
• Resource pack helpers: anything whose description is about how the game looks

Not sure about a specific mod? Its Modrinth or CurseForge page states the environment - look for "client" versus "server" on the listing. Mods marked client-side only never need to be installed on the server, even when every player uses them.

What it means

When Fabric Loader rejects a mod set it also tries to compute a fix, and when it succeeds it prints this block. It is the most useful thing in a Fabric startup failure - not a diagnosis to interpret, but an instruction list. Coalstack's Auto Debugger surfaces it verbatim for exactly that reason.

How to fix it

• Do what it says, exactly. Version numbers are part of the instruction - "0.92.2 or later" means 0.92.1 will not do.
• Do every line before restarting. The list is one coherent solution, not a set of alternatives to try in turn.
• Match your Minecraft version when downloading. Mod pages list a separate build per game version, and only the one matching your server is relevant.
• "Remove mod X" is a real option. If the suggestion is to remove something you do not care about, that is the fastest fix available.

If Fabric could not determine a solution you will see COAL-019 instead, which lists the unmet requirements without the fix.

What it means

Fabric Loader is listing an unmet requirement, and the line contains everything you need: which mod is complaining (Some Mod), what it needs (fabric-api), and which versions would satisfy it (0.92.0 or later). "Missing" can mean not installed at all, or installed at a version outside that range.

How to fix it

• Install the named mod at a version inside the stated range, built for your exact Minecraft version. fabric-api is by far the most common one to be missing - a large share of Fabric mods depend on it.
• If it is already installed, update it - and delete the old jar rather than leaving both, or you will land on COAL-008 next.
• Or remove the requesting mod if you would rather not add the dependency.
• Expect several of these at once. Read the whole list and fix every line before restarting.

What it means

Something failed during startup and nothing caught it, so Java printed the stack trace and quit. On its own this line tells you almost nothing - it is the outermost wrapper around whatever actually went wrong. The real cause is either further down the trace, after a Caused by: line, or in the log lines immediately above it.

How to fix it

• Read up, not down. Scroll to the last few lines before this one. Mod loaders print their real complaint - a missing dependency, a version mismatch - just before the exception escapes.
• Follow every Caused by: to the end of the chain. The last one is usually the actual fault.
• Check the common specific causes that arrive wrapped in this: a missing dependency, a client-only mod, or an unaccepted EULA.

Coalstack's Auto Debugger exists largely for this case - it scans the whole log and reports the specific finding instead of the wrapper.

What it means

The server crashed mid-tick while updating the world - blocks, entities, and block entities all update inside that tick. Because it happens during normal running rather than startup, the trigger is usually specific data in the world: one corrupted chunk, one broken entity, or one block entity a mod cannot handle.

How to fix it

• Read the crash report's "Affected level" block. It names the exact block or entity position, which tells you the chunk to deal with.
• If it crashes on join, it is where that player is standing. A player logged out inside a crashing chunk re-crashes the server on every login. Move them with an offline NBT editor, or teleport them from the console in the moment before the crash.
• Regenerate just the bad region. Tools like MCA Selector let you delete a single region file so it regenerates on next load - far less destructive than restoring the entire world.
• If it started right after a mod change, remove that mod first. Mods adding entities or machines are the usual source.
• Otherwise restore a backup from before the crashes began.

What it means

Java ran out of call stack, which in practice always means infinite recursion: something called itself, directly or in a loop, with nothing to end it. The giveaway is the stack trace - the same handful of lines repeat hundreds of times.

How to fix it

• Read the repeating frames. The package name in the loop tells you which mod, data pack, or script owns the bug.
• Data pack functions are a frequent cause: a function that calls itself, or two that call each other, with no condition to stop. Check anything added recently under datapacks/.
• Automation and scripting mods loop the same way when one event triggers another - a block-break handler that breaks a block, for instance.
• Raising -Xss is not a fix. A deeper stack only delays a genuine infinite loop. Find the recursion instead.

What it means

A healthy server completes 20 ticks a second. The watchdog is a separate thread that notices when a single tick has run far past its budget - 60 seconds by default - and concludes the server is hung rather than slow. It then kills the process and dumps the thread stacks. This is not a performance warning: a tick that long means something is genuinely stuck.

How to fix it

• Read the thread dump printed with the crash. The Server thread's stack shows exactly what it was doing when it froze - the topmost mod package in that trace is what to investigate.
• Chunk generation is the usual innocent cause. A player exploring new terrain with heavy worldgen mods can stall a tick past 60 seconds on a slow disk. Pregenerating the world fixes that properly.
• Deadlocks are the usual guilty one. If the dump shows threads waiting on each other, that is a bug in the named mod - report it, and remove the mod meanwhile.
• Do not simply disable the watchdog. Setting max-tick-time=-1 in server.properties stops the kill, not the freeze - the server then sits there unresponsive instead. It is a reasonable temporary measure while you pregenerate, and a bad permanent one.

What it means

A file did not contain what the server expected - truncated, half-written, or invalid. The overwhelming cause is an unclean shutdown: killing the process, closing the window, or losing power mid-save leaves a region file written halfway. Disk problems and running out of free space account for most of the rest.

How to fix it

• Identify the file from the message. A .mca file is world data, level.dat is world metadata, and anything in a mod's config folder is usually safe to delete and let regenerate.
• For level.dat, Minecraft keeps level.dat_old right beside it. Renaming that over the broken one recovers most cases without touching your world.
• For a region file, restore just that file from a backup, or delete it and let the chunk regenerate - you lose the builds in that region, not the world.
• For a mod cache or config, delete the folder (not the jar) and let the mod rebuild it.
• Then fix the cause. Always stop the server with the stop command rather than by closing the window, and keep automated backups running so the next occurrence costs you minutes instead of the world.