// Minecraft

Serveur Minecraft qui crash : comment lire le crash report

Serveur Minecraft qui crash : comment lire le crash report

Quand votre serveur Minecraft crash, la cause est presque toujours écrite noir sur blanc dans le dossier crash-reports ou dans logs/latest.log. Lire un crash report Minecraft se fait en trois étapes : regardez la ligne Description:, les premières lignes de la stack trace et le dernier Caused by:. C'est généralement là que figure le plugin ou le mod fautif. Pas de crash report ? Regardez alors latest.log et la console ; c'est souvent la mémoire.

Où se trouvent le crash report et les logs ?

Tout se trouve dans le dossier racine de votre serveur, que vous ouvrez dans le gestionnaire de fichiers du panel de jeu ou via SFTP.

  • crash-reports/ : un fichier par crash, avec l'heure dans le nom, par exemple crash-2026-09-30_14.02.11-server.txt. Un tel rapport n'est créé que si Minecraft remarque lui-même que quelque chose ne va pas.
  • logs/latest.log : le journal de la session en cours. À chaque démarrage (et chaque nouveau jour), le précédent est compressé, par exemple en logs/2026-09-30-1.log.gz. Après un redémarrage, le crash se trouve donc dans le .log.gz le plus récent.
  • hs_err_pid<numéro>.log : c'est Java lui-même qui est tombé, pas Minecraft. C'est rare.

Rien trouvé ? Regardez alors la console du panel. Lors d'un crash, elle affiche Detected server process in a crashed state!, avec en dessous Exit code et Out of memory. Si vous y lisez Out of memory: true, le serveur a été arrêté parce qu'il a dépassé sa limite de mémoire, et Minecraft n'a plus eu l'occasion d'écrire un rapport.

Arborescence d'un serveur Minecraft avec le dossier crash-reports, le dossier logs contenant latest.log et des fichiers .log.gz compressés, et un fichier hs_err_pid, avec ce que chaque fichier révèle sur un crash
Où chercher quand votre serveur Minecraft crash : trois endroits dans le dossier racine, et la console en filet de sécurité.

Comment lire un crash report Minecraft

Un exemple abrégé, provenant d'un serveur moddé :

---- Minecraft Crash Report ----
// Who set us up the TNT?

Time: 2026-09-30 14:02:11
Description: Ticking entity

java.lang.NullPointerException: ...
	at com.example.mobmod.ZombieAi.tick(ZombieAi.java:88)
	at net.minecraft.world.level.Level...

A detailed walkthrough of the error, its code path and all known details is as follows:
-- Head --
Thread: Server thread
-- Entity being ticked --
Details:
	Entity Type: minecraft:zombie (...)
	Entity's Block location: World: (120,64,-340), ...
-- System Details --
...
  1. Description est le résumé. Ticking entity, Ticking block entity, Exception in server tick loop ou Watching Server donnent déjà une piste.
  2. La ligne juste en dessous est l'erreur elle-même, par exemple java.lang.OutOfMemoryError: Java heap space.
  3. Les lignes at forment la stack trace ; la première indique où le problème est survenu. net.minecraft est Minecraft lui-même ; io.papermc, org.bukkit, org.spigotmc, com.destroystokyo et ca.spottedleaf sont Paper. Un autre nom de package correspond généralement à un plugin ou à un mod.
  4. Caused by: est la cause sous-jacente ; s'il y en a plusieurs, la dernière est la plus profonde. Les lignes comme ... 12 more sont des répétitions.
  5. Les blocs en dessous donnent du contexte : pour une ticking entity, le type et les coordonnées ; tout en bas, dans System Details, la version de Java, la mémoire et les flags JVM.

Depuis la 26.1, Minecraft Java n'est plus obfusqué : les lignes Minecraft de votre stack trace ont donc elles aussi des noms de classes lisibles.

Les cinq causes les plus courantes

1. Pas assez de mémoire

Si vous voyez java.lang.OutOfMemoryError: Java heap space, le heap Java est plein. Ce n'est pas forcément une fuite ; souvent, le heap est simplement trop petit. Une view-distance plus basse et moins de mondes chargés aident. Si c'est toujours juste, choisissez une offre Minecraft plus grande.

Plus délicat : un crash sans rapport, avec un log qui s'arrête net et Out of memory: true dans la console. En plus du heap, Java utilise aussi de la mémoire, entre autres pour les classes chargées et les threads. Si le heap peut remplir toute l'offre, le processus peut dépasser la limite et il est alors arrêté brutalement. Chez MC-Node, vous réglez cela avec la variable de démarrage Geheugenlimiet (%) (la limite de mémoire) dans le panel : la part de la mémoire de votre offre que Java peut utiliser comme heap, entre 50 et 95. Vide signifie 100 %. Une valeur autour de 85 laisse de la marge ; les modpacks lourds peuvent nécessiter une valeur plus basse. Redémarrez ensuite. Voir aussi combien de RAM il faut à votre serveur.

2. Un plugin ou un mod incompatible avec la 26.3

Sur Paper, vous voyez alors souvent Error occurred while enabling ... (Is it up to date?). Paper désactive alors ce plugin et continue de tourner. Les erreurs de plugin qui surviennent ensuite, Paper les journalise généralement sous la forme Could not pass event ... to <plugin>, sans crasher ; un plugin qui fait geler le serveur se repère grâce au watchdog (cause 4). Vérifiez sur la page du plugin si la 26.3 est prise en charge. Attention : au moment de la rédaction, Paper ne propose pour la 26.3 que des builds alpha et bêta ; la 26.2 dispose de builds stables. Ce que la 26.3 casse d'autre, vous le découvrirez dans Minecraft 26.3 et votre serveur.

3. La mauvaise version de Java

Minecraft 26.x exige Java 25. Un serveur vanilla sous Java 21 renvoie UnsupportedClassVersionError avec class file version 69.0 (Java 25) et only recognizes class file versions up to 65.0 (Java 21). Dans ce cas, Paper affiche Minecraft 26.1 and newer requires running the server with Java 25 or above. La même erreur pour un seul plugin signifie que celui-ci attend un Java plus récent. Le changement se fait via l'image Docker dans le panel : changer de version de Java.

4. Le watchdog : un tick qui reste bloqué

Vanilla et NeoForge signalent A single server tick took ... seconds (should be max ...) et Considering it to be crashed, server will forcibly shutdown. La limite est max-tick-time dans server.properties, 60000 millisecondes par défaut. Paper désactive ce watchdog et utilise à la place timeout-time dans spigot.yml (60 secondes par défaut), avec le message The server has stopped responding! et un thread dump dans latest.log, sans crash report. Cherchez-y des noms de plugins : Paper pointe lui-même les plugins qui font des requêtes HTTP ou MySQL et les modifications de monde trop volumineuses. Selon Paper, relever la limite revient à échanger le crash contre de gros pics de lag.

5. Ticking entities et chunks corrompus

Avec Ticking entity ou Ticking block entity, un seul mob, un entonnoir ou une machine (souvent moddée) lève une erreur à chaque tick. Sur vanilla et NeoForge, le serveur crashe alors de nouveau dès que cette partie du monde se charge. Le rapport indique le type et les coordonnées. Restaurez une sauvegarde, ou supprimez ce chunk hors ligne avec l'outil communautaire MCA Selector (compatible avec la 26.3 depuis la version 2.9) ; cela efface toutefois tout ce que contient ce chunk. Paper, lui, ne crashe pas ici : il journalise Entity threw exception at ou BlockEntity threw exception at avec l'emplacement, et supprime l'entity ou la block entity concernée.

Un fichier de région endommagé (r.x.z.mca, 32 × 32 chunks), par exemple après un arrêt brutal pendant la sauvegarde, ne fait généralement pas crasher le serveur. Vanilla journalise Failed to load chunk, Paper ... chunk data will be lost, et ce chunk est régénéré. Ce qui s'y trouvait est perdu ; restaurez alors une sauvegarde.

Trouver le coupable pas à pas

  1. Faites d'abord une sauvegarde, même si le serveur ne tourne pas.
  2. Lisez le crash report le plus récent et la fin de latest.log (ou du .log.gz le plus récent). Cherchez ERROR et WARN juste avant le crash.
  3. Annulez votre dernière modification. Une mise à jour, un nouveau plugin ou une autre image Java est le suspect numéro un.
  4. Coupez en deux. Pas de nom évident ? Déplacez la moitié de vos plugins (ou mods) dans un dossier comme plugins-desactives et démarrez. Le crash a disparu : le coupable se trouve dans la moitié retirée ; sinon, dans le reste. Répétez jusqu'à ce qu'il ne reste qu'un candidat. Des mods privés de leur mod de base ne démarrent pas ; c'est une autre erreur.
  5. Partagez votre log via mclo.gs plutôt que sur Discord : vous obtenez un lien court et les adresses IP sont supprimées automatiquement. Vérifiez vous-même qu'il ne contient ni mots de passe ni tokens.

Quand ce n'est pas un crash

  • Can't keep up! Is the server overloaded?, c'est du lag : le serveur prend du retard mais continue de tourner. Voir ce que signifient TPS et MSPT.
  • Des joueurs sont éjectés alors que la console continue de tourner : c'est généralement le client ou la connexion.

Quand ouvrir un ticket ?

Si vous voyez Out of memory: true alors que la limite de mémoire est bien réglée, si le serveur crashe avant que quoi que ce soit n'apparaisse dans latest.log, ou si la méthode par moitiés ne donne rien, ouvrez un ticket. Indiquez de quel serveur il s'agit, l'heure du crash, les liens mclo.gs du crash report et de latest.log, et ce que vous avez modifié juste avant.

Questions fréquentes

Où trouver le crash report de mon serveur Minecraft ?

Dans le dossier crash-reports, à la racine de votre serveur, avec la date et l'heure dans le nom, par exemple crash-2026-09-30_14.02.11-server.txt. Le journal se trouve dans logs/latest.log ; si le serveur a déjà redémarré, regardez dans le fichier .log.gz le plus récent.

Pourquoi n'y a-t-il pas de crash report alors que mon serveur crash ?

Le processus s'est alors arrêté avant que Minecraft puisse écrire un rapport, souvent parce qu'il a dépassé la limite de mémoire de l'offre ; la console affiche alors Out of memory: true. Baissez dans ce cas Geheugenlimiet (%) (la limite de mémoire) dans le panel, ou choisissez une offre plus grande.

Quelle version de Java faut-il pour Minecraft 26.3 ?

Java 25 : c'est ce qu'indiquent les données de version de Mojang pour la 26.3, et Paper l'exige depuis la 26.1. Avec un Java plus ancien, vous verrez UnsupportedClassVersionError avec class file version 69.0, ou sur Paper un message indiquant que Java 25 est requis.

Puis-je mettre max-tick-time à -1 contre les crashs du watchdog ?

Sur vanilla et NeoForge, c'est possible, mais cela ne règle rien : un serveur figé reste alors simplement bloqué. Paper désactive ce watchdog vanilla ; chez lui, c'est timeout-time dans spigot.yml qui s'applique. Mieux vaut chercher ce qui bloque le tick.

À lire aussi

// ESSAYEZ VOUS-MÊME
Votre serveur Minecraft en ligne en 60 secondes
Voir les offres →