StackOverflow Analysieren

Wenn in einem .NET-Programm eine StackOverflowException ausgelöst wird, dann crashed der komplette Prozess. Für den Programmierer gibt es leider absolut keine Möglichkeit, dies abzufangen.

Es gibt die Möglichkeit, sich mit dem Visual Studio Debugger vorher an den Prozess zu hängen. Wenn die Exception aufschlägt, zeigt der Debugger den Call-Stack an. Man benötigt dafür aber Visual Studio und es kann hin und wieder passieren, dass dies auch mal nicht funktioniert.

Im folgenden wird eine alternative Vorgehensweise beschrieben, die deutlich zuverlässiger zum Ergebnis führt. Es wird mithilfe des Werkzeug ProcDump beim Auftreten dieser Exception ein Dump-File erstellt. Dieses wird anschließend mit windbg analysiert und der Call-Stack ermittelt.

Ist es ein StackOverflow?

zuerst stellt sich die Frage ob der Absturz eines Brokers tatsächlich durch einen StackOverflow ausgelöst wird. Das kann an den folgenden Symptomen festgestellt werden:

1.) Alle Benutzer die auf dem Broker arbeiten erhalten die Meldung:

Session has been terminated! SessionID is unknown.

2.) Im Event-Log des Broker-Servers ist folgender Eintrag zu finden:

  • Quelle: Application Error
  • Ereignis-ID: 1000
  • Detail-Text:
    • Name der fehlerhaften Anwendung: w3wp.exe
    • Ausnahmecode: 0xc00000fd

Fehler reproduzieren

Wenn nicht bekannt ist, wie genau der Fehler entsteht, dann ist es empfehlenswert dies herauszufinden. Denn so kann man gezielt einen Broker starten, den Fehler auslösen und ein Dump-File erzeugen.

Um das einzugrenzen kann das SessionTrace verwendet werden.

Dazu gibt man in der web.config die folgenden Informationen an:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="SessionTraceFolder" value="C:\temp\sessiontrace" />
    <add key="SessionTraceCaching" value="false"/>
    ...
Warning

Das Ändern der Datei startet den Broker neu

Den SessionTraceFolder kann man auch im Publish-Wizard angeben. Das SessionTraceCaching muss aber manuell auf "false" gesetzt werden, damit Anfang und Ende eines Requests getrennt protokolliert werden. Das ist entscheidend für die Analyse des Fehlers.

Wurden die Dateien erzeugt und es ist mind. ein Absturz aufgetreten, dann kann man den SessionTrace-Ordner in das Werkzeug FSSessionTraceAnalyzer.exe einlesen (dieses befindet sich im Framework Studio Programmverzeichnis). Auf der Registerkarte "Session Map" gibt es unten einen Link "Show open Requests". Dieser zeigt eine Liste aller Requests an, zu denen keine Ende protokolliert wurde. Das können potentielle Kandidaten sein, aber ggf. auch Requests die unverschuldet mit abgebrochen wurden. Gut ist es daher, wenn mehrere Abstürze aufgetreten sind, so lässt sich der entscheidende Kandidat besser finden.

Gibt die gewonnene Info noch keine Aufschluss über die Ursache, dann ist der nächste Schritt das Erstellen eines Dump-Files.

Dump-File erstellen

Vorbereitungen

Das freie Werkzeug ProcDump herunterladen

https://docs.microsoft.com/en-us/sysinternals/downloads/procdump

Die Zip-Datei entpacken z.B. in den Ordner C:\ProcDump

Dump erzeugen

Der betroffene Prozess muss bereits laufen. ProcDump beobachtet den laufenden Prozess und erzeugt im Falle eines StackOverflow den gewünschten Dump.

Eingabeaufforderung starten. Ggf. als Administrator erforderlich um sich an einen Windows Dienst hängen zu können.

In den Ordner des ProcDump-Programms navigieren

C:\> cd C:\ProcDump

Das Programm starten

C:\ProcDump> procdump64.exe -accepteula -e 1 -f C00000FD.STACK_OVERFLOW -g -ma <PID> %temp%

<PID> ist die ID des Processes. Diese kann über den Task-Manager in Erfahrung gebracht werden. Es kann auch der Name des Prozesses - z.B. w3wp.exe oder NV.ERP.Base.JobServer.Host.JobServerHost.WindowsService.exe angegeben werden. Dies funktioniert aber nicht, wenn der Prozess mehrfach mit dem selben Namen ausgeführt wird (bsp. w3wp.exe mehrfach gestartet wird).

Die Eingabeaufforderung offen und am Server den Windows-Benutzer angemeldet lassen. Wenn jetzt eine StackOverflowException auftritt, erzeugt dieses Programm einen Dump, bevor das Programm im Anschluss endgültig crashed.

Die Dump-Datei wird in den Temp-Ordner gepackt. Sie heißt NameDesProcesses_Datum_Uhrzeit.dmp. Diese Datei kann im nächsten Schritt mit WinDbg analysiert werden.

Die Datei kann ggf. mehrere GB groß sein, denn sie enthält ein komplettes Hauptspeicher-Abbild des Prozesses. Erfolgt eine Analyse bei N&V, dann sollte die Datei als 7-Zip gepackt und per ftp bereitgestellt werden.

Analyse mit windbg.exe

Vorbereitungen

Note

Ist auf dem Rechner Visual Studio installiert, dann ist WinDbg evtl. bereits verfügbar. Die Installation ist in diesem Fall nicht nötig.

Das Tool WinDbg bietet Microsoft als Store-App an: https://apps.microsoft.com/store/detail/windbg-preview/9PGJGD53TN86.

Alternativ kann die Installation dieses Tools auch über das Windows SDK erfolgen. Dazu das Windows SDK von der folgenden Seite herunterladen:

https://developer.microsoft.com/windows/downloads/windows-sdk/

  • Button "Laden Sie das Installationsprogramm herunter>"
  • Die Installations-Routine winsdksetup.exe starten.
  • Alles Haken außer "Debugging Tools for Windows" entfernen.<
  • Installieren.

Analyse

Die windbg.exe (x64-Variante) starten.
Einfach im Startmenü "windbg" eintippen.

Die Dump-Datei einlesen
Menü File -> Open Crash Dump

Unten in die Text-Zeile die folgenden Befehle eingeben:

0:000> .loadby sos clr
0:000> !analyze

Jetzt den Callstack anzeigen mit folgendem Befehl:

0:000> !clrstack

Dies kann eine ganze Weile gehen - einfach abwarten :-)