Ein Crash ist ein unerwarteter Absturz eines Spiels oder Programms. Für die Fehlersuche ist der Absturz allerdings nur das sichtbare Ergebnis. Entscheidend ist die Frage, was unmittelbar davor im Spiel passiert ist und welcher technische Fehler die weitere Ausführung verhindert hat.
Was bedeutet Crash?
Bei einem Crash kann dein Spiel nicht wie vorgesehen weiterlaufen. Der Prozess wird beendet oder bricht aufgrund eines Fehlers ab. Für Spieler zeigt sich das beispielsweise dadurch, dass das Spiel plötzlich geschlossen wird oder eine Fehlermeldung erscheint.
Ein Crash beschreibt zunächst nur das Ergebnis. Er erklärt noch nicht, warum das Spiel abgestürzt ist. Die eigentliche Ursache musst du während des Debuggings ermitteln.
Crash und Bug sind nicht dasselbe
Nicht jeder Fehler führt zu einem Absturz. Ein Bug kann beispielsweise dafür sorgen, dass eine Tür nicht aufgeht, eine Figur an der falschen Position erscheint oder eine Quest nicht fortgesetzt werden kann. Das Spiel läuft in diesen Fällen möglicherweise trotzdem weiter.
Bei einem Crash endet dagegen die Programmausführung unerwartet. Der zugrunde liegende Fehler kann bereits vorher entstanden sein. Der Moment des Absturzes und die eigentliche Ursache müssen deshalb nicht identisch sein.
Ein Beispiel aus einem Spiel
Angenommen, dein Charakter öffnet eine Truhe. Das Spiel versucht daraufhin, den darin gespeicherten Gegenstand zu laden. Die zugehörigen Daten fehlen jedoch oder enthalten einen ungültigen Verweis. Eine Funktion greift anschließend auf Informationen zu, die nicht wie erwartet verfügbar sind, und das Spiel stürzt ab.
Für den Spieler sieht es zunächst so aus, als verursache das Öffnen der Truhe den Crash. Die eigentliche Ursache könnte jedoch in den Daten des Gegenstands, in der Inventarlogik oder in einem zuvor entstandenen fehlerhaften Zustand liegen.
Warum musst du einen Crash reproduzieren?
Für die Untersuchung ist es hilfreich, den Absturz erneut auslösen zu können. Du versuchst deshalb herauszufinden, welche Schritte zuverlässig zum Fehler führen.
Stürzt das Spiel beispielsweise jedes Mal ab, wenn du dieselbe Truhe mit einem bestimmten Gegenstand im Inventar öffnest, besitzt du bereits wichtige Informationen. Du kannst den Vorgang wiederholen, einzelne Bedingungen verändern und beobachten, wann der Crash auftritt und wann nicht.
Schwieriger sind Abstürze, die nur gelegentlich erscheinen. In solchen Fällen gewinnen technische Aufzeichnungen an Bedeutung, weil du den ursprünglichen Ablauf möglicherweise nicht unmittelbar nachstellen kannst.
Welche Informationen brauchst du?
Ein einzelner Hinweis wie „Das Spiel ist abgestürzt“ reicht für eine gezielte Fehlersuche meistens nicht aus. Hilfreich sind Informationen darüber, was vor dem Crash geschah und unter welchen Bedingungen er auftrat.
- die betroffene Spiel- beziehungsweise Build-Version,
- die letzten Aktionen vor dem Absturz,
- Log-Dateien,
- ein Stack Trace,
- Informationen über Betriebssystem und Hardware,
- relevante Spieleinstellungen,
- Hinweise darauf, ob sich der Fehler reproduzieren lässt.
Nicht bei jedem Crash stehen sämtliche Informationen zur Verfügung. Je mehr Kontext du kennst, desto genauer kannst du die Suche eingrenzen.
Was verrät ein Log?
Ein Log zeichnet Ereignisse während der Ausführung des Spiels auf. Darin können beispielsweise geladene Bereiche, Warnungen, fehlgeschlagene Vorgänge oder Fehlermeldungen erscheinen.
Beim Crash der Truhe könnte das Log zeigen, dass unmittelbar zuvor eine bestimmte Gegenstandsdatei nicht geladen werden konnte. Damit erhältst du einen konkreten Hinweis für die weitere Untersuchung.
Der letzte Log-Eintrag muss allerdings nicht automatisch die Ursache sein. Er zeigt zunächst nur, was das Spiel protokolliert hat.
Was zeigt dir ein Stack Trace?
Ein Stack Trace zeigt die Folge von Funktionsaufrufen, die zu einem bestimmten Zeitpunkt aktiv war. Bei einem Crash kann er dich dadurch zu dem Codebereich führen, in dem der Fehler sichtbar wurde.
Vielleicht führt die Aufrufkette von der Interaktion mit der Truhe über das Inventarsystem bis zu einer Funktion, die Gegenstandsdaten verarbeitet. Damit verkleinert sich der Bereich, den du im Programmcode untersuchen musst.
Auch ein Stack Trace beweist nicht automatisch, wo die ursprüngliche Ursache liegt. Ein falscher Zustand kann bereits früher entstanden sein und erst später zum Absturz führen.
Warum ist die Build-Nummer wichtig?
Bei einem Crash solltest du wissen, welche Build-Version betroffen ist. Während der Entwicklung entstehen fortlaufend neue Fassungen des Spiels. Ohne eindeutige Zuordnung könntest du einen Fehler untersuchen, der in deinem aktuellen Entwicklungsstand bereits anders aussieht.
Angenommen, Build 120 läuft stabil und Build 121 stürzt beim Öffnen einer Tür ab. Dieser Vergleich liefert einen wichtigen Ansatzpunkt: Du kannst untersuchen, welche Änderungen zwischen beiden Entwicklungsständen vorgenommen wurden.
Versionsverwaltung grenzt die Suche weiter ein
Hier kommt die Versionsverwaltung ins Spiel. Sie dokumentiert Änderungen am Projekt und ermöglicht dir, unterschiedliche Entwicklungsstände miteinander zu vergleichen.
Arbeitest du mit Perforce P4, können zusammengehörende Änderungen in Changelists gespeichert sein. Tritt ein Crash erstmals nach einer bestimmten Änderung auf, lässt sich der betreffende Bereich genauer untersuchen.
Auch hier gilt: Eine zeitlich passende Änderung ist zunächst nur ein Verdacht. Erst Tests und die eigentliche Fehleranalyse zeigen, ob sie den Absturz tatsächlich verursacht.
Warum treten manche Crashes nur auf bestimmten Geräten auf?
Ein Spiel kann auf deinem Entwicklungsrechner problemlos funktionieren und auf einem anderen System trotzdem abstürzen. Spieler verwenden unterschiedliche Prozessoren, Grafikkarten, Treiber, Betriebssystemversionen und Speicherkonfigurationen.
Auch Plattformen unterscheiden sich. Ein Fehler kann beispielsweise ausschließlich in einer bestimmten Konsolenfassung oder unter bestimmten Grafikeinstellungen auftreten. Geräte- und Systeminformationen helfen deshalb dabei, Gemeinsamkeiten zwischen Crash-Berichten zu erkennen.
Was ist ein Crash Report?
Ein Crash Report fasst technische Informationen zu einem Absturz zusammen. Welche Daten enthalten sind, hängt vom Spiel, der Plattform und den eingesetzten Werkzeugen ab.
Dazu können beispielsweise Stack Trace, Build-Kennung, Betriebssystem, Geräteinformationen und weitere technische Daten gehören. Statt lediglich zu erfahren, dass das Spiel abgestürzt ist, erhältst du damit zusätzlichen Kontext für die Analyse.
Viele gleiche Crashes müssen nicht einzeln untersucht werden
Nach der Veröffentlichung kann derselbe Fehler bei zahlreichen Spielern auftreten. Tausend Crash Reports bedeuten deshalb nicht zwangsläufig tausend unterschiedliche Probleme.
Fehlererfassungssysteme können ähnliche Ereignisse gruppieren. Dadurch lässt sich erkennen, dass viele Abstürze wahrscheinlich zum selben technischen Problem gehören. Zusätzlich kann die Häufigkeit Hinweise darauf geben, welche Fehler besonders viele Spieler betreffen.
Crash-Erfassung mit Sentry
Eine Möglichkeit zur technischen Erfassung von Abstürzen bietet Sentry. Die Plattform kann Fehlerereignisse aus Anwendungen sammeln und mit zusätzlichen Informationen verbinden.
Je nach Integration können beispielsweise Stack Traces, Release-Informationen und weitere technische Daten für die Untersuchung verfügbar sein. Damit lässt sich ein Fehler aus einer veröffentlichten Version wieder in den Entwicklungsprozess zurückführen.
Sentry behebt den Crash nicht automatisch. Die gesammelten Informationen unterstützen dich dabei, den Fehler einzugrenzen, zu reproduzieren und anschließend im Projekt zu korrigieren.
Vom Crash zur Fehlerkorrektur
Die Untersuchung eines Absturzes folgt deshalb häufig mehreren Schritten. Zunächst identifizierst du die betroffene Version und sammelst Informationen über den Fehler. Logs und Stack Trace liefern technischen Kontext, während die Versionsverwaltung relevante Änderungen sichtbar macht.
Anschließend versuchst du, den Crash zu reproduzieren und eine mögliche Ursache gezielt zu testen. Nach der Korrektur erzeugst du einen neuen Build und prüfst erneut die Situation, die zuvor zum Absturz führte.
Damit endet die Arbeit nicht zwangsläufig. Weitere Tests sollen zeigen, ob die Korrektur neue Probleme verursacht hat. Erst dadurch schließt sich der Weg vom beobachteten Crash über das Debugging bis zum überprüften neuen Entwicklungsstand.
Weitere Artikel auf Games und Lyrik
Wenn du dich neben der technischen Spieleentwicklung auch für klassische Adventures interessierst, findest du auf Games und Lyrik weitere Beiträge. In Runaway 3: A Twist of Fate begleitest du Brian und Gina durch ein Point-and-Click-Adventure mit Rätseln, ungewöhnlichen Situationen und einer Geschichte voller Wendungen.
Weitere Informationen zur Erfassung und Untersuchung von Abstürzen findest du auf der offiziellen Website von Sentry.
