Zunächst ist dieser Fehler nicht Ihre Schuld.
Ein Programmierer hat vergessen, einen Fehler in seinem Programm zu behandeln, daher schlägt er fehl.
Natürlich tritt das Problem nicht hat in der Anwendung selbst zu sein (so der Programmierer aus dem Schneider ist). Dies kann in Windows sein oder in der MSVC-Laufzeit, in der .Net-Laufzeit oder in den Grafikkartentreibern oder was auch immer (deshalb werden Sie immer aufgefordert, alle Updates zu installieren, bevor Sie sich an den Support wenden).
Sie haben also alles abgedeckt, aber das Problem bleibt bestehen. Was jetzt?
Nun, das einzige, was jetzt noch übrig ist, ist, dass die betreffende Anwendung fehlerhaft ist und der Programmierer für diese nicht aus dem Schneider ist ( A-HA! ). Es ist also das Problem des Autors der Software. Wenden Sie sich an sie und fragen Sie sie, ob sie Ihnen helfen könnten, und beheben Sie das Problem.
Aber was ist, wenn sie mir sagen, dass ihre Software perfekt ist? Ich bin der Einzige mit diesem Problem und im Allgemeinen ist es meine Schuld.
Jetzt kommt der lustige Teil. Sie finden die tatsächliche Ursache Ihrer Fehlermeldung.
Was hat die Anwendung tatsächlich zu dem Betriebssystem gesagt, das das Betriebssystem dazu veranlasst hat, " Sie müssen den F-down herunterfahren! "?
Dafür stehen Ihnen viele Werkzeuge zur Verfügung.
- Protokolldateien
- Das Windows-Ereignisprotokoll
- Prozessmonitor
Sollte die betreffende Anwendung Protokolldateien ausschreiben, können diese bei der Suche nach der Ursache Ihres Anwendungsproblems Gold sein. Lesen Sie sie und besprechen Sie mögliche Fehlermeldungen hier.
Das Windows-Ereignisprotokoll enthält sicherlich Informationen über die abgestürzte Anwendung. Wenn es sich tatsächlich um eine .NET-Anwendung handelt, können Sie sogar Glück haben und einen Aufrufstack aus dem Protokoll ziehen (was für Entwickler sehr hilfreich sein könnte).
Wenn alles andere fehlschlägt, wenden Sie sich an Process Monitor . Process Monitor ist ein Tool, das die gesamte Kommunikation zwischen einer Anwendung und dem Betriebssystem (sozusagen) protokolliert . In den resultierenden erfassten Daten konnten Sie also genau sehen, welche Funktion die Anwendung aufgerufen hat, die zu einem unbehandelten Fehlerzustand führte. Dies könnte etwas Triviales sein, wie der Versuch, auf eine nicht vorhandene Datei oder ein Registrierungsobjekt zuzugreifen. Wenn Sie jedoch feststellen, dass ein Aufruf des Protokolls lange dauert, werden Sie mit diesem Ansatz wahrscheinlich nicht sehr weit kommen, wenn Sie keine Erfahrung mit der Softwareentwicklung haben.
Wenn Sie das tun " Nun, das hilft mir wahrscheinlich nicht bei der Lösung meines Problems ", dann haben Sie wahrscheinlich Recht. Es kann zwar Spaß machen, ein Problem wie dieses für bestimmte Personen aufzuspüren, aber normalerweise ist es die Aufgabe der Person, die die fehlerhafte Software geschrieben hat.
Sie sind weit besser dafür gerüstet, das Problem zu finden, als Sie es sind. Ein richtiger Fehlerbericht kann manchmal sehr weit gehen.