How To Read A Minecraft Crash Report

When your Minecraft server crashes, it generates a crash report file. This file contains everything you need to know about what went wrong: the error, the system state, the loaded mods/plugins, and the exact line of code that failed.

Crash reports look intimidating because they include a lot of technical text. Most server owners scroll through them, see "Java something something Exception," and give up. But once you know what to look for, a crash report tells you exactly which mod, plugin, or config caused the crash and how to fix it.

This guide teaches you how to read Minecraft crash reports systematically. By the end, you will be able to identify the cause of any common crash and know what to do next.

Where crash reports live

When your server crashes, Minecraft writes a crash report to:

your-server-folder/crash-reports/crash-2026-05-15_14.23.45-server.txt

The filename includes the date and time. The most recent crash report is the one for your most recent crash.

If you are using Server Heron's panel, you can find crash reports in the file manager under /crash-reports/ and view or download them directly.

If your server keeps crashing on startup and never gets to write a crash report, the relevant information is usually in logs/latest.log instead. Same diagnostic principles apply.

The structure of a crash report

Every Minecraft crash report has the same basic sections, in this order:

Header - timestamp, brief description, joke comment
Exception and stacktrace - the actual error
Detailed walkthrough - additional context for the error
System details - Minecraft version, Java version, OS, memory, JVM flags
Loaded mods/plugins - everything currently active (modded only)
World/level details - world name, dimension, coordinates if relevant

Most of the diagnostic value is in sections 2 and 5. Let us focus on those.

How to read the exception

The exception is the most important line in the entire crash report. It tells you what type of error occurred.

Example:

java.lang.OutOfMemoryError: Java heap space

The structure is:

java.lang.OutOfMemoryError - the type of exception
Java heap space - the specific message

Common exception types and what they mean:

java.lang.OutOfMemoryError
The server ran out of allocated RAM. Either you allocated too little RAM for your modpack, or you have a memory leak from a bad mod, or your view distance / chunk loading is too aggressive.

java.lang.NullPointerException (or NPE)
Code tried to use something that did not exist (a null reference). Usually caused by a mod or plugin bug. The stacktrace will tell you exactly which mod.

java.lang.StackOverflowError
A function called itself too many times (infinite recursion). Often caused by mod conflicts or recursive event handlers.

java.util.ConcurrentModificationException
Two threads tried to modify the same data at the same time. Usually a plugin doing something async that should be sync.

java.lang.NoClassDefFoundError or java.lang.ClassNotFoundException
A mod or plugin tried to use a class that does not exist. Usually means you have a mod for the wrong Minecraft version, or a missing dependency.

java.lang.NoSuchMethodError
A mod tried to call a method that does not exist in the version of another mod. Almost always a version mismatch between mods.

java.lang.IllegalArgumentException
Code passed bad data to a method. Often caused by corrupted world data or bad config values.

The exception type is your first clue. The message gives you more context.

How to read the stacktrace

Below the exception is the stacktrace, a list of method calls showing how the error happened.

Example:

java.lang.NullPointerException: Cannot invoke "net.minecraft.world.entity.player.Player.getInventory()" because "player" is null
    at com.example.somemod.SomeModEvent.onPlayerJoin(SomeModEvent.java:142)
    at net.minecraftforge.eventbus.EventBus.post(EventBus.java:303)
    at net.minecraft.server.players.PlayerList.placeNewPlayer(PlayerList.java:201)
    at net.minecraft.server.network.ServerLoginPacketListenerImpl.handleAcceptedLogin(ServerLoginPacketListenerImpl.java:122)

Read this from top to bottom. The first line under the exception is where the error actually happened. In this case:

com.example.somemod.SomeModEvent.onPlayerJoin(SomeModEvent.java:142)

This tells you:

The mod responsible: com.example.somemod (the package)
The class: SomeModEvent
The method that crashed: onPlayerJoin
The exact line in the source code: SomeModEvent.java:142

The mod's package (the dotted name) usually matches its name. com.example.somemod would be a mod called "Some Mod" or similar. You can search the mod list section of the crash report to confirm which mod this is.

The lines below at com.example... show what called this method. They are useful for context but the top line is what matters.

How to read the mod list

The crash report includes a section listing every mod (Forge/Fabric) or plugin (Bukkit/Spigot/Paper) currently loaded.

Example:

-- Loaded Mods --
Details:
    | State   | ID         | Version       | Source         |
    |---------|------------|---------------|----------------|
    | LCHIJA  | minecraft  | 1.21.4        | client.jar     |
    | LCHIJA  | forge      | 51.0.33       | forge.jar      |
    | LCHIJA  | jei        | 19.21.0.247   | jei.jar        |
    | LCHIJA  | somemod    | 1.0.5         | somemod.jar    |

The state column tells you the mod loading state. LCHIJA is the normal "fully loaded" state. Anything else (especially E for error) is suspicious.

If your stacktrace pointed to com.example.somemod.SomeModEvent, you find somemod in this list. That confirms the version (1.0.5) which you can use to check for known issues or find the source code.

For Forge mods, you can usually find the source on the mod's GitHub or CurseForge page. Search for the line number in the crash report against the source code to see what was happening.

How to read system details

The system details section gives you the environment context:

-- System Details --
Details:
    Minecraft Version: 1.21.4
    Java Version: 21.0.2
    Java VM Version: OpenJDK 64-Bit Server VM
    Memory: 234234 / 8589934592 bytes
    JVM Flags: 14 total; -Xmx8G -Xms2G -XX:+UseG1GC ...

Key things to check:

Java version:
Many modern modpacks need Java 17 or 21. If you are running Java 8 or 11 with a modpack designed for Java 21, you will get crashes.

Memory:
The format is used / total bytes. To convert: divide by 1073741824 to get GB.

In the example, 234234 / 8589934592 bytes means 0.0002 GB used out of 8 GB allocated. This is the moment of crash, not normal usage. For OOM crashes, the "used" number will be very close to the "total" number.

JVM flags:
Check that flags like -Xmx (max heap) match what you intended. If you set 8 GB but the flags say -Xmx2G, your start command is overriding your panel setting.

Common crash patterns and how to fix them

Pattern 1: OutOfMemoryError

Symptom: Crash report exception is java.lang.OutOfMemoryError: Java heap space

Cause: Server ran out of RAM.

Fix:

Allocate more RAM (use our RAM lookup guide to size correctly)
Lower view distance and simulation distance
Reduce mob caps
Check for memory leaks (run /spark heap and look for unusually large object counts)

Pattern 2: Crash on startup mentioning a specific mod

Symptom: Server crashes within seconds of starting, stacktrace points to one specific mod

Cause: Mod incompatibility, bad mod version, or missing dependency.

Fix:

Check the mod's CurseForge/Modrinth page for known issues
Verify you have all required dependencies
Try removing the mod and starting again
If the mod is essential, check if there is a newer version

Pattern 3: Crash when a player does a specific action

Symptom: Server crashes only when a player joins, opens a specific GUI, or interacts with a specific block

Cause: Bug in a specific mod's event handling.

Fix:

Note the specific action and mod from the stacktrace
Search for that mod + crash on Google or the mod's issue tracker
Often a known bug with a known workaround

Pattern 4: Crash with corrupted world data

Symptom: Stacktrace mentions chunk loading, NBT data, or IllegalArgumentException related to a region file

Cause: Corrupted world save (often from an unclean shutdown)

Fix:

Restore from a backup (your panel should have daily backups configured)
Use a tool like MCEdit or Region Fixer to repair the corrupted region file
If you cannot restore, identify the bad chunk by coordinates and delete just that chunk file

Pattern 5: Plugin conflict crash

Symptom: Stacktrace mentions multiple plugins interacting

Cause: Two plugins both trying to handle the same event in incompatible ways.

Fix:

Disable plugins one by one to find the culprit pair
Check both plugins' issue trackers
Update both to latest versions
If conflict persists, use a different plugin for one of the functions

Tools that help you read crash reports

Mclo.gs
Paste your crash report or log to https://mclo.gs/ for a sharable link. Useful when asking for help on Discord or forums.

Crash Report Analyzer (mod)
Some Forge/Fabric mods analyze crash reports automatically. Useful but not always accurate.

Spark
Not for crashes, but for ongoing diagnosis. If your server is crashing repeatedly, run Spark to find what is eating memory or CPU before the crash.

Search engines
Copy the exception line plus any specific mod name into Google. Most common crashes have been encountered and solved before.

When to ask for help

If you cannot identify the cause from the stacktrace, the next step is to ask for help. Include:

The full crash report (paste to mclo.gs and share the link)
What you were doing when it crashed
Whether it crashes consistently or randomly
Your mod/plugin list and versions
Any recent changes (added mods, updated versions, changed configs)

Where to ask:

Server Heron Discord - our team helps with crashes for all customers as part of standard support
The mod's GitHub issues page - if you identified a specific mod
r/admincraft - Reddit community for server admins
Spigot or Paper forums - for plugin-related crashes

Do not just paste a crash report and ask "why?" Include context. The more information you give, the faster someone can help.

Common mistakes when debugging crash reports

Looking only at the bottom of the stacktrace.
The bottom is usually the Minecraft engine code (net.minecraft.*). The actual cause is at the top, in the mod or plugin code.

Assuming the most recent change is the cause.
Sometimes a change you made weeks ago was actually fine but combined with today's update creates a crash. Look at all changes, not just the most recent.

Reinstalling everything as a first response.
Reinstalling rarely fixes a crash. Identify the cause first, then take targeted action.

Ignoring the exception type.
The exception type (OOM, NPE, etc.) tells you the category of problem. Ignoring it makes diagnosis much harder.

Not keeping crash reports.
Save your crash reports. If a crash recurs in 6 months, having the old report makes diagnosis instant.

A short FAQ

Can I prevent crashes entirely?
No, software has bugs. But you can reduce crash frequency by keeping mods/plugins updated, allocating proper RAM, running stable Minecraft versions, and avoiding experimental mod combinations.

My modpack crashes on startup with no error in chat. Where do I look?
Check logs/latest.log for errors that happened during startup. Crash reports are sometimes not generated for startup crashes.

Should I report every crash to the mod author?
Only if you can reproduce it consistently and have a clean stacktrace. Random one-time crashes are rarely actionable for mod authors.

My server crashes with no crash report at all.
Likely the server killed the JVM (out of memory) before it could write the report. Check for OutOfMemoryError messages in logs/latest.log or your console.

Can a crash report be wrong about which mod caused the crash?
Sometimes. The stacktrace shows where the crash happened, not always the root cause. A bug in mod A might surface as a crash in mod B's code if mod B uses something mod A provided. Cross-reference with mod issue trackers.

How do I disable specific mods to find the culprit?
Use a binary search. Disable half your mods, see if the crash continues. If yes, the culprit is in the still-enabled half. Repeat until you find the specific mod.

Wrapping up

Crash reports are the most important diagnostic tool you have for a Minecraft server. Once you can read them, most "my server crashed and I don't know why" problems become "my server crashed because of mod X, here's the fix."

The structure to follow:

Find the crash report in crash-reports/
Read the exception line (the type of error)
Read the top of the stacktrace (where it happened)
Match the package name to your mod list
Look up the specific error and mod online
Apply the fix

If you get stuck, paste the crash report to mclo.gs and ask for help. Server Heron's support team handles crash debugging for all our customers as part of standard support, no extra cost.