Run-Time Error 216 beim Beenden der Anwendung

[HStrohmaier]

Hallo!

Ich habe ein seltsames Phänomen auf einem meiner Dev-Systeme ((D6 Ent., UP2): Einige meiner Anwendungen melden beim Beenden einen Runtime-Error 216. Mit dem Debugger oder der Suche nach Laufzeitfehler komme ich nur auf (mir) nichtssagende Teile des Assembler-Codes im CPU-Fenster. Interessanterweise tritt dieser Fehler *nicht* auf, wenn ich die Anwendung vor dem Beenden minimiere und wieder herstelle oder alternativ irgendein anderes Fenster auf dem Desktop kurz anklicke und meine Anwendung wieder aktiviere. Ein automatisiertes Minimize in der DPR-Datei als letzte Anweisung vor den ganzen finalization-Abschnitten löst das Problem ebenfalls:

Delphi-Quellcode:

...
  Application.Run;
  Application.Minimize;
End;

Was auch noch hilft: im Debugger einen Breakpoint auf das "End;" setzen und zwei bis drei Sekunden warten und dann mit F9 weiterlaufen lassen. Schon geht es

Der Anwendung ist lediglich ein FromDestroy-Ereignis zugeordnet, welches aber keinen Einfluß auf den beschriebenen Effekt zu haben scheint. Die von mir verwendeten 3rd-Party-Bibliotheken sind u.a. IP*Works!, NTSet, CoolTrayIcon, u.a. und ich binde diverse ActiveX-Controls ein. ShareMem hat keinen Einfluß und schrittweises Entfernen von Code macht mich wahnsinnig, weil ich zwar Code entfernen kann, bis der Effekt nicht mehr auftritt. Aber wenn ich dann den letzten Schritt wieder rückgängig mache, tritt das Problem oftmals gar nicht auf. Ich muß dann wieder mehrere Schritte einmal zurück und kann den Fehler trotz systematischer Suche nicht richtig eingrenzen.

Viele Grüße

-=HS=-

[Luckie]

Du kannst in der Hilfe nachgucken, was Laufzeitfehler 216 ist. Soweit ich mich erinner, ist das eine AccessViolation. Du scheinst auf Speicher zuzugreifen der ungültig ist. Das muss nicht unbedingt an der Stelle sein an der der Debugger stehen bleibt.

[HStrohmaier]

Hallo Luckie,

Zitat von Luckie:

Du kannst in der Hilfe nachgucken, was Laufzeitfehler 216 ist. Soweit ich mich erinner, ist das eine AccessViolation. Du scheinst auf Speicher zuzugreifen der ungültig ist. Das muss nicht unbedingt an der Stelle sein an der der Debugger stehen bleibt.

das mit der Hilfe und dem Laufzeitfehler hatte ich schon geprüft. Leider ist mir nicht klar, wieso ich plötzlich nicht mehr auf diesen Speicher zugreife, wenn ich auf dem Desktop mal eben auf eine andere Anwendung klicke und dann wieder auf mein Programm - denn dann tritt der Fehler nicht mehr auf. Und einen Eventhandler, der auf die Aktivierung der Anwendung reagiert, habe ich nicht implementiert. Das macht alles nur die VCL.

Noch eine Idee?

-=HS=-

[p80286]

Hallo HS,

Luckies Vorschlag ist garnicht soweit hergeholt, weil der Teufel ist ein Eichhörnchen.
Ich empfehle Dir die Finalization-Abschnitte zur Überprüfung.

Übrigens Deine Einwände sind durchaus berechtigt. Nur was Du als Fehler benennst sind vom System erkannte Fehlersituationen. Die erst durch Programmfehler hervorgerufen werden KÖNNEN aber nicht müssen. Nimm es als Hinweis, daß irgendwo bei der Programmbeendigung etwas morsch ist.

Gruß
K-H

[DeddyH]

Wenn mein löchriges Gedächtnis mich nicht täuscht, hatten wir so etwas erst neulich im Zusammenhang mit Komponenten einer bekannten Sammlung (ob Indy oder Jedi, weiß ich nicht mehr). Schuld war auch hier der finalization-Abschnitt einer verwendeten Komponente. Da hilft wohl nur Durchforsten ("In Dateien suchen").

[nahpets]

Hallo,

blöde Frage, ist es ein Timingproblem. Alles was Du zusätzlich machst, dauert Zeit, Klicken, Minimieren... .
Es könnte sein, dass da die Reihenfolge der Freigabe von was auch immer nicht stimmt und deshalb irgendwer noch Speicher braucht, den jemand anders schon freigegeben hat. (Erstellungsreihenfolge?)
Gibt es mehrere Formulare, die eventuell gegenseitig auf Komponenten zugreifen, Werte abfragen... ? Da ist mir sowas auch schon mal passiert.

Hilft am Ende eventuell ein Sleep(1000)? Das würde diese Vermutung bestätigen, wäre jedoch keine optimale Lösung.
p80286 und DeddyH liegen da mit ihrer Vermutung wahrscheinlich sehr nah an dem Problem.

Stephan