Ich habe einen seltsamen zeitweiligen Absturz, der nur unter bestimmten Umständen auftritt , den ich nicht lösen kann, und ich suche den Rat von SO, wie ich ihn angehen kann.
An scheinbar zufälligen Punkten zeigt Windows den Dialog "[App] hat aufgehört zu arbeiten". Es ist ein APPCRASH in ntdll.dll, Ausnahmecode 4000001f Ausnahme Offset 000a2562. Hier wird es schwierig: Dies tritt nur auf, wenn die Anwendung unter dem Debugger ausgeführt wird. Der Debugger fängt diese Ausnahme jedoch nicht ab, und an dem Punkt, an dem Windows dieses Dialogfeld anzeigt, reagiert die IDE nicht. Dieser Fehler tritt nicht auf, wenn er normal ausgeführt wird, d. H. Nicht innerhalb des IDE-Debuggers.
Ich kann es nicht außerhalb des Debuggers reproduzieren, also kann ich das Programm nicht ausführen und anhängen, wenn es bereits abgestürzt ist. Ich kann die Ausführung nicht anhalten, wenn Windows dieses Dialogfeld anzeigt, da die IDE nicht reagiert. I kann manuell Codezeilen nachverfolgen, um zu sehen, wo es auftritt. Es gibt mehrere, und wo es vorkommt, ist scheinbar zufällig. Für eine Weile ist es aufgetreten, wenn ein Fenster (oder ein neues Formular) für eine Weile beim Erstellen eines Threads angezeigt wurde.
Bearbeiten: Ich habe es bis zur IDE verfolgt: Wenn ich an einem Haltepunkt pausiere und auf die Registerkarte Threadstatus klicke, stürzt das Programm sofort ab mit dem obigen Dialog obwohl es theoretisch pausiert ist. In dieser Situation reagiert die IDE weiterhin. Das ist wirklich seltsam.
Ich habe gerade meine Entwicklungsumgebung in VMWare Fusion verschoben. Der Fehler tritt auch beim Ausführen eines Builds von meinem alten (nativen Windows) Computer auf meinem neuen Computer auf; Es ist nicht mit der gleichen EXE-Datei auf dem alten Computer aufgetreten. Das lässt mich fragen, ob es mit Fusion oder etwas in meinem neuen Setup zusammenhängt.
Ich renne:
Dies weist alle Merkmale einer Speicherbeschädigung auf. Es wird nur angezeigt, wenn Sie in einer bestimmten Umgebung ausgeführt werden und jedes Mal an einer anderen Position auftritt. Beide klassischen Symptome.
Der beste Weg, um dies zu debuggen, besteht darin, das vollständige FastMM herunterzuladen und mit vollen Debugging-Optionen zu starten.
Wenn das nicht hilft, werden Sie darauf beschränkt, Teile des Codes nacheinander zu entfernen, bis Sie das Problem isolieren können.
Ein weiteres Problem, das ich in D2010 gesehen habe, ist ein Problem beim Mischen von lokalen Klassendefinitionen (d. h. Klasse innerhalb der Klasse) mit Generika. Der generierte Code ist in Ordnung, aber die Debug-DCUs sind falsch und beim Durchlaufen des Codes springt der Debugger in die falsche Datei und stirbt kurz danach. Sie scheinen nicht das gleiche Problem zu haben, aber es gibt Ähnlichkeiten bei den IDE-Todesfällen.
Endlich würde ich Ihnen raten, Ihren eigenen Code anstelle von VMware zu vermuten. Es ist immer verlockend, etwas anderes zu beschuldigen, aber meiner Erfahrung nach war es immer mein Code am Ende!
Ich habe ein ziemlich ähnliches Problem. Ich habe auch eine .dll entwickelt und wenn ich irgendwo in meinem Code einen Haltepunkt gesetzt habe, stoppte Delphi an der Quellcodezeile und die Host-Anwendung stürzte sofort ab.
Beim Schließen des "Thread Status Window" im Debug-Layout wurde das Problem "behoben". Ich arbeite an Windows 7 64-Bit und Delphi XE3.
4000001F ist STATUS_WX86_BREAKPOINT
Mit anderen Worten, es ist INT 3, das nicht von IDE behandelt wurde.
Da es in NTDLL ausgelöst wird - ich würde vermuten, dass dies ein Hinweis auf Speicherbeschädigung im System-Heap ist. Denken Sie daran, dass einige Windows-Codes auf die Debugger-Version wechseln , wenn sie unter dem Debugger ausgeführt werden . Deshalb können Sie dies nicht reproduzieren, wenn die Anwendung außerhalb des Debuggers als Standalone ausgeführt wird - weil der Haltepunkt nicht generiert wird.
Sie können FastMM im vollen Debug-Modus versuchen, aber ich denke nicht, dass es Ihnen helfen wird. Die Beschädigung passiert nicht im Speicher, sondern im Systemspeicher. Ja, vielleicht wird das Speicherzuweisungsschema geändert - und Ihre Korruption wird sich in Ihrem Code / Speicher offenbaren .... Verwenden Sie Top-Down-Zuordnungen, versuchen Sie es mit SafeMM ...
Ein anderer möglicher Ansatz wäre Application Verifier .
Siehe auch:
Überprüfen Sie die dsk-Datei "projects" und stellen Sie sicher, dass keine Referenz auf die falsche Einheit verweist. Die Lösung besteht darin, den DSK in einem Editor zu öffnen und den Speicherort der Datei an den richtigen Speicherort zu ändern.
Tags und Links delphi crash c++builder vmware-fusion