Runtime error 217 bei FreeLibrary

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

[JohannesK]

Zitat von 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.

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.

[Gremlin]

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

[JohannesK]

Zitat von Gremlin:

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.