Fehler durch __dbk_fcall_wrapper?

[Ralf Kaiser]

Hallo,

Wir haben bei einem Programm in Delphi Berlin einen seltsamen Effekt:

Nachdem das Programm (scheinbar) beendet wurde ist es immer noch im Taskmanager zu sehen, läuft also eigentlich noch. Dabei verbraucht es ca. 25% der CPU-Last. Eine Prüfung mit dem ProcessExplorer ergab, dass dort ein Thread noch läuft der im ProcessExplorer mit dem Namen "NameDerExe.exe!__dbk_fcall_wrapper" markiert ist, dieser läuft mit 25% Prozessorlast (4 Kerne, es wird also ein Kern komplett ausgelastet).

Weiterhin passiert dies nur wenn das Programm durch unseren Build-Vorgang erzeugt wurde, eine lokal in der IDE kompilierte Version zeigt dieses Verhalten nicht. Ich gehe also davon aus, dass es sich um einen Unterschied in den Bibliotheken Debug vs. Release handeln muss. Das Programm verwendet etwa 70 selbst erstellte BPLs und noch einige 3rd-Party Komponenten.

Im Netz habe ich schon Hiweise auf dieses ominöse "__dbk_fcall_wrapper" gefunden, es hat scheinbar etwas mit der Speicherverwaltung zu tun. Allerdings bezogen sich alle Hinweise die ich bisher gefunden habe auf die Delphi-Version Seattle, wir erstellen das Programm aber mit Delphi Berlin. Außerdem bezogen sich alle Hinweise im Netz auf die "borlndmm.dll" die wir aber nicht verwenden (zumindest nicht als DLL)

Mit den PE-Informationen der GExperts habe ich herausgefunden, dass bei allen BPLs diese Routine "__dbk_fcall_wrapper" in der Exportliste enthalten ist.

Hat schon mal jemand ähnliche Probleme in Delphi Berlin gesehen? Ich habe im Moment keine Idee mehr, welche Versionen von BPLs ich mal testweise austauschen soll oder wie ich dem Problem überhaupt näher kommen kann.

Vielen dank schon mal für jeden noch so kleinen Hinweis!!

Ciao,
Ralf

[TiGü]

Auf Verdacht:

Die EXE aus dem Build-Vorgang mit Dependency Walker öffnen und prüfen, ob irgendein Modul auf die BORLNDMM.DLL zeigt?

Werden die BPLs und Third-Party-Komponenten im Build-Vorgang ebenfalls komplett neu gebaut?

[Ralf Kaiser]

Zitat von TiGü:

Auf Verdacht:

Die EXE aus dem Build-Vorgang mit Dependency Walker öffnen und prüfen, ob irgendein Modul auf die BORLNDMM.DLL zeigt?

Werden die BPLs und Third-Party-Komponenten im Build-Vorgang ebenfalls komplett neu gebaut?

Die BORLNDMM.DLL wird in keinem Modul referenziert (sie ist auch gar nicht im Build enthalten, es würde also auf einem "sauberen" Rechner eine Fehlermeldung wegen der fehlenden DLL geben, was nicht der Fall ist)

Die BPLs werden während des Build natürlich neu gebaut. Die 3rd-Party BPLs nur wenn sich dort eine Version geändert hat (ist ein eigener Build der die erzeugten BPLs in Lib-Verzeichnisse auf dem Buildserver kopiert)

[TiGü]

Zum Ausschließen die 3rd-Party-Komponenten mal neu bauen? Außer Zeit und Strom kostet es ja nichts.

[TiGü]

Habt ihr das Problem letztendlich lösen können?

[Ralf Kaiser]

Ja. Ich habe die externen und alle internen Bibliotheken neu gebaut und im Buildprozess aktualisiert. Danach war der Fehler plötzlich weg (ich hatte nur in letzter Zeit zu viel um die Ohren, darum habe ich mich nicht mehr gemeldet)