dotnet/diagnostics: SOS, lldb-Plugin und die dotnet-Tools für Laufzeitdiagnose im Detail

Vier Tools für unterschiedliche Ebenen der Prozessanalyse

Die praktische Oberfläche des Repositories bilden vier globale Diagnosewerkzeuge, die das README jeweils mit einem Link zur eigenen Dokumentseite aufführt. dotnet-counters überwacht Leistungsindikatoren einer .NET-Core-Anwendung in Echtzeit, dotnet-trace schreibt Ereignisse einer laufenden Anwendung in eine lokale Trace-Datei, dotnet-dump sammelt Dumps und analysiert sie, und dotnet-gcdump erzeugt gcdumps von lebenden .NET-Prozessen für die Heap-Analyse.

Die Aufteilung folgt einer klaren Logik: Die beiden ersten Tools beobachten einen Prozess während des Laufens, die beiden anderen erfassen und zerlegen einen Zustand. Für eine Störungssuche heißt das etwa, mit dotnet-counters die Richtung zu finden und anschließend mit dotnet-dump oder dotnet-gcdump die Ursache im Speicherbild zu suchen. Die einzelnen Kommandozeilenparameter listet das README nicht; sie liegen auf den verlinkten Dokumentseiten wie documentation/dotnet-dump-instructions.md.

SOS als Debugger-Erweiterung und ihr verwalteter Teil

Neben den globalen Tools enthält das Repository SOS, die Debugger-Erweiterung für lldb, das lldb-SOS-Plugin und den verwalteten Teil SOS.NETCore. Genau diese Aufteilung ist der Grund für die Existenz des Repositories: SOS.NETCore lag vorher im Runtime-Repository, wo es laut README ein Source-Build-Problem verursachte. Hier kann der verwaltete Teil out of band weiterentwickelt werden.

Ein weiteres genanntes Ziel ist die Symbolserver-Unterstützung für die .NET-Core-Laufzeit als neue SOS- und Plugin-Funktion außerhalb des regulären Release-Zyklus. Für Anwender bedeutet das, dass Erweiterungen am Debugger nicht an den Rhythmus der Laufzeit-Releases gekoppelt sind, sondern über die eigenen Releases dieses Repositories kommen.

Die Testmatrix: Distributionen, Architekturen, lldb-Versionen

Das README beschreibt die Verifikation als sehr große Matrix. Auf der Betriebssystemseite stehen Centos 6 und 7, Ubuntu, Alpine, Fedora, Debian und RHEL 7.2, auf der Architekturseite x64, x86, arm und arm64. Die lldb-Versionen reichen von 3.9 bis 9.0, und getestet wird gegen alle unterstützten und in Entwicklung befindlichen .NET-Core-Hauptversionen.

Die Build-Ziele sind dabei zweigeteilt: SOS und das lldb-Plugin werden für die portable, auf glibc basierende Linux-Plattform mit Centos 7 als Referenz gebaut sowie für Plattformen, die der portable musl-basierte Build nicht abdeckt, nämlich Centos 6, Alpine und macOS. Welche Kombinationen aktuell grün sind, verrät das README nicht; der Build-Status-Abschnitt ist leer, es bleibt ein CI-Link zur Pipeline dnceng.visualstudio.com.

Alte lldb-Versionen auf Centos, Alpine und Fedora

Ein eigenes Ziel des Projekts betrifft die Toolchain: viele Distributionen liefern standardmäßig sehr alte lldb-Versionen aus, und das Repository will den Zugang zu einer benötigten Version erleichtern, derzeit Version 3.9, mit Skripten und Dokumentation für Centos, Alpine, Fedora und weitere Plattformen. Wer SOS unter lldb nutzen will, hängt also an zwei Versionen gleichzeitig, der der Laufzeit und der des Debuggers.

Das erkläre auch, warum die Matrix oben die lldb-Versionen als eigene Dimension führt. Die Detailseite documentation/FAQ.md sammelt häufige Fragen; die Anleitung zum Debuggen von CoreCLR liegt im Runtime-Repository unter docs/workflow/debugging/coreclr/debugging-runtime.md.

Eigenbau mit build.sh: Voraussetzungen und Grenzen

Für den Build aus dem Quellcode nennt das README vier Voraussetzungen: Git, CMake, Python und einen C++-Compiler. Installiert man diese, reduziert sich der Build auf den Aufruf des Skripts build.cmd oder build.sh im Stammverzeichnis. Die Installation der Komponenten unterscheidet sich je nach Betriebssystem; es gibt separate Anleitungen für Windows, Linux, macOS, FreeBSD und NetBSD unter documentation/building/.

Wichtig ist die Plattformgrenze: Cross-Building über Betriebssysteme hinweg gibt es nicht, man muss auf der jeweiligen Zielplattform bauen. Die einzige Ausnahme ist ARM, das auf x64 gebaut wird. Für private Runtime-Builds existiert zudem eine eigene Seite zum Testen, documentation/privatebuildtesting.md.

Release-Rhythmus und Versionsnummern ablesen

Die Versionsnummern folgen nicht dem Schema der Laufzeit: Die letzten Releases heißen v10.0.731102 vom 30. Juni 2026, v10.0.721401 vom 28. April 2026 und v9.0.661903 vom 6. Januar 2026. Man erkennt daran zwei parallele Schienen, eine für die Diagnosetools zur Version 10 und eine zur Version 9, jeweils mit eigenem Build-Stamp.

Das Repository selbst zeigt rund 1.300 Sterne, etwa 400 Forks und 308 offene Issues; der letzte Push datiert auf denselben Tag wie das Release im Juni. Release-Notizen zu SOS und den Diagnosetools stehen laut README im GitHub-Releases-Tab. Lizenziert ist alles unter der MIT-Lizenz, nachgewiesen über die Datei LICENSE.TXT.

Redaktionelles Fazit

dotnet/diagnostics ist die erste Adresse, wenn ein laufender .NET-Prozess untersucht werden muss: dotnet-counters für Live-Messwerte, dotnet-trace für Ereignisaufzeichnung, dotnet-dump und dotnet-gcdump für Speicheranalyse, SOS unter lldb für die Tiefe. Wer nur seine Anwendung misst, kommt mit den globalen Tools aus; wer in Dumps abtaucht, braucht zusätzlich lldb. Vor dem Eigenbau sollten die plattformspezifischen Anleitungen geprüft werden, denn Cross-Building gibt es nur von x64 nach ARM.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes