Wie verfolge ich einen zeitweiligen Absturz, der nur unter dem Debugger auftritt, aber nicht von ihm abgefangen wird?

8

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.

Der Fehler

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.

Weitere Informationen

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:

  • Windows 7 Pro x64 auf WMWare Fusion 3.1.3 unter OSX Lion 10.7.1, alle vollständig aktualisiert. Fusion läuft im "Vollbild" -Modus auf einem meiner Bildschirme.
  • Bei einem Kollegen, der nativ Windows 7 ausführt (nicht in einer VM), tritt dieses Problem nicht auf. Ich auch nicht auf meinem alten Vista Computer.
  • Embarcadero RAD Studio 2010, vollständig aktualisiert (ich hoffe, es gibt ungefähr fünf Updates und alles in Ordnung zu bringen ist knifflig.) Ich habe DDevExtensions 2.4.1 installiert, und das neueste IDE Fixpack auch: die Deinstallation dieser beiden hat keine Wirkung.
  • Die Anwendung wird hauptsächlich in C ++ geschrieben, mit Delphi-Schnipseln. Es ist 32-Bit.
  • Wir verwenden EurekaLog , aber die Ausnahme wird auch nicht davon erfasst. (Normalerweise wird eine Ausnahme zuerst vom Debugger und dann von EurekaLog abgefangen.)
  • Das Ausführen eines Debug-Builds (kein EurekaLog, zusätzliche Debug-Informationen usw., debug DCUs auf true gesetzt) ​​reproduziert es ebenfalls. Die Option "DCUs debuggen" auf der Delphi-Verknüpfungsseite des Dialogfelds C ++ Builder-Projekteinstellungen scheint jedoch keine Auswirkungen zu haben - ich kann den VCL-Code nicht aufrufen und finde die Zeile, die den Fehler tatsächlich auslöst.
  • Codeguard (erkennt Speicherzugriffsfehler, doppelte Freigaben, Zugriff in freigegebenem Speicher, Pufferüberläufe usw.) meldet nichts.
David M 22.08.2011, 06:36
quelle

4 Antworten

8

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!

    
David Heffernan 22.08.2011 07:16
quelle
3

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.

    
Martin Trummer 26.06.2013 14:47
quelle
2

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:

Alex 21.05.2015 22:24
quelle
1

Ü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.

    
House of Dexter 11.12.2013 19:27
quelle