Richtlinien für das Debuggen

Artikel
09/02/2008

Aktualisiert: November 2007

Im Folgenden werden Richtlinien für das Debuggen von Code vorgestellt.

Erforderlich

Machen Sie sich mit Debugtools vertraut.

Sie müssen Debugtools verstehen und beherrschen. Weitere Informationen finden Sie unter Debuggen in Visual Studio.
Informieren Sie sich, wo die Symbole archiviert werden.

Die Symbole für alle Produkte müssen auf Symbolservern archiviert werden. Sie müssen nur wissen, wo diese Server zu finden sind. Weitere Informationen finden Sie unter "How to Use the Microsoft Symbol Server" in der MSDN Library.
Untersuchen Sie, aufgrund welcher Probleme Prozesse hängen bleiben, und beheben Sie diese Probleme.

Für Benutzer ist eine Anwendung, die nicht mehr reagiert (hängt), genauso schlimm wie ein Absturz. In beiden Fällen geht Arbeit verloren, und die Benutzer müssen von vorne beginnen. Bislang war die Meinung verbreitet, dass bei hängen gebliebenen Anwendungen die Ursache sehr viel schwieriger zu ermitteln und zu beheben sei. In vielen Fällen gilt dies heute nicht mehr, wenn Prozesse hängen bleiben. Verwenden Sie zum Lösen dieser Probleme die neuesten Tools und Techniken. Weitere Informationen finden Sie unter "How to Troubleshoot Program Faults with Dr. Watson" in der MSDN Library.
Lernen Sie, wie ein Minidump gedebuggt wird.

Wenn Tester und Kunden einen Codeabsturz herbeiführen, ist in den meisten Fällen kein Debugger angefügt. Wenn Sie das Problem dann nicht einfach reproduzieren können, steht Ihnen nur ein Minidump zur Verfügung. Daher ist es sehr wichtig, dass Sie lernen, anhand eines Minidumps zu debuggen. Weitere Informationen finden Sie unter "Minidump Files" in der MSDN Library.
Lernen Sie, wie ein beschädigter Stapel wiederhergestellt wird.

Die Wiederherstellung eines beschädigten Stapels ist eine komplizierte Aufgabe, die jedoch von wesentlicher Bedeutung ist, da in der Praxis bei einer Vielzahl von Fehlern unverständliche Stapel vorhanden sind. Weitere Informationen finden Sie unter "Troubleshooting Common Problems with Applications: Debugging in the Real World" in der MSDN Library.

Vermeiden

Die Annahme, dass beim Test alle Probleme gefunden werden.

Beim Testen werden niemals alle Probleme gefunden. Das ist einfach nicht möglich. Der Code ist zu komplex. Und selbst wenn beim Testen alle Probleme gefunden würden, hätten Sie niemals genügend Zeit, um alle zu beheben. Vermeiden Sie stattdessen beim Entwurf des Produkts Probleme von Anfang an. Ersparen Sie sich die Mühe, später Korrekturen durchzuführen. Sie müssen die Verantwortung für die Qualität des Codes übernehmen. Das Testteam überprüft die Qualität des Codes lediglich. Verlassen Sie sich nicht darauf, dass die Tester schon alles in Ordnung bringen.

Empfohlen

Lernen Sie, Multithreadanwendungen zu debuggen.

Wenn Sie Threads in ein Programm einfügen, können dadurch neue Fehler entstehen. Alle Maßnahmen, die Sie in einer Singlethreadumgebung zum Debuggen von Anwendungen ergreifen, werden mit zunehmender Anzahl von Threads immer wichtiger. So können Sie zum Beispiel nicht immer einen Fehler an dem Punkt abfangen, an dem er auftritt. Normalerweise wird der Fehler später abgefangen, möglicherweise auch in einem anderen Thread. In einer solchen Situation können Sie nicht einfach in der Aufrufliste zurückgehen, bis Sie das Problem gefunden haben, denn der Fehler ist in einem anderen Thread mit einer anderen Aufrufliste aufgetreten. Arbeiten Sie so vorausschauend wie möglich, um das Debuggen grundsätzlich zu vereinfachen.
Informieren Sie sich, wie das Remotedebuggen funktioniert.

Das Remotedebuggen kommt zum Einsatz, wenn Sie von Ihrem eigenen Computer aus ein Problem lösen möchten, das auf einem anderen Computer aufgetreten ist. Diese Methode nutzen Entwickler häufig, wenn ein Codesegment auf dem eigenen Computer ordnungsgemäß ausgeführt wird, auf einem anderen System hingegen zum Absturz führt. Das Debuggen auf dem anderen System kann in diesem Fall remote ausgeführt werden, ohne dass sich der Entwickler zu dem anderen Computer begeben muss. Weitere Informationen finden Sie unter Remotedebuggen – Setup.
Lernen Sie, Debugvorgänge auf Liveservern auszuführen.

Beim Debuggen eines Liveservers, auf den bereits Kunden zugreifen, kommen andere Debugverfahren zum Einsatz. Je mehr Code für das Web geschrieben wird, umso häufiger werden diese Verfahren angewendet. Weitere Informationen finden Sie unter "Troubleshooting Common Problems with Applications: Debugging in the Real World" in der MSDN Library.
Kommentieren Sie alle Fehlerkorrekturen.

Wenn Sie ein Problem beheben, schließen Sie eine Versionsnummer, die Problem-ID und Ihren Alias in den Code ein. Wenn eine andere Person den Code später anzeigt und eine Frage zu der Korrektur hat, kann sie Sie um Informationen bitten.
Überprüfen Sie alle Fehlerkorrekturen.

Sie sollten alle Korrekturen im Code überprüfen. Lassen Sie Ihren Code von mindestens einer anderen Person (Kollegen) überprüfen.
Überprüfen Sie vor dem Einchecken, ob schwer erkennbare Probleme korrigiert wurden.

Vermeiden Sie, dasselbe Problem zweimal zu beheben. Überprüfen Sie anhand eines Builds, ob die Korrektur richtig ist, besonders bei schwer erkennbaren Problemen.
Erfassen Sie alle Fehlerkorrekturen in einem Testversionsdokument.

Koordinieren Sie die Arbeit des Testteams, indem Sie alle Fehlerkorrekturen in einem Testversionsdokument dokumentieren und dieses per E-Mail an das Testteam senden.
Verwenden Sie einen Symbolserver, um die Produktsymbole zu indizieren und zu archivieren.

Wenn die Produktsymbole auf einem Symbolserver indiziert und archiviert werden, wird das Debuggen auf jedem System, auch auf Kundensystemen, beschleunigt und vereinfacht.

Nicht empfohlen

Beheben Sie keine Probleme anderer Entwickler, ohne diese darüber zu informieren.

Es ist eine gute Übung, wenn Sie den Code anderer Entwickler untersuchen und versuchen, deren Probleme zu beheben. Sie lernen den Code besser kennen und unterstützen andere. Auf keinen Fall sollten Sie jedoch eine Korrektur einchecken, ohne den Besitzer des Codes darüber in Kenntnis zu setzen.
Schließen Sie ein Problem nicht als "nicht reproduzierbar" ab, ohne dieselbe Version in derselben Umgebung auszuprobieren.

Sie müssen einen Rollback auf die Produktversion ausführen, in der das Problem gefunden wurde. Gehen Sie nicht davon aus, dass das Problem behoben worden ist, wenn es in der aktuellen Produktversion nicht auftritt. Diese Annahme könnte sich als falsch erweisen. Möglicherweise wurde der Code geändert, sodass das Problem jetzt lediglich verdeckt ist. Wenn Sie ein Problem untersuchen, bis Sie beobachten können, wie es auftritt, finden Sie möglicherweise die eigentliche Ursache und können das Problem beheben, sodass es auf keinem Computer mehr auftritt.