5 min read Easy 5.8k

Lire les logs et debugger un serveur S&Box

Published on May 18, 2026 at 03:59 PM

Où sont les logs S&Box, comment les lire, comment identifier la cause d'un crash (.NET stack trace, Source 2 assert, package mismatch), et comment activer le verbose quand ça part en cacahuète.

Introduction

S&Box logue beaucoup, et c'est plutôt une bonne chose. Le runtime .NET donne des stack traces propres, Source 2 sort des asserts identifiables, et le système de packages signale clairement les problèmes de téléchargement. Encore faut-il savoir où regarder.

Prérequis

Un serveur S&Box (qui plante ou qui se comporte mal)
Accès au panel Wisp (Console + Files)

Étape 1 : La console temps réel

C'est ton premier outil. Dans le panel Wisp → Console, tu vois tout ce que le serveur logue en direct :

Boot Steam Update / téléchargements packages
Erreurs runtime .NET
Asserts Source 2
Print depuis le code du gamemode

💡 Garde un onglet Console ouvert en permanence quand tu testes une modif.

Étape 2 : Les fichiers de log persistants

Les logs sont aussi écrits sur disque. Va dans Files et cherche le dossier logs/ à la racine du conteneur.

Fichiers typiques :

logs/
├── server.log           # log principal courant
├── server.log.1         # rotation jour précédent
├── crash-2026-05-17.log # crash dumps si applicable

Tu peux les télécharger pour analyse offline. Pour le live tail, Console suffit.

Étape 3 : Lire une stack trace .NET

Quand le gamemode plante, tu verras quelque chose comme :

System.NullReferenceException: Object reference not set to an instance of an object
  at MyGamemode.PlayerComponent.OnUpdate() in /path/PlayerComponent.cs:line 42
  at Sandbox.GameObject.Update()
  ...

À lire de haut en bas :

Type d'exception : NullReferenceException, IndexOutOfRangeException, InvalidOperationException, etc.
Message : précise le contexte
Stack trace : la première ligne (PlayerComponent.cs:line 42) est généralement ton code, c'est là qu'il faut regarder en priorité

Étape 4 : Identifier les erreurs courantes

Failed to resolve package → Mauvais ident dans +game. Format strict org.name minuscules.

SteamCMD failed: app 1892930 not found → Décalage Steam ou indisponibilité temporaire. Force un Reinstall ou attends 5 min.

Cannot bind port 27015: address already in use → Un autre service occupe le port, ou un précédent serveur S&Box n'a pas libéré le port après crash. Restart complet de l'instance.

Roslyn compilation failed → Erreur de compilation C# dans ton gamemode local (.sbproj). Le message précise le fichier et la ligne.

Assertion failed: ... at engine/... → Bug Source 2 (rare). Note le message complet et signale-le à Facepunch via leur tracker, ou ouvre un ticket VeryCloud avec le log.

Étape 5 : Activer le verbose

Selon ce que tu veux debugger, plusieurs leviers :

Logging gamemode (C#)

Dans ton code, multiplie les Log.Info("..."), Log.Warning("..."), Log.Error("..."). Ces messages apparaissent dans la console et les fichiers de log.

Trace réseau (si supporté par le gamemode)

Certains gamemodes exposent des ConVars de debug. Vérifie leur doc. S&Box base ne fournit pas de net_graph standard côté serveur.

Étape 6 : Analyser un crash dump

Si le serveur crashe complètement (process tué) :

Va dans Files → logs/
Cherche un fichier crash-*.log ou coredump-*
Télécharge-le et ouvre dans un éditeur

Si tu as le code source du gamemode, charge le .pdb correspondant dans un debugger .NET (dotPeek, ILSpy) pour résoudre les adresses.

Étape 7 : Garder un historique propre

Sur un serveur public, les logs grossissent vite. Quelques pratiques :

Logrotate côté gamemode : limite la taille (Wisp ne purge pas seul)
Schedule Wisp pour download + supprimer les logs > 30 jours
N'exporte pas les SteamID complets dans tes logs publics (RGPD)

Étape 8 : Logs vers Discord (alerting)

Pour être notifié sans surveiller la console toute la journée, beaucoup de gamemodes intègrent un webhook Discord. Si le tien ne le fait pas, tu peux le coder en C# :

using System.Net.Http;

static async void NotifyDiscord(string message)
{
    using var http = new HttpClient();
    await http.PostAsJsonAsync(
        "https://discord.com/api/webhooks/...",
        new { content = message }
    );
}

Branche-le sur Log.OnMessage pour relayer les erreurs critiques.

Dépannage

La console n'affiche rien

Le serveur n'a pas démarré (vérifie le bouton START)
Buffer plein côté Wisp — refresh la page
Le gamemode logue dans stderr ? regarde aussi l'onglet Log Viewer si disponible

Stack trace tronquée

Le gamemode utilise Exception.Message au lieu de Exception.ToString() : pas grand-chose à faire côté serveur
Récupère les .pdb du build si tu as accès au code

Le crash dump est binaire

C'est normal pour un coredump Linux. Utilise gdb ou un outil .NET de crash analysis
Si trop chiant, ouvre un ticket support VeryCloud avec le fichier

Commandes utiles

# Voir le dernier log
# -> Files / logs / server.log (clic droit Edit)

# Telecharger un log pour analyse offline
# -> Files / logs / [fichier] / clic droit Download

# Tail live = onglet Console du panel

Conclusion

S&Box logue clairement, à condition de regarder au bon endroit : Console pour le live, Files → logs/ pour l'historique. Stack traces .NET très lisibles, asserts Source 2 cryptiques mais identifiables, packages bavards. Une fois habitué, tu identifies la cause d'un crash en 30 secondes au lieu de redémarrer 10 fois.

Pour aller plus loin : webhooks Discord pour les erreurs critiques, intégration avec un APM .NET, dump auto via cron quand mémoire dépasse un seuil.