Ich kämpfe seit einer Code-Änderung mit o.g. Exception welche beim beenden meines Programmes auftritt (innerhalb der IDE).
---------
Im Projekt ACalc.exe ist eine Exception der Klasse EAccessViolation mit der Meldung ´Zugriffsverletzung bei Adresse 0040B110 in Modul ´ACalc.exe´- Lesen von Adresse 400C87D´ aaufgetreten-
Anhalten – Fortsetzen - Hilfe
---------
Fortsetzen der Ausführung resultiert in einem "Runtime Error 216 at 0040945A"
---------

- Das Problem tritt nur in einer meiner Applikationen auf, andere laufen einwandfrei (also vermutlich kein Fehler in der delphi IDE)
- Ich habe nur ein BackUp einer deutlich älteren Version auf welche ich ungern zurückgreifen möchte
- Ausklammern der zuletzt geschriebenen Routinen im SourceCode -> keine Verbesserung
- Aus Forum und Google-Suche vermute ich auf einen Fehler beim "Destroy" der Applikation.
Die Destroy-Routine des Hautforms habe ich bereits testweise "geleert" (keine Verbesserung)
- Ich vermute eher das ich beim umbasteln der GUI evtl. etwas benötigtes aus Versehen gelöscht habe ?!?

wie gehe ich am besten vor um dem Fehler auf die Spur zu kommen?
Die o.g.. Fehleradresse hilft mir ja vermutlich nicht weiter, oder?

LG Martin

Fehler beim Beenden sind schwer zu finden. Sind Threads im Programm?

Zitat von MartinK:

...
Die o.g.. Fehleradresse hilft mir ja vermutlich nicht weiter, oder?

LG Martin

evtl schon, wenn hier versucht wird auf ein von dir erzeugtes, aber schon
zerstörtes Objekt bzw. Fenster zuzugreifen.
Dann rausfinden welches das ist.

Man beachte das Freigeben von Fenstern mit .release !

Wenn du "Anhalten" auswählst solltest du an die Stelle kommen, an der der Fehler auftritt. Schau dann mal in den Callstack, ob dort etwas auffälliges steht.
Benutzt deine Anwendung andere DLLs? (Stichwort: Sharemem)
Weitere Möglichkeit, um Fehler aufzuspüren, ist die FastMM als FullDebug zu benutzen (wie müsste auch hier irgendwo im Forum stehen).

Hmm
- Threads werden nicht benutzt
- Anhalten breaked auf einer ASM zeile innerhalb "procedure _UStrClr" aus der System Unit
- Der Aufruf stack ist auch nicht wirklich aussagekräftig, verweist ebenso auf die _UStrClr

ich denke mal ich habe weniger Aufwand wenn ich aus dem Backup und der neuen fehlerhaften Version eine zusammenrestauriere


Danke für Euren Support
LG Martin

Ich find die Information ziemlich aussagekräftig.
Wenn ich in der Vergangenheit diesen Fehler hatte, handelte es sich meist um das Fehlen der Sharemem in der uses wenn Strings an/von DLLs übergeben wurden. In einigen anderen Fällen war das Herumpfuschen an Strings über Pointer schuld.

Ist 216 nicht generell ein (Memory/Pointer)-Fehler außerhalb der Kontrolle der eigenen Applikation, also z.B. wenn die Exceptionbehandlung noch nicht oder nicht mehr aktiviert ist (im Init bzw. Finalize der Anwendung), oder eben in einer DLL? Sharemem ist da nur eine Möglichkeit (Pointer ist aber generell die richtige Richtung).

Ich hatte das bei Threads mit FreeOnTerminate=True, die dann irgendwann terminierten (wenn Classes.pas schon längst finalisiert war).

Andere Möglichkeit, wenn keine Fremd-DLL im Spiel ist: Breakpoint auf das 'End.' der Anwendung legen und dann per Single-Step die Finalisierungs-Teile der Units durchsteppen...