Applikation hängt beim Beenden. Abschießen unmöglich

[alzaimar]

Ahoi

Der Titel sagt schon Alles.
Wir haben hier eine Applikation, die per DLL mit einer Steuerungsschnittstelle kommuniziert. Diese ist ziemlich tief im Windows-System verwoben, was sich durch den Umstand bemerkbar macht, das die Steuerungssoftware selbst dann weiterläuft, wenn Windows mit einem BSOD abschmiert oder sonst irgendwie abgeschmiert ist (was eigentlich nicht vorkommen darf, aber so stehts im Prospekt).

Nun denn, die Schnittstelle ist also eine DLL, die statisch von Delphi geladen wird (durch die 'external' Direktive). Desweiteren laufen diverse Threads in der Anwendung. Anwender berichten nun, das diese Anwendung ab und zu beim Beenden nicht aus dem Speicher verschwindet, sie ist in der Prozessliste noch zu sehen und lässt sich durch den Taskmanager *nicht* abschießen.

Ich dachte zuerst an einen nicht terminierenden Thread, aber dann kann man die App doch abschießen, oder?

Blöderweise funktioniert ein Teil der Applikation immer noch, sodaß die Steuerungssoftware denkt, die App läuft, obwohl sie in Wirklichkeit vollkommen breit im Speicher rumgeistert und keinen Ton von sich gibt.

Meine Frage:
Kann das Hängen und vor allen Dingen das nicht-abschießen-können damit zu tun haben, das die Anwendung gerade in der DLL ist, die widerum in den Tiefen von Windows rumrödelt? Lohnt es sich also, die DLL dynamisch zu laden und bei Programmende kontrolliert zu einem bestimmten Zeitpunkt X selbst freizugeben, um diesen undeterministischen Zustand zu vermeiden? Ich würde den Aufruf der DLL sogar über eine Critical Section kapseln oder irgendwie sicherstellen, das die DLL nur dann entladen wird, wenn gerade kein Zugriff darauf stattfindet.

Bringt das was?

[SirThornberry]

das von dir beschriebene Verhalten kenne ich. Ich hatte es bisher nur beim direkten Ansteuern der seriellen Schnittstelle über einen Treiber der beim Start der Anwendung installiert wurde und über eine DLl angesprochen wird. Hängt das ganze dann im Treiber kehrt natürlich der DLL aufruf nicht zurück und abschießen geht auch nicht weil ja sonst der Treiber totalen Schwachsinn macht.
Daher ist die Treiberprogrammierung auch eine Kunst für sich weil es nicht möglich sein soll das eine Anwendung das System kontrollieren soll. Ziel bei Treibern sollte sein, dass der Treiber auch noch funktioniert wenn während der Kommunikation eine Schnittstelle abschmiert (sei es ein Gerät oder eine Application)

[alzaimar]

Gut, das dachte ich mir.

Ich würde also:
1. Vor jedem Zugriff auf die DLL ein Flag prüfen ( à la 'InShutdownMode')
2. Im OnClose dieses Flag auf True setzen.
3. Warten, bis kein Aufruf mehr in der DLL ist
4. Die DLL aus dem Speicher werfen (alle zukünftigen Aufrufe werden fehlschlagen)
5. Die Anwendung normal terminieren.

Wissen tut man natürlich nicht, ob das ganze dan funktioniert, da dieser Fehler einer dieser tollen 'passiert in Taiwan, aber sonst nur Dienstags, außer wenn es draußen regnet oder auch nicht, manchmal eben' Fehler ist.

Danke für die Bestätigung.

[ULIK]

Hi,

so spontan würd ich jetzt sagen: DLL dynamisch laden. Dann beim Schliessen entladen und dabei warten, bis das auch geschehen ist (CloseQuery Event?). Hat ja nebenbei auch den Vorteil, daß man beim Start auf das Nichtvorhandensein der DLL vernünftig reagieren kann

Uli

[alzaimar]

Das mit dem Entladen und warten schaue ich mir an. Das die DLL wider erwarten nicht auf dem Zielrechner ist, kann nicht passieren bzw. muss nicht explizit behandelt werden. Die DLL ist Bestandteil des Images, der im Produktionsprozess auf den Prozessrechner geblasen wird. Trotzdem ein guter Hinweis!

[ULIK]

Du unterschätzt die Kreativität der Benutzer beträchtlich! Und wenn's nur der Virenscanner ist, der fälschlicherweise die DLL als Virus erkennt und in die Isolation schiebt.

Grüße,
Uli