.NET-Produktions-Debugging
https://stackoverflow.com/questions/52808
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich habe schon seit einiger Zeit eine Windows-App in Produktion und habe sie so eingerichtet, dass sie uns Fehlerberichte sendet, wenn sie Ausnahmen auslöst.Die meisten davon sind recht anschaulich und helfen mir, das Problem sehr schnell zu finden (ich verwende den MS Application Exception Block).
In einigen Fällen habe ich Berichte über Probleme, die ich nicht reproduzieren kann und die anscheinend nur auf einigen wenigen Client-Rechnern auftreten.
Ich habe keinen physischen Zugriff auf diese Client-Computer. Welche Strategien kann ich zum Debuggen verwenden?Wäre es besser, eine Ablaufverfolgung in den Code einzubauen, oder gibt es andere Alternativen?
Danke schön.
Bearbeiten:Ich hätte klarer sein sollen:Die Fehlermeldungen, die ich erhalte, enthalten zwar den Stacktrace, aber da es sich um Produktionscode handelt, wird nicht die genaue Zeile angezeigt, die die Ausnahme verursacht hat, sondern nur die Methode, in der sie ausgelöst wurde.
Lösung
Eine Möglichkeit besteht darin, eine (Mini-)Dump-Datei so nah wie möglich an der Stelle zu generieren, an der die Ausnahme ausgelöst wird.Das Artikel spricht darüber, wie man dies mit verwaltetem Code macht.
Anschließend können Sie die Dump-Datei in Visual Studio oder WinDbg laden und mit Hilfe von überprüfen SOS
Andere Tipps
Du bist auf dem richtigen Weg.Sie müssen ein Tracking-Modul erstellen, das Aktionen/Ausnahmen lokal protokolliert.
Sie können dann über eine Schaltfläche oder eine Menüoption verfügen, auf die der Benutzer klicken kann, um Ihnen diese Informationen entweder automatisch per E-Mail zu senden, sobald das Problem auftritt, oder er kann die Option haben, an die Datei zu gelangen, damit er sie jederzeit an Sie übertragen kann andere Weise.
Sie können sogar einen Diagnosecode einbauen, um eine Integritätsprüfung auf dem System durchzuführen und Ihnen einen Bericht zu senden (vielleicht werden alle Ihre Komponententests ausgeführt, um zu sehen, ob sie auf diesem System funktionieren).
Ich benutze das immer Modul von Jeff für nicht behandelte Ausnahmen, das Senden einer E-Mail mit Stacktrace usw.
Smart Inspect von Gurock-Software hat sich für mich schon oft als nützlich erwiesen.Es lässt sich sehr einfach in eine .NET-Anwendung integrieren und bietet Ihnen eine äußerst leistungsstarke Kontrolle bei der Analyse von Protokolldateien.Es verfügt über Protokollebenen, mit denen Sie bestimmte Funktionen außer in bestimmten Fällen deaktivieren können, damit die Leistung nicht beeinträchtigt wird.
Sie verfügen sogar über Serversoftware, mit der Ihre Software eine Verbindung herstellen kann, um Protokolle zu speichern, wenn Sie keinen vollständigen Zugriff auf die Maschinen haben.Sie könnten beispielsweise einen Server haben, der unter www.IhreDomain.com läuft.Ihre Software verfügt über eine Konfigurationsoption zum Aktivieren des Debuggens.Smart Inspect ist so konfiguriert, dass die Protokolldaten an Ihren Server (und optional an eine lokale Datei) gesendet werden, sodass Sie unabhängig davon, wo die Software ausgeführt wird, eine Live-Protokollierung erhalten.
Smart Inspect ist sehr einfach zu konfigurieren und verfügt über viele Funktionen, die Ihnen helfen können.Ich habe es verwendet, um leistungsstarke Multithread-Serveranwendungen im laufenden Betrieb zu debuggen, ohne die Maschinen herunterzufahren.Es verfügt über alle Haken, um den Überblick über verschiedene Prozesse, Threads und Maschinen zu behalten.
Ich würde das Ereignisprotokoll verwenden.Schauen Sie hier:
