Dynamische DLL ausladen läßt Anwendung abstürzen

[Thomas Feldmann]

Hallo,

habe ein Problem mit dem Ausladen einer dynamisch geladenen DLL. Nach dem
Versuch des Ausladens mit Win32Check (FreeLibrary(h...)); ist die Anwendung
eingefroren und läßt sich nicht beenden. Leider ist es auch nicht möglich,
die Fehlerstelle im Debugger zu finden oder eine Windows Fehlermeldung zu bekommen, da sich alles irgendwo in Windows aufhängt.
In der Hilfe von Delphi 5 Enterprise las ich unter D´lls und Active X von
einem ähnlichen Problem mit Delphi 3 Dll´s (QR 2.0). Danch ist Borland das
Problem bekannt und man wird eine Lösung finden. Hat jemand von einer solchen Lölsung schon etwas gehört?
Für einen kurzen Tip wäre ich dankbar!

Thomas Feldmann

[Witold Rompa]

habe das gleiche Problem, aber nur unter win95/98

Witold Romp

[Andreas Kosch]

Hallo,

was ist das für eine DLL? Lässt sich der Fehler mit einem kurzen Beispiel jederzeit reproduzieren

[Witold Rompa]

Hallo Herr Kosch,

ich habe so ziemlich alle Möglichkeiten ausprobiert die LoadLibrary betreffen, (auch die Beispiele aus Ihrem Buch win32 Lösungen).

Dabei auch die einfachste Form
LibHandle := LoadLibrary(‚name.dll);
...
FreeLibrary(LibHandle);

Bei Einsatz unter win2000 oder WindowsNt keine Probleme.
Jedoch unter win95/98 beim ausführen von FreeLibrary(LibHandle) keine Reaktion mehr.
Um weiterzukommen setzte ich CreateProcess ein.

Ich verwende Delphi 5 Enterptise UP 1 + AdoUp2.

Danke für Ihre Hilf

[Hagen Reddmann]

Hi

Was ist in der DLL, Formulare, COM, ActiveX ?
Wurde mit Laufzeitpackages compiliert ?
In welcher Sprache ist die DLL programmiert ?
Wenn mit Delphi, nutzen die EXE & DLL den Shared Memory Manager aus Unit ShareMEM ?
Erzeugt die DLL eigene Threads ?
Benötigt die DLL einen Messagequeue, also hat sie Windows-Fensterhandle ?
Implementiert die DLL irgendwelche Hooks, Callback funktionen ?

Wir brauchen schon mehr Input

Gruß Hage

[Witold Rompa]

Hallo Herr Rodemann.

Danke für die schnelle Antwort.

Es sind mehrere DELPFI DLL’s die in nach bedarflade, in einer befinden sich Formulare,in der anderen Reports (QR) . Das Ergebnis bei win95/98 ist das gleiche.(keine Reaktion bei FreeLibrary)

Es wurde nicht mit Laufzeitpackages compiliert.

Grundsätzlich versuche ich ohne ShareMEM auszukommen, in diesem Fahle habe ich es auch versucht, ohne Erfolg.

Ich gehe immer nach dem Schema vor, in früheren Projekten funktionierte das auch. Der einzige Unterschied der mir im Moment einfeld, der Entwicklungs- Rechner ist jetzt win2000 früher win95, aber ??

Grüße Witol

[Hagen Reddmann]

Jaja, das sind die Probleme mit DLL's und DLL übergreifenden Klassen etc. Ich habe im Forum schon mehrmals darauf hingewiesen, das die gemeinsamme Nutzung von Delphi-Forms etc. aus DLL's OHNE gemeinsame Laufzeitpackages gefährlich ist.

Als erstes werden alle DLL's überprüft die Formulare enthalten. Ich nehme an das in diesen DLL's das interne Application Object auf das der EXE "umgebogen" wird. Das ist gefährlich, und muß VOR dem entladen der DLL wieder korrekt rückgängig gemacht werden. Als nächstes mal schauen wie die Formulare in den DLL's erzeugt werden. Wer ist der Owner oder bei MDI Clients der Parent ?!
Als nächstes mal schauen ob irgendwelche globale Event's genutzt werden. Z.B. Application.OnMessage / Screen.OnActiveControlChange etc. wird in der DLL genutzt.
Nun, falls Du ShareMem nutzt, dann solten ALLE DLL's und die EXE ihn nutzen (immer als ERSTE Unit im *.dpr Source). Falls Du ihn NICHT nutzt dann sollte KEINE DLL ihn nutzen. Da Du aber Formulare/QR in DLL's nutzt MUSST Du ShareMem nutzen. Nur falls Du in ALLEN DLL's und EXE mit Laufzeitpackages arbeitest kann in Deinem Fall auf ShareMem verzichtet werden, da ja dann sowieso nur ein MM aktiv ist.

Nun, QuickReport ist so'ne Sache. Sehr bekannt für das schlechte Laufzeitverhalten. Grundsätzlich ist meiner Meinung nach QR nicht geeignet um in DLL's oder Packages genutzt zu werden. Dafür gibt es mehrere Gründe:
<li>Keine oder falsche "Deinitialisierung der globalen QR Objecte"
<li>Keine Entfernung von Hooks auf andere globale Objecte
<li>massive Memoryleaks

Gruß Hage

[Witold Rompa]

Danke für die schnelle und so exakte Antwort.

Grüße Witol