Probleme mit Windows 7 (32Bit), Debugger, TOpenDialog

[Bbommel]

Hallo zusammen,

ich weiß, dass der Beitragstitel zunächst mal nicht sehr eindeutig klingt, aber ich habe ehrlich gesagt keine Idee mehr, wie ich das Problem weiter einkreisen kann und was nun genau die Ursache sein soll. Vielleicht hat jemand ja schon mal etwas ähmliches gehabt.

Mein Problem kann ich mittlerweile auf folgenden, reproduzierbaren Fehler eingrenzen: Ich starte mein Programm, wähle die Funktion Datei->Öffnen, so dass ein Öffnen-Dialog erscheint (TOpenDialog). In diesem drücke ich sofort wieder Esc oder klicke auf Abbrechen, dann beende ich mein Programm. Kurz bevor Delphi dann auch den Debugger beendet, meldet sich Windows mit der Meldung, dass mein Programm nicht mehr funktioniert und beendet werden muss. Erst wenn ich dem zustimme, wird das Programm und dann auch der Debugger beendet bzw. dann erst kehrt Delphi zum normalen Standard-Layout zurück.

Den Fehler habe ich seit heute und heute ist auch der erste Tag, an dem ich produktiv mit Windows 7 (32-Bit Professional) arbeite (bzw. das eigentlich wollte...). Zur Sicherheit habe ich auch noch mal ein Backup des Programms von vor zwei Wochen getestet, das definitiv funktioniert hat - hier tritt der selbe Effekt auf.

Auf einem zweiten Rechner mit Windows 7 und D2009 lässt sich das selbe Problem ebenfalls reproduzieren.

Starte ich das Programm ohne Debugger (direkt über die Eingabeaufforderung oder mit Strg+Shift+F9 in Delphi), dann tritt der Fehler nicht auf.

Benutze ich das Programm ohne den Öffnen-Dialog (ich kann meinem Programm die zu öffnende Datei auch direkt per Kommandozeile mitteilen), dann tritt der Fehler ebenfalls nicht auf.

Leider habe ich (weil ich dachte, vorher alles erfolgreich getestet zu haben) keinen Vista-Rechner mehr hier, aber: Bis Montag trat der Fehler dort auch nicht auf.

In der Situation, in der dieser Fehler auftrat, kann ich den Abschluss des Programms auch debuggen. Ich bin brav alles im Einzelschritt durchgegangen, alle Objekte wurden freigegeben, alle finalization-Abschnitte der units durchgelaufen, alles ohne Probleme. Erst, wenn das alles erledigt ist, also, wenn das Programm "eigentlich" schon fertig ist, kommt die Fehlermeldung.

Das Ganze erinnert mich ein bisschen an den Debuuger-Bug, allerdings trifft der ja auf 64-Bittige Windows zu, außerdem ist die Fehlermeldung selbst ja völlig anders. Dennoch habe ich mal den Patch dafür getestet, aber auch das brachte keine Änderung zum Guten.

Was habe ich noch getestet? Ach ja, ein neues Projekt: Leider ließ sich das Problem so auf die Schnelle nicht nachstellen, indem man einfach ein neues Projekt erstellt und da mal einen Öffnen-Dialog anzeigen lässt - dort funktionierte alles problemlos. Schade, sonst hätte ich wenigstens einen Schuldigen gehabt.

Ach ja, der Fehler wird in der ntdll.dll verursacht, falls es irgendwen gibt, der damit was anfangen kann:

Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7600.16385
Fehlermodulzeitstempel: 4a5bdadb
Ausnahmecode: 80000003
Ausnahmeoffset: 0009f8d2
Betriebsystemversion: 6.1.7600.2.0.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: d1ab
Zusatzinformation 2: d1ab624ec7d094c26a73530c245a3468
Zusatzinformation 3: d1ab
Zusatzinformation 4: d1ab624ec7d094c26a73530c245a3468

Ihr seht mich am Ende meiner Lösungsansatzideen. Natürlich kann es auch noch sein, dass ich mir selbst irgendwie den Speicher zerschieße und dass das bisher nur nicht aufgefallen ist. Allerdings sind zu dem Zeitpunkt ja noch kaum Daten geladen und dass es nur auffällt, wenn der Debugger läuft und Windows 7 und der Öffnen-Dialog, dann aber auch gleich bei zwei Rechnern und immer wieder... halte ich zumindest für unwahrscheinlich...

Ich brauche Hilfe. Und tröstende Worte.

Bis denn
Bommel

Edit:
Ich hab noch mal etwas mehr nach dem Fehlercode 80000003 gegoogelt. Das Ergebnis deutet meiner Meinung nach schon darauf hin, dass das hier irgendwas mit dem Debugger zu tun hat. Immerhin ist die Bezeichnung für den Fehler wohl hardcoded breakpoint und der Aufruf, der ihn auslöst, wird wohl auch vom Delphi-Debugger benutzt. Einen manuellen Breakpoint, wie etwa hier beschrieben benutze ich aber nicht.

Also, wirklich schlauer bin ich noch nicht, wollte euch aber am Zwischenergebnis teilhaben lassen...

[Bbommel]

Hallo zusammen,

hier mal eine kurze Rückmeldung, falls mal jemand über die SuFu über dieses Thema stolpern sollte. Letztlich lag das alles natürlich doch an mir selbst, auch wenn ich es vorher für unwahrscheinlich gehalten habe. Aber die beschriebene Kombination (Win7, Debugger, OpenDialog) hat letztlich wirklich einfach nur dazu geführt, dass mir Fehler auf die Füße gefallen sind, die schon ziemlich lange im Programm schlummern.

Ich hab die letzten Tage dann also damit verbracht mit FastMM nach Speicherlecks zu fahnden (und da haben sich mit der Zeit doch so einige angesammelt gehabt - hätte ich nicht gedacht), ".Free" durch "FreeAndNil" zu ersetzen und bin auch so auf Stellen gestoßen, an denen auf Objekte zugegriffen wurde, die schon längst freigegeben waren (was halt meisten zufällig gutging) usw. usf. - nun läuft das Programm wieder einwandfrei und wahrscheinlich, zumindest was die Speicherlecks&Co angeht, so sauber wie lange nicht.

Ach ja, die eigentliche Fehlermeldung entstand übrigens wirklich gaaaanz tief im System, nämlich in der Prozedur "_halt0" der systems-Unit, also wirklich bei dem allerallerletzten, was das Programm überhaupt macht. Letztlich führte dann der Aufruf von "ExitProcess" zu der Fehlermeldung.

Bis denn
Bommel