Ich habe ein Problem mit einer von uns erstellten Anwendung, die manchmal mit einer StackOverflowException in .NET-Code abstürzt.
Leider ist die App teilweise nicht verwaltet und teilweise verwaltet, und aus irgendeinem Grund tritt das Problem nur auf Nicht-Entwickler-Computern auf.
Mein aktueller Plan ist die Verwendung von WINDBG (Teil der Debugging-Tools für Windows von Microsoft), das auf den Testern installiert ist. Ich kann WINDBG dazu bringen, die Erstellung der fraglichen Ausnahme abzufangen.
Als solches kann ich Folgendes tun:
sxe ld:mscorlib g .loadby sos clr !stoponexception -create System.StackOverflowException g Da dieses Problem nur jeden zweiten Tag auftritt, und nur alle 50+ oder mehr, würde ich es lieber vermeiden, wenn die Tester alles oder einen Teil davon eingeben müssen, wenn sie diese App starten.
Ich habe versucht, die obigen Befehle in einer Textdatei zu platzieren und eine Verknüpfung wie folgt zu erstellen:
"...\windbg.exe" -c "$<c:\windbg.txt" -o "...\app.exe" Der WINDBG-Debugger wird gestartet, schlägt jedoch mit dieser Fehlermeldung fehl:
0:000> sxe ld:mscorlib 0:000> g Command file caused an implicit wait Command file execution failed, HRESULT 0x80004005 "Unspecified error" Also anscheinend gist in einem solchen Startskript nicht erlaubt.
Kann ich machen was ich will? Kann ich dies automatisieren oder muss ich nur eine Batchdatei vorbereiten oder etwas, das Autohotkey verwendet, das dies tut?
Es ist zwar spät, aber ich wollte trotzdem einen Workaround anbieten. Ich bin mit dem gleichen Problem konfrontiert und bin bei der Suche nach der Antwort auf diese Frage gestoßen. Ich habe später eine Problemumgehung herausgefunden.
Um das Problem zu umgehen, rufen Sie das Skript mit $> <oder $$> <oder $$> a <auf, damit die Befehle in einem einzelnen Befehlsblock zusammengefasst werden.
Sie könnten versuchen .dump /ma /u c:\app.dmp, einen Absturzabzug zu erhalten, der auf Ihrem Computer kopiert und analysiert werden kann.
Anstatt zu versuchen, den Benutzer WinDbg auf seinem Computer ausführen zu lassen, können Sie mit WER automatisch ein Crash-Dump erstellen, es auf Ihren Computer kopieren und ohne Zeitdruck analysieren. Siehe Erstellen von Dumps im Benutzermodus, um Einstellungen in der Registry zu erstellen, in denen der Dump auf der Festplatte gespeichert wird.
In beiden Fällen sollten Sie von C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 (oder Framework64) kopieren:
Andernfalls kann es vorkommen, dass Ihre .NET-Version von seiner Version abweicht und Sie den Fehler nicht analysieren können.