So finden und beheben Sie Fehler in kommerzieller Software unter Windows

So finden und beheben Sie Fehler in kommerzieller Software unter Windows

Laut Wikipedia ist „Ein Softwarefehler ein Fehler, eine Schwachstelle, ein Fehler oder eine Störung in einem Computerprogramm oder -system, die dazu führt, dass ein falsches oder unerwartetes Ergebnis erzielt wird oder sich unbeabsichtigt verhält und die Anwendung schließlich abstürzt. Der Prozess der Fehlerbehebung wird als „Debugging“ bezeichnet und verwendet häufig formale Techniken oder Tools, um Fehler zu lokalisieren .“

Meistens können Fehler in einer Entwicklerumgebung reproduziert und behoben werden, bevor eine Version an die Produktion gesendet wird. Manchmal hängen Fehler jedoch von der jeweiligen Umgebung oder dem Profil der Benutzer ab — z. B. die Verwendung von Sonderzeichen in einem Ordnernamen —, was es schwieriger macht, die Ursache eines Fehlers zu verstehen. Die schlimmsten Fehler erfordern Benutzerunterstützung, um eine Bildschirmfreigabesitzung einzurichten, um zu sehen, wie ein Benutzer einen Fehler reproduziert.

Bei Dashlane verwendet das Windows-Team verschiedene Tools, um Fehler zu finden und zu reproduzieren:

• Technische Protokolle, um Probleme zu erkennen und zu beheben, die manchmal mehrere Iterationen und Interaktionen mit dem Benutzer erfordern, bei dem ein Problem auftritt
• Microsoft Process Monitor und Process Explorer, zwei kostenlose Tools, die fehlerhafte Installationen oder eine beschädigte Umgebung lokalisieren

Kürzlich hat Microsoft eine neue Version eines anderen Entwicklertools, WinDbg, vorgestellt. Diese Anwendung wurde in eine UWP-App portiert, ist im Microsoft Store frei verfügbar und verfügt über eine sehr schöne und nützliche Funktion: TTD oder Time Travel Debugging. Denken Sie an eine Zeit, in der Sie einen sehr schwer zu reproduzierenden Fehler beheben mussten, der nur auf einem bestimmten Computer auftrat. Oder denken Sie an die Zeit, die Sie mit der Installation einer Entwicklerumgebung auf diesem Computer verbracht haben — wenn Sie könnten. Denken Sie dann darüber nach, wie oft Sie Ihre Anwendung im Debug-Modus starten mussten, um den Fehler zu reproduzieren, und dann haben Sie die beschädigte Zeile verpasst, indem Sie versehentlich F5 anstelle von F11 gedrückt haben. TTD macht dies zu einem Kinderspiel, da Sie den Fehler nur einmal aufzeichnen müssen, damit Sie ihn immer wieder abspielen können, sowohl vorwärts als auch rückwärts.

Zeitreise-Debugging mit WinDbg

TTD ist eine Reverse-Debugging-Lösung. Es besteht aus 3 Schritten:

1. Notieren Sie die App oder den Prozess auf dem Computer, der den Fehler reproduzieren kann. Verwenden Sie WinDbg mit Administratorrechten und starten Sie eine ausführbare Datei oder hängen Sie sie an eine bereits ausgeführte Datei an, um deren Ablaufverfolgung aufzuzeichnen. Das Ergebnis ist eine Datei (.run extension) enthält alle Informationen, um den Fehler zu reproduzieren. Aus diesem Grund können wir Dashlane nur zum Debuggen von Fehlern verwenden, die vor der Anmeldung auftreten, um keine sensiblen Benutzerinformationen zu sammeln.
2. Wiederholen Sie die aufgezeichnete Spur vorwärts und rückwärts so oft wie nötig, um das Problem zu verstehen. Nach dem Laden erstellt WinDbg einen Index der Ablaufverfolgung, der eine vollständige und schnelle Speichersuche ermöglicht. Wir öffnen normalerweise auf einem Entwicklercomputer, auf dem wir Quellcode und PDB-Symbole laden können. Auf diese Weise können wir die Ablaufverfolgung wiedergeben, während wir Code in unserer IDE mit Prozess- und Speicherdatensätzen von der aufgezeichneten Maschine ausführen. (Stellen Sie sicher, dass der Quellcode und die Symbole mit der aufgezeichneten Prozessversion übereinstimmen.)
3. Analysieren Sie durch Hinzufügen von Haltepunkten, führen Sie Abfragen aus, um häufige Codeprobleme zu identifizieren, und erhalten Sie vollen Zugriff auf Speicher und Einheimische, um zu verstehen, was vor sich geht.

Beispiel

Angenommen, Sie haben eine einfache Konsolenanwendung geschrieben und erstellt.

Nehmen wir an, die erstellte Anwendung (TestTTD.exe) und die Symboldatei (TestTTD.pdb) sind in C:\TestTTD\bin , und der Quellcode ist in C:\TestTTD\src.

Record

1. Öffnen Sie WinDbg mit erhöhten Rechten.
2. Wählen Sie auf der Registerkarte Datei die Option Ausführbare Datei starten (erweitert). Geben Sie im Feld Ausführbar Folgendes ein C:\TestTTD\TestTTD.exe. Überprüfen Sie Record process with Time Travel Debugging, setzen Sie das Ausgabeverzeichnis auf einen beschreibbaren und vorhandenen Pfad und klicken Sie dann auf OK.
3. Wenn die Anwendung abstürzt, speichert WinDbg eine Ablaufverfolgungsdatei (.erweiterung ausführen) und protokolliert den Speicherort beim Laden.
4. Stoppen Sie den Debugger, und öffnen Sie den Speicherort der Ablaufverfolgungsdatei.

1. Öffnen Sie WinDbg.
2. Wählen Sie auf der Registerkarte Datei die Option Einstellungen in der linken Seitenleiste aus. Wählen Sie Debugging-Einstellungen, Hinzufügen C:\TestTTD\src zum Quellpfad-Feld und C:\TestTTD\bin zum Feld Symbolpfad. Klicken Sie auf OK, um die Änderungen zu speichern.
3. Wählen Sie auf der Registerkarte Datei die Option Ablaufverfolgungsdatei öffnen aus, und navigieren Sie zu der im Schritt Aufzeichnung erstellten Ablaufverfolgungsdatei.

Analysieren

1. Fügen Sie nach dem Laden der aufgezeichneten Trace-Datei in WinDbg einen Haltepunkt hinzu, um den Status der Anwendung zu stoppen und zu analysieren. Laden Sie eine Skriptdatei von der Registerkarte Quelle und klicken Sie dann auf die linke Seite der Zeile des gewünschten Haltepunkts. Drücken Sie F5, um zum Haltepunkt zu gelangen.
2. Drücken Sie nun F10, um wie in einer Visual Studio-Debugging-Sitzung zu wechseln. Klicken Sie auf Schritt über zurück, um rückwärts zu laufen.

Schlussfolgerungen

Beim Debuggen von Produktionscode und kaum reproduzierbaren Fehlern sind WinDbg und sein Time Travel Debug ein großartiges Werkzeug für Entwickler, das Zeit und Ressourcen sparen kann, indem es die fehlerhafte Anwendung nur in der betroffenen Umgebung aufzeichnet und Ihnen die Möglichkeit gibt, sie überall wiederzugeben. Weitere Informationen finden Sie im Microsoft-Blog oder auf der Website von MSDN Channel 9.