Minecraft-Server-Crash-Report lesen: Schritt-für-Schritt-Anleitung (2026)

Der Server ist gerade abgestürzt, in der Konsole steht eine rote Wand aus Text und in crash-reports/ liegt eine frische Datei mit 800 Zeilen. Wenn das einmal pro Woche passiert und Sie jedes Mal raten müssen, welches Plugin schuld ist, ist diese Anleitung für Sie. Wir zerlegen die Struktur eines Crash Reports, lesen einen Stack Trace mit den Augen eines Paper-1.21-Admins, unterscheiden einen Java-seitigen Crash von einem nativen JVM-Crash und finden das schuldige Plugin in Sekunden.

Geschrieben für Paper und Folia 1.21+ auf Java 21, aber 90% gilt auch für Spigot, Purpur, Fabric und Forge. Alle Klassen- und Exceptionnamen sind echt, nichts erfunden.

Wo der Server Crash Reports ablegt

Wenn Minecraft eine fatale Exception im Haupt-Tick-Thread fängt, dumpt der Vanilla-Code selbst einen Report. Drei Orte sind relevant und alle drei sollten geprüft werden:

• crash-reports/crash-YYYY-MM-DD_HH.MM.SS-server.txt neben server.jar. Das ist das primäre Artefakt, erzeugt von net.minecraft.CrashReport kurz bevor der Prozess stirbt.
• hs_err_pid<PID>.log im Arbeitsverzeichnis des Servers. Diese Datei stammt von der HotSpot-JVM selbst, geschrieben von nativem Runtime-Code, wenn nicht Ihr Java-Code crasht, sondern die VM: SIGSEGV, native Memory Exhaustion, JIT-Bug.
• logs/latest.log und gerollte logs/*.log.gz. Der Stack Trace landet meist auch hier, dazu der Kontext der Minute vor dem Crash. Ohne latest.log ist ein Crash Report oft wertlos, weil man nicht sieht, was das Plugin eine Sekunde vor dem Fehler getan hat.

Paper schreibt manchmal eine vierte Datei: debug/ mit TPS- und Thread-Dump, falls der Watchdog rechtzeitig auslöste. Auf Paper 1.21.4+ schauen Sie auch dort nach.

Zuerst: Datei komplett kopieren. Nicht editieren, kein "Rauschen" entfernen. Ein vollständiger Crash Report ist genau das, was der Plugin-Autor braucht, und im Rauschen versteckt sich oft die Ursache.

Anatomie von crash-XXXX.txt

Die Datei sieht furchteinflössend aus, ihr Aufbau ist aber mechanisch. Ein typischer Crash:

---- Minecraft Crash Report ----
// Don't be sad, have a hug! <3

Time: 2026-04-15 18:42:11
Description: Exception ticking world

java.lang.NullPointerException: Cannot invoke "org.bukkit.entity.Player.getInventory()" because the return value of "org.bukkit.Bukkit.getPlayer(String)" is null
    at com.example.shopgui.ShopGuiPlus.onPlayerJoin(ShopGuiPlus.java:142) ~[ShopGUIPlus-1.94.0.jar:?]
    at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) ~[?:?]
    at org.bukkit.plugin.EventExecutor.execute(EventExecutor.java:123) ~[paper-api-1.21.4.jar:?]
    at io.papermc.paper.plugin.manager.PaperPluginManagerImpl.callEvent(PaperPluginManagerImpl.java:177) ~[paper-1.21.4.jar:?]
    at net.minecraft.server.players.PlayerList.placeNewPlayer(PlayerList.java:215) ~[paper-1.21.4.jar:?]
    ...

Schicht für Schicht. Die Markerzeile ---- Minecraft Crash Report ---- existiert, damit Tools wie mcprofile erkennen, dass es ein Crash Report ist und kein Vanilla-Log. Dann ein Witz, Mojang-Humor aus net.minecraft.CrashReport.getErrorComment seit 2012.

Time und Description liefern Kontext. Description ist das, was der Main Thread im Moment der Exception getan hat. Häufige Werte: Exception ticking world, Exception in server tick loop, Loading entities, Unexpected error, Watching Server. Wenn die Beschreibung Watching Server ist, kommt der Dump vom Watchdog nach einem Freeze, nicht aus der Exception selbst, und der Stack Trace zeigt NICHT den Schuldigen, sondern den hängenden Thread.

Danach folgt die eigentliche Exception-Klasse und der Aufrufstapel. Das ist der wichtigste Teil und der nächste Abschnitt widmet sich ihm.

Stack Trace lesen: wo es crashte vs wer schuld ist

Reihenfolge im Stack Trace: oben der jüngste Frame (wo der Throw passierte), unten der älteste (meist Thread.run). Anfänger beschuldigen oft die oberste Zeile und liegen falsch.

Die Regel ist einfach. Gehen Sie von oben nach unten und finden Sie den ersten Frame, der NICHT Vanilla Minecraft, NICHT Bukkit/Paper-API und NICHT Java-Standardbibliothek ist. Die Pakete:

• net.minecraft.*, com.mojang.* ist Vanilla. Selten die Ursache.
• org.bukkit.*, io.papermc.*, org.spigotmc.* ist Server-API. Auch selten schuld.
• java.*, jdk.*, sun.* ist das JDK. Crash hier bedeutet OOM, JIT-Problem oder Sie haben null an die API gegeben.
• Alles andere ist Drittanbieter-Code. Das ist der Schuldige.

Im Beispiel oben ist die erste fremde Zeile at com.example.shopgui.ShopGuiPlus.onPlayerJoin(ShopGuiPlus.java:142) ~[ShopGUIPlus-1.94.0.jar:?]. Paket com.example.shopgui, jar ShopGUIPlus-1.94.0.jar, Schuldiger in einer Sekunde gefunden. Datei ShopGuiPlus.java Zeile 142.

Der Anhang in eckigen Klammern ~[ShopGUIPlus-1.94.0.jar:?] ist Paper-Spezifisch. Auf Spigot fehlt das, dann muss man das Paket manuell suchen. com.example.shopgui führt in fünf Sekunden zu ShopGUIPlus.

Wenn der Stack Trace KEINEN fremden Code enthält und alles in net.minecraft.* liegt, ist das entweder ein Vanilla-Bug (selten), Welt-Korruption oder die Folge eines fremden Bugs: Ein Plugin hat eine Entity zerstört und Vanilla crasht eine Minute später beim Aufräumen. In dem Fall öffnen Sie latest.log und suchen WARN/ERROR in der Minute vor dem Crash.

Häufige Exceptions: Bedeutung und Behebung

Neun von zehn Crashes laufen auf eine von sechs Exceptions hinaus. Das Muster zu kennen spart eine Stunde Debug.

NullPointerException. Jemand rief eine Methode auf einem null-Objekt auf. Java 14+ schreibt Diagnostik wie Cannot invoke "X.method()" because Y is null. Das sagt EXAKT, was null war. Meist hat ein Plugin Bukkit.getPlayer() oder world.getBlockAt().getState() nicht auf null geprüft. Fix: Plugin updaten oder Autor mit Trace melden.

ConcurrentModificationException. Thread A modifiziert eine Collection, während Thread B darüber iteriert. Plage von Plugins, die die Welt aus einem Async-Task anfassen. Operationen auf Welt, Chunks, Entities oder Inventories MÜSSEN auf dem Main Thread laufen via Bukkit.getScheduler().runTask(plugin, ...). Wenn das schuldige Paket Wörter wie Async, Tasks oder Sync enthält, ist es fast sicher das.

OutOfMemoryError: Java heap space. Heap voll. Kein Code-Bug, sondern ein Memory-Leak oder zu kleiner -Xmx. Vor dem OOM schreibt die JVM fast immer hs_err_pid oder java_pid<PID>.hprof (mit -XX:+HeapDumpOnOutOfMemoryError). hprof in Eclipse MAT oder VisualVM öffnen und sehen, welche Klasse am meisten hält. Auf 1.21 oft Citizens (eingefrorene NPCs), grosse Dynmap-Renders, Plugins mit cachenden HashMap<UUID, ...> ohne Cleanup.

StackOverflowError. Endlose Rekursion. Meist eine zirkuläre PlaceholderAPI: Placeholder A expandiert zu B, B zu A. Oder ein EventListener feuert ein Event, das den gleichen Listener erneut aufruft. Der Stack Trace zeigt die GLEICHEN Zeilen hunderte Male, suchen Sie das Muster.

NoClassDefFoundError / ClassNotFoundException. Plugin referenziert eine Klasse, die nicht im Classpath ist. Meist weil:

1. Das Plugin von ProtocolLib/Vault/PlaceholderAPI abhängt und Sie es nicht in plugins/ gelegt haben.
2. Sie Paper aktualisiert haben und das Plugin eine Mojang-mapped-Klasse nutzt, die umbenannt wurde (z.B. net.minecraft.server.v1_17_R1.* ist nach 1.17 weg).
3. Versionskonflikt: Zwei Plugins haben verschiedene Versionen derselben Library geshadet und der ClassLoader nahm die falsche.

IllegalStateException auf Paper 1.21 bedeutet meist "Sie haben die Welt off-thread angefasst", "Iterator invalidiert" oder "Plugin disabled". Die Exception-Message ist fast immer explizit.

Tabelle: Exception, wahrscheinliche Ursache, erster Schritt

Exception	Wahrscheinliche Ursache	Erster Schritt
NullPointerException	Plugin hat null nicht geprüft nach API-Call	Erstes fremdes Paket im Trace finden, Plugin updaten
ConcurrentModificationException	Async-Code mutiert Welt/Entities	Plugin mit "Async" im Namen abschalten und testen
OutOfMemoryError: Java heap space	Memory-Leak oder -Xmx zu klein	-Xmx prüfen, Heap-Dump in MAT öffnen
StackOverflowError	Zyklische Rekursion (oft PAPI)	Wiederholte Zeilen im Trace suchen
NoClassDefFoundError	Fehlende Dependency oder Versionskonflikt	Pflicht-Plugins in plugins/ verifizieren
IllegalStateException	Async-API-Zugriff oder disabled Plugin	Message lesen, ist meist explizit

hs_err_pid: wenn die JVM selbst crasht

Wenn eine hs_err_pid12345.log im Server-Verzeichnis erscheint, ist das eine andere Crash-Kategorie. Java-Exceptions fängt die JVM sauber. Wenn Sie hs_err_pid sehen, ist die VM selbst gestorben: SIGSEGV, SIGBUS, native Memory Exhaustion, JIT-Bug.

Die Datei beginnt so:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f4a8c1d3a40, pid=12345, tid=12378
#
# JRE version: OpenJDK Runtime Environment Temurin-21.0.4+7 (21.0.4+7) (build 21.0.4+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM Temurin-21.0.4+7 (21.0.4+7-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x9aa40]
#

Worauf achten:

• Problematic frame ist die wichtigste Zeile. Steht da C [libc.so.6+...] oder C [libfreetype.so+...], ist es eine native OS-Library. Oft ein NIC-Treiber, glibc auf altem Ubuntu, OpenSSL.
• Steht da J net.minecraft.server.MinecraftServer.tick, ist das ein JIT-Bug, Java auf neuestes Patch-Release upgraden.
• JRE version zählt. Java 17.0.2 hatte einen bekannten JIT-Bug, 21.0.0 GA auch. Auf neuestes Temurin LTS gehen, siehe adoptium.net.
• Der THREAD-Block zeigt, was der Thread tat. Ist es "Server thread" durch org.bukkit.craftbukkit.v1_21_R3.*, dann tickte der Server und crashte im Native.
• Memory-Block ist bei OOM relevant. Native Memory Tracking falls JVM mit -XX:NativeMemoryTracking=summary gestartet wurde.

Wenn hs_err_pid regelmässig erscheint, RAM mit memtest86 über Nacht prüfen (auf Dedicated). Ein defekter DIMM produziert SIGSEGV an zufälligen Stellen. Häufiger als gedacht.

Latest.log: Kontext der Minute vor dem Crash

Der Crash Report zeigt den Moment des Versagens. Was DAVOR passierte, steht in logs/latest.log. Datei öffnen und Timestamp 30-60 Sekunden vor Time aus dem Crash Report suchen. Wichtig:

• [WARN] und [ERROR] von Plugins. Oft warnt das Plugin fünf Minuten lang, bevor es kippt.
• Can't keep up! und Watchdog-Meldungen. Server fror vor dem Tod ein.
• Player-Joins. Wenn der Crash immer beim Login einer bestimmten UUID kommt, ist deren playerdata/<uuid>.dat wahrscheinlich kaputt.
• Befehle von Admins oder Plugins. WorldEdit-Operationen, /reload (niemals /reload auf einem Live-Server), Massen-Kicks.

Nützliche Kombo: latest.log zwei Sekunden vor dem Crash zeigt [WARN] [ShopGUIPlus] Failed to load shop config for player Steve, und der Crash-Report-Stack endet in ShopGuiPlus.onPlayerJoin. Schuldiger ohne Raten bestätigt.

Schuldiges Plugin finden: vom Paket zum Download

Der Trace zeigt also auf at com.example.shopgui.ShopGuiPlus.onPlayerJoin. Was tun:

1. plugins/ öffnen und jar nach Klammer-Name ShopGUIPlus-1.94.0.jar suchen. Version notieren.
2. Ohne Klammern (Spigot): unzip -p plugins/*.jar plugin.yml | grep -A1 main: und main:-Klasse mit Paket abgleichen. Output zeigt, welches jar das Paket enthält.
3. Google nach com.example.shopgui führt meist zu SpigotMC resources, Modrinth oder dem GitHub des Autors.
4. Plugin-Version gegen letzten Release prüfen. Jede SpigotMC-Resource hat Changelog und Issue Tracker.
5. Wenn die letzte Version neuer ist und Changelog "fix NullPointerException on player join" enthält, upgraden. Fertig.
6. Wenn Sie schon auf der letzten Version sind, Issue eröffnen. Den GANZEN Crash Report mitsenden (via pastebin, mclo.gs oder GitHub Gist), Paper-Version (/version), Java-Version (java -version) und Reproschritte.

Für Paper-Plugins gute Praxis: prüfen, ob der gleiche Crash schon in Paper Issues gemeldet ist. Manchmal ist Paper selbst schuld, vor allem direkt nach einem neuen Release.

Tools, die die Triage beschleunigen

mclo.gs nimmt einen Crash Report und hebt Plugin-Pakete in eigenen Blöcken hervor. Praktisch fürs Teilen in Discord-Support-Channels.

mcprofile.io parst Crashes und färbt Stack Frames nach Owner. Keine Paid-Features, alles frei.

Für hprof-Dumps ist Eclipse MAT seit fünfzehn Jahren Standard. Öffnet Dumps bis 8 GB auf einem Notebook, siehe eclipse.dev/mat.

IntelliJ IDEA Community öffnet hs_err_pid und teilt es in Tabs. Auch frei.

Wenn Sie nichts lokal installieren wollen, deckt grep 80% ab: grep -A 30 "Stacktrace:" crash-reports/crash-*.txt liefert den Stack ohne Drumherum.

Bug an Plugin-Autor melden

Ein guter Issue ist der Unterschied zwischen "in einem Tag geschlossen" und "sechs Monate ignoriert". Minimum:

• Plugin-Version (/version <Plugin>).
• Server-Version (/version, ganze Zeile inklusive Paper-Build).
• Java-Version (java -version).
• Voller Crash Report via mclo.gs oder GitHub Gist. Niemals 800 Zeilen direkt in den Issue kleben.
• latest.log fünf Minuten vor dem Crash, ebenfalls via mclo.gs.
• Reproschritte. Bei zufälligem Crash so schreiben: "happens randomly 1-2 times per day, no obvious trigger".
• Liste der Plugins, die parallel laufen.

Was NICHT zu tun: keinen Roh-Text einfügen, Crash Report nicht editieren ("ich habe Lärm entfernt"), nicht nur "crashed pls fix" schreiben.

FAQ

Was zählt mehr, crash-report.txt oder hs_err_pid?

Wenn beides existiert, mit crash-report.txt anfangen. Es ist eine Java-Exception mit sinnvollem Stack Trace und identifizierbarem Plugin. hs_err_pid liest man, wenn crash-report.txt gar nicht entstand oder nur eine Watching Server-Description ohne nützlichen Trace enthält.

Warum zeigt der Trace nur net.minecraft.* und kein Plugin?

Zwei Gründe. Entweder crashte es auf einem Thread, der keinen Plugin-Code lief (Chunk-Gen, Netzwerk), und ein Plugin hat Daten vorher zerstört. Oder es ist ein Watchdog-Dump und der Stack zeigt den eingefrorenen Main Thread, nicht die Ursache des Freezes. In beiden Fällen latest.log öffnen und WARN-Einträge 30 Sekunden vor der Crash-Time suchen.

Server crasht beim Start und schreibt keinen Crash Report. Wo schauen?

Wenn der Prozess vor dem Erstellen von crash-reports/ stirbt, geht das Log nach stdout. Server in screen/tmux laufen lassen oder mit 2>&1 | tee start.log und stdout prüfen. Meist NoClassDefFoundError von einem Plugin mit fehlender Dependency oder inkompatibler Java-Version.

Wie unterscheide ich OOM von normalem Lag?

OOM erscheint als java.lang.OutOfMemoryError: Java heap space oder GC Overhead Limit Exceeded. Wenn das fehlt, aber TPS auf null fiel und Watchdog den Server eine Minute später killte, ist das KEIN OOM, sondern eine lange GC-Pause oder ein hängendes Plugin. Spark-Profiler starten (/spark profiler) und Flame Graph aufzeichnen.

Was tun bei Server, der mit jedem Mal anderem Report crasht?

Klassisches Symptom für Hardware-Trouble oder kaputte Welt. Erst memtest86 über Nacht auf Dedicated. Dann Welt mit chunky oder regionfixer prüfen. Auf Managed Hosts um Verschiebung auf eine andere Node bitten, manchmal OOMt ein lauter Nachbar Ihre JVM.

Soll ich -XX:+HeapDumpOnOutOfMemoryError deaktivieren?

Nein, an lassen. Der Dump entsteht einmal beim OOM und ist etwa so gross wie -Xmx. Bei -Xmx16G sind das 16 GB, freier Plattenplatz muss da sein. Ohne Heap Dump ist das Finden eines Memory-Leaks möglich, dauert aber deutlich länger.

Wenn Ihr Server einmal pro Woche kippt und jeder Crash Report dem letzten ähnelt, kennen Sie das schuldige Plugin wahrscheinlich schon. Aber wenn die Crashes zufällig wirken und kein lesbares Muster da ist, prüfen Sie, ob ein Paketsturm Ihren Netzstack überlastet und echten Spielern den Connect verweigert. MineGuard fängt solche Angriffe ab, bevor sie Minecraft erreichen, und lässt nur echte Plugin-Crashes in den Logs zurück.