Runtime error 217 bei FreeLibrary

[JohannesK]

Guten Morgen alle,

ich bekomme bei einem Kunden einen bisher nicht eingrenzbaren Fehler beim Aufruf von FreeLibrary (und nur bei diesem Kunden).

Kurze Beschreibung:
Meine Anwendung ruft eine DLL auf in der die Schnittstellen zu unterschiedlichen ERP-Systemen enthalten sind. Der Aufruf und die Aufgaben werden richtig ausgeführt. Beim Aufruf von FreeLibrary kommt es zu einem Laufzeitfehler.
Das Problem dabei ist, dass der Fehler benutzerabhängig ist. Er tritt auf bei bestimmten Windows-Nutzern. bei anderen nicht (gleicher Rechner, nur anderer User). Der Admin des Kunden versichert, dass die Userprofile identisch sind - gleiche Rechte auf Windows-Ebene. Es gab auch schon die Situation, dass es nach Neuaufbau des Userprofils für ein paar Stunden fehlerfrei funktioniert hat.
Eine Vermutung von mir ist daher, dass vielleicht irgendein Schutzprogramm die DLL nach mehreren Aufrufen auf eine "schwarze Liste" setzt und den Zugriff verhindert.

Hat jemand eine Idee - ich bin für jeden Hinweis dankbar.

[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:

Zitat von JohannesK (Beitrag 1480900)

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.

[Gremlin]

Ist es möglich, dass eine verwendeten Funktion der DLL für einen PChar zu große Rückgabewerte liefert?

[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.

[JohannesK]

Zitat:

Zitat von Gremlin (Beitrag 1480903)

Ist es möglich, dass eine verwendeten Funktion der DLL für einen PChar zu große Rückgabewerte liefert?

Eigentlich nicht, der Wert ist bei einer fehlerfreien Ausführung der Dll leer.
Ausserdem erklärt es nicht das unterschiedliche Verhalten bei Nutzerwechsel.

[JohannesK]

Zitat:

Zitat von jziersch (Beitrag 1480905)

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.

Interfaces werden nicht verwendet in dieser unit. Der Fehler müsste dann ja auch benutzerunabhängig auftreten.

[JohannesK]

Wir haben aus Zeitgründen die Funktion von den Clients auf den Server verlagert und arbeiten jetzt die Buchungen über einen Dienst ab, ohne jedes Problem.
Eine wirkliche Ursache für das Verhalten konnten wir bisher nicht finden, der Kunde arbeitet nach Aussage des Systemverantwortlichen z.B. auch nicht mit Quota-Regeln für seine User.

Trotzdem Danke für alle Tipps in diesem Zusammenhang. :)