Runtime error 217 bei FreeLibrary

[jaenicke]

Die DLL ist nicht von dir?

Ich würde als erstes einmal mit dem Process Monitor schauen was vor dem Fehler alles passiert. Rechteprobleme würde man da z.B. ganz gut sehen.

Klar ist jedenfalls, dass in der DLL eine unbehandelte Exception auftritt. Insofern kann man da von außen ohne Quelltext nicht allzu viel sehen, es sei denn man kann genug Assembler um sich das auch ohne Quelltext anzuschauen.

[JohannesK]

Die Schnittstellen-DLL ist auch von mir, dort sind sämtliche Aufrufe in einen try ..except drin. Alle Funktionen werden ja auch ordnungsgemäss und vollständig ausgeführt.
Hatte ich vergessen zu erwähnen: in der Regel tritt der Fehler erst beim zweiten Aufruf innerhalb einer Buchungsliste auf, obwohl jede Buchung für sich einen abgeschlossenen Vorgang darstellt.
Von der Protokollierung her ist ersichtlich dass es erst bei der Freigabe kracht.

[Der schöne Günther]

Ist die DLL mit Delphi gemacht? Enthält sie auch VCL-Bestandteile?

[JohannesK]

Die DLL ist mit Delphi gemacht, genau wie die exe.
Der Aufruf enthält auch keine Strings. Durch verwendete units können schon VCL-Komponenten mitkompiliert werden, aber es gibt keine Formulare die geöffnet werden.

[dummzeuch]

Ist das Problem wirklich User-abhängig? Also:

User A meldet sich an, startet das Programm, macht etwas und beendet es. -> Fehler tritt auf

User B meldet sich an, startet das Programm, macht dasselbe und beendet es. -> Fehler tritt nicht auf

Falls sich das so nicht reproduzieren lässt, würde ich eher darauf tippen, dass der Fehler durch ein anderes Programm ausgelöst wird, das User A vorher / gleichtzeitig verwendet und User B nicht.

[JohannesK]

Der Fehler ist genau in der Art userabhängig und reproduzierbar

Zitat:

User A meldet sich an, startet das Programm, macht etwas und beendet es. -> Fehler tritt auf
User B meldet sich an, startet das Programm, macht dasselbe und beendet es. -> Fehler tritt nicht auf

[Sinspin]

Wir hatten solche Fehler auch schon.
Fehlergründe waren bisher:
* Nutzer hat, warum auch immer, einer falsche Version vom Pogramm installiert und die neue lässt sich nicht installieren.
* Nutzerprofil Quota Einstellungen für den Plattenplatz lokal und im Storage, Also Speicher reichte nicht aus. Fiel erst nicht auf weil die DBs für Outlook versteckt ist und nicht überall als verbrauchter Speicher angezeigt wurden.

[JohannesK]

Zitat:

Nutzer hat, warum auch immer, einer falsche Version vom Pogramm installiert und die neue lässt sich nicht installieren.

Kann man ausschliessen, es ist die gleiche Maschine, einziger Unterschied ist der Windows-User

Zitat:

* Nutzerprofil Quota Einstellungen für den Plattenplatz lokal und im Storage, Also Speicher reichte nicht aus. Fiel erst nicht auf weil die DBs für Outlook versteckt ist und nicht überall als verbrauchter Speicher angezeigt wurden.

Muss ich mit dem Admin des Kunden prüfen

[jaenicke]

Zitat von JohannesK:

Zitat:

* Nutzerprofil Quota Einstellungen für den Plattenplatz lokal und im Storage, Also Speicher reichte nicht aus. Fiel erst nicht auf weil die DBs für Outlook versteckt ist und nicht überall als verbrauchter Speicher angezeigt wurden.

Muss ich mit dem Admin des Kunden prüfen

So etwas sieht man auch sofort im bereits erwähnten Process Monitor.

Vielleicht wird auch etwas beim ersten Durchlauf freigegeben, das nicht wieder erzeugt wird, so dass es beim zweiten Mal durch die doppelte Freigabe knallt. Auch dann kommt der Fehler, aber es gibt eben sehr viele Möglichkeiten.

Wird der Fehler denn irgendwo abgefangen, z.B. hinterher im Hauptprogramm? Gibt es dazu Logs mit Stacktrace (ggf. auch mit Tools wie MadExcept oder Eurekalog)? Ansonsten wird der Fehler vielleicht von Windows geloggt, dann wären Debuginformationen im .dbg Format von Windows hilfreich, die man mitliefern kann.

[jziersch]

Verwendet die DLL interfaces?

Falls ja würde ich mal suchen ob evtl. diese explizit freigegeben werden oder z.b. in einem Record überschrieben.

Ansonsten kann man die finalization durchgehen und schauen was so passiert.
Ein paar logging Aufrufe vor dem Aufruf der Destruktoren könnte helfen den Fehler einzugrenzen.

Gestern habe ich einen Fehler in einer utility unit behoben bei der ein TDictionary für <Interfaces> verwendet wurde.
Der Fehler beim Beenden war weg, als ich dies auf Pointer geändert habe.