Zugriffsverletzung beim Beenden eines Programms nach LoadLibrary

[Tower1234]

Hallo Zusammen,

ich bin vor ein paar Tagen von Delphi XE2 nach XE6 umgestiegen, und nach ein paar Anpassungen lief alles problemlos.

Bis auf ein Problem, zu dem ich keine Idee mehr habe...

Das Problem tritt auf, sobald ich eine DLL mit LoadLibrary einbinde. Das Laden funktioniert problemlos, auch sämtliche Funktionen laufen, wie sie sollen.
Aber bei der Beendigung des aufrufenden Programms hagelt es "Access Violations". Oder genauer gesagt: nach Beendigung, jedenfalls an einer Stelle, die ich bisher noch mit keinem try-except-Block einfangen konnte. (starte ich die EXE ohne Compiler, erscheint 1-2 Sekunden nach Beenden ein Runtime Error)

Wohlbemerkt reicht für dieses Phänomen das einfache LoadLibrary. Selbst wenn die DLL sonst in keiner Form angesprochen wird, erscheinen die Access Violations.

Binde ich die DLLs über die frühe Bindung ein, tritt auch kein Problem auf. Aber aus diversen Gründen wäre die späte Bindung deutlich praktischer...

Falls jemand eine Idee hat - ich bin für alle Anregungen dankbar...!

[Uwe Raabe]

Mach doch frühe Bindung mit delayed .

Verzögertes Laden

[Bernhard Geyer]

Wenn eine DLL geladen wird so wird hier u.U. auch schon Quellcode ausgeführt.
D.h. die DLL hat einen Programmierfehler da sie nicht erwartet geladen aber nicht verwendet zu werden.

[jaenicke]

Wann wird die DLL denn entladen? Wenn das FreeLibrary zu spät kommt, sind evtl. schon Ressourcen aus der Exe entladen, wenn die DLL entladen wird.

Gibt es in der DLL vielleicht eigene Finalization Abschnitte oder Klassendestruktoren?

Die Zugriffsverletzung mit Stacktrace, wenn du sie postest, könnte evtl. auch etwas aussagen.

[Tower1234]

Das Entladen habe ich schon an verschiedenen Stellen versucht. Von direkt hinter dem LoadLibrary über die letztmögliche Programmzeile bis zum kompletten Auskommentieren.
Die Zugriffsverletzungen erscheinen (da war mein Ausgangspost nicht ganz korrekt, sorry) beim FreeLibrary oder - wenn dies auskommentiert ist - am Programmende.

Blöde Frage: Wie komme ich denn an den StackTrace?

@Uwe: Die frühe Bindung (ob delayed oder nicht) kommt leider nicht in Frage, weil man dort meinem Verständnis nach nicht den Pfad zur DLL angeben kann - was bei mir aber nötig ist.

Oder gibt es da doch eine Möglichkeit?
Das wäre sonst auch eine "elegante" Umgehung des Problems...?

[jaenicke]

Zitat von Tower1234:

Die Zugriffsverletzungen erscheinen (da war mein Ausgangspost nicht ganz korrekt, sorry) beim FreeLibrary oder - wenn dies auskommentiert ist - am Programmende.

Das ist die entscheidende Information. Damit ist klar, dass es beim Deinitialisieren der DLL passiert. Ist das deine eigene DLL? Dann siehst du den Stacktrace oben links, wenn du die DLL im Debugger ausführst, sprich mit dem Programm, das diese lädt, als Hostprogramm. Delphi hält bei der Exception ja an.

[Tower1234]

So, ich habe noch etwas forschen können:

Die DLL ist von mir, aber sie (alleine) scheint es nicht zu sein.
Erstaunlicherweise tritt der Fehler auf, sobald ich eine Unit aus der Jedi Code Library einbinde!

Und es scheint egal zu sein, welche. Zumindest konnte ich es mit verschiedenen reproduzieren...
Es ist die aktuelle Version der JCL, die auch für XE6 freigegeben ist und auch sauber installiert wurde.

Ich habe mal Google gefragt, aber es scheint zumindest nichts Generelles bekannt zu sein...

Der StackTrace gibt daher übrigens leider auch wenig her - meine Unload-Routinen, aber die sind ziemlich unspektakulär.

[jaenicke]

Installiere die JEDIs mal neu und nimm in den Installern der JCL und JVCL "Include Unit Versioning" heraus.

Wenn es daran liegt, sieht man das eigentlich im Stacktrace ganz einfach, weil die Schutzverletzung genau dort auftritt. Das Problem hatten wir bei DLLs auch, weshalb unsere Installationsprozedur die Entfernung dieser Häkchen vorsieht...

[Tower1234]

So, ich konnte es endlich testen und - das war's!

Vielen Dank, das Unit Versioning war tatsächlich die Ursache!

[Der schöne Günther]

Jetzt würde ich aber gerne auch den detaillierten Grund verstehen.