C# Debugging: Techniken und Tools für Profis

C# Debugging: Von „Warum funktioniert das nicht?“ zu „Ich weiß, wo der Fehler steckt“

Jeder C#-Entwickler kennt die Situation: Der Code kompiliert, läuft, aber macht etwas völlig Unerwartetes. Oder er stürzt mit einem Fehler ab, der sich in der Testumgebung nicht reproduzieren lässt. In solchen Momenten wird C# Debugging von einer Routineaufgabe zur wahren Kunst.

In diesem Artikel sehen wir uns Techniken und Tools an, die Ihnen helfen, Bugs nicht nur zu finden, sondern dies schnell und effizient zu tun. Wir beschränken uns nicht auf das Standard-F5 – wir sprechen über fortgeschrittene Breakpoints, bedingte Ausdrücke, Speicheranalyse und sogar die Arbeit mit Dumps in WinDbg. Los geht's!

Basis-Techniken für mächtiges C# Debugging

Bevor wir zu exotischen Tools übergehen, stellen wir sicher, dass Sie das Maximum aus Visual Studio herausholen. Viele Entwickler nutzen nur F9 (Breakpoint setzen) und F10(Schritt-für-Schritt), aber das ist zu wenig.

Bedingte Breakpoints (Conditional Breakpoints)

Stellen Sie sich vor: Sie haben eine Schleife mit 1000 Iterationen, und der Bug tritt nur bei der 567. auf. Einen Breakpoint setzen und 567 Mal F5 drücken? Nein. Nutzen Sie bedingte Breakpoints.

for (int i = 0; i < 1000; i++)\n{\n    // Irgendeine Logik\n    ProcessItem(items[i]);\n}

Klicken Sie mit der rechten Maustaste auf den roten Breakpoint-Kreis → wählen Sie „Conditions“ → geben Sie i == 567 ein. Wenn der Zähler den gewünschten Wert erreicht, stoppt der Debugger automatisch. Das spart Stunden Ihrer Zeit.

Als Bedingung können Sie nicht nur Vergleiche, sondern jeden booleschen C#-Ausdruck verwenden. Zum Beispiel: items[i].IsValid == false && items[i].Id > 100.

Breakpoints mit Aktionen (Tracepoints / Actions)

Manchmal müssen Sie die Ausführung nicht anhalten, sondern nur zu einem bestimmten Zeitpunkt ein Log ausgeben. Dafür gibt es Breakpoints mit Aktionen. Setzen Sie einen Breakpoint, klicken Sie mit der rechten Maustaste → „Actions“ → geben Sie eine Nachricht wie Methode aufgerufen mit Parameter: {parameter} ein.

Das funktioniert wie Console.WriteLine, aber ohne den Code zu ändern. Sie können Variablenwerte direkt im Output-Fenster ausgeben, ohne die Anwendung zu unterbrechen.

„An Prozess anhängen“ (Attach to Process)

Kommt es vor, dass ein Bug nur in der Produktion auftritt, lokal aber nicht? Nutzen Sie Debug → Attach to Process. Sie können sich mit einem bereits laufenden Prozess verbinden (z. B. IIS, Windows-Dienst oder Desktop-Anwendung).

Ein wichtiger Hinweis: Stellen Sie sicher, dass Sie die PDB-Dateien (Symbole) für die ausgeführte Build-Version haben. Sonst sehen Sie statt Variablennamen nur Variable1 und Variable2.

Fortgeschrittene Techniken: Diagnose ohne Stopp

Nicht alle Bugs lassen sich im Debugger fangen. Manchmal verändert das Anhalten der Ausführung das Programmverhalten (z. B. aufgrund von Timings in Multithread-Code). Für solche Fälle gibt es andere C# Debugging-Techniken.

Logging mit DiagnosticSource und Serilog

Das integrierte System.Diagnostics.Trace ist gut, aber für ernsthafte Projekte ist strukturiertes Logging besser. Serilog ist einer der beliebtesten Logger für .NET.

using Serilog;\n\nLog.Logger = new LoggerConfiguration()\n    .WriteTo.Console()\n    .WriteTo.File("log.txt", rollingInterval: RollingInterval.Day)\n    .CreateLogger();\n\ntry\n{\n    var result = SomeRiskyOperation();\n    Log.Information("Operation erfolgreich ausgeführt. Ergebnis: {Result}", result);\n}\ncatch (Exception ex)\n{\n    Log.Error(ex, "Fehler bei der Ausführung der Operation");\n}

Strukturierte Logs ermöglichen die Fehlersuche nicht nach Text, sondern nach Feldern. So können Sie alle Logs mit OrderId = 12345 der letzten Stunde finden. Das ist mächtiger als grep in einer Textdatei.

Profiling und Leistungsdiagnose