Reihenfolge vom Laden von Modulen

[freimatz]

Hallo,
wir haben in einem Projekt hunderte von Modulen. Das sind exe, bpl und dll. Viele davon sind von uns selbst und viele wiederum in Delphi geschrieben. Um letztere geht es mir.
Nun habe ich eine exe - aktuell ein Testprojekt - und frage mich warum ein package vor einem anderen geladen wird.
Umgekehrt: wie kann man rausfinden, welches package oder dll das erste Modul ist das geladen wird? Das wäre dann z.B. wichtig um dort FastMM oder andere

Was man im Event-Fenster mit "Load Module" sehen kann, ist nach unserer Einschätzung nicht das was wir erwarten. Etwas mehr trauen wir da ProcMon zu, wobei da man ja nur Dateizugriffe sehen kann und nicht die komplexere Operation Modul-Laden.

Mit "tdump -em. <exe>" sieht man importiere Module. Diese Liste beinhaltet jedoch nur einen Teil der geladenen Module.

Hat uns jemand Informationen oder Ideen?

(Noch komplexer wird es wenn man die Reihenfolge der units und des initialization betrachtet, aber eins nach dem anderen.)

[himitsu]

tdump gibt nur die statischen Imports und vielleicht auch DelayedImports an, von dem einen Modul (EXE).
Du mußt also auch noch alle deine DLLs und BPLs durchgehn.
Und dann auch noch die Hooks im Windows, wo dir auch noch was untergeschoben werden kann. (Maustreiber, Teamviewer, Acrobat, ...)



erstmal "Zufall",

aber grundsätzlich ist es so, dass bei deiner EXE, vor dem eigentlichen Start, die ImportListe durchgegangen wird und dort wird einfach der Liste nach alles geladen (von oben nach unten), beim Laden der einzelnen DLL/BPL dann wiederum (vorher) das, was sie lädt usw.

Die Liste(n) entsteht, beim Linken/Kompilieren, in welcher Reihenfolge es dort eingebunden wurde. (Delphi sortiert da nichts)


Dann vielleicht noch DelayedLoading, was erst beim ersten Aufruf eines Imports geladen wird,
und natürlich das dynamische Laden (LoadLibrary/LoadPackage), was irgendwo mitten in der Ausführung (im Intitialisazionscode oder später im Code) geladen wird.




Ist ähnlich, wie mit deinen Units.
Es geht erst in der DPR/DPK die Liste durch, dann das USES im Interface-Abschnitt der PAS ... da beides in der Reihenfolge der Deklaration
und zum Schluß auch noch das USES im Implementations-Teil ... dort kann Delphi sich frei entscheiden, in welcher Reihenfolge (für dich also zufällig).

Beim Laden einer Unit wird dann wieder dessen USES abgehandelt usw.


Also abgesehn vom Implementations-Uses, kann man die "statischen" Verlinkungen der DLL/BPL mit der Art der Reihenfolge bei den Units vergleichen.
Das Implementations-Uses und die delayed+dynmamischen DLLs und die Hooks, bringen hier bissl Chaos rein, aber sonst ist die Reihenfolge eigentlich fest.



Im Programm gibt es Events, um sich über das Laden von DLL/BPL informieren zu lassen,
bzw. ich hatte mir auch mal aus der PEB die Infos rausgeholt ... da gibt es 3 Listen, wovon eine der Reihenfolge des Ladens enspricht, inkl. einer Angabe "warum" es geladen wurde (statisch, delayed oder dynamisch).

[himitsu]

Im Log des Debuggers steht das LOADED und UNLOADED, also wenn die DLL/BPL fertig geladen wurde.
Im ProcMon siehst du dagegen quasi das BeforeLoading.

[freimatz]

Danke für alle deine Ausführungen. Das in deinem Nachtrag haben wir irgendwie so geahnt.
Wenn ich Dich recht verstehe müsste man ja doch nur die ImportListe rekursiv durchgehen - oder? Gibt es dafür nicht schon Tools dafür?

Noch ein Aber: wir haben in der dpr der exe die Ziele "{$R <name>Manifest.res}" auskommentiert. Dadurch hat sich die Reihenfole deutlich geändert. In der res Datei müsste sich ein Manifest befinden, in dem u.a. COM-Klassen registriert sind. Weiss Du - oder sonstwer - etwas darüber?

[himitsu]

In dem Manifest steht aber auch drin, dass Windows die "neue" CommonControlsAPI v6+ verwenden soll,
sonst werden stattdessen quasi die alten VorXP-DLLs vom Windows geladen.


Wenn es bloß um die BPL geht, dann kann man die .d auslesen (in den Projektoptionen die C++-Dependencies aktivieren)
oder das requires der .dpk und die .dproj der .dpr.
(requires der .dpk ... da hab ich einen echt bösen Code im DevExpressCompiler versteckt ... ja, aus dem LSP wäre es mir auch lieber)

Will man nur wissen wo welche Ressource-Datei drin ist, dann in den .d nachsehn oder in der .map.

Ich weiß nicht, ob der PE-Explorer rekursiv kann
aber ich glaub einer der Delphi-Decompiler hatte was dafür drin.


Die "wahre" Reihenfolge, inkl. dynamischem Laden und abhängig vom DelayedLoading, bekommt man nur durch Loggen, wenn die Anwendung ausgeführt wird.

Es gibt viele Programme und Delphi-Codes, welche das von einer "Binary" auslesen, aber ich fürchte zusammenfassen mußt du es dann selbst.
"C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\tdump.exe" -em deine.exe

tdump64.exe und natürlich Beides für exe, dll und bpl



Falls jemand ein paar Wochen/Monatchen warten kann ... paar Projekte für sowas hab'sch noch in der Pipeline, in Bezug auf meinen eigenen Debugger und ein anderes Projekt.

[freimatz]

Zitat von himitsu:

In dem Manifest steht aber auch drin, dass Windows die "neue" CommonControlsAPI v6+ verwenden soll,
sonst werden stattdessen quasi die alten VorXP-DLLs vom Windows geladen.

Darum geht es mir nicht. Wie ich schrieb sind mir nur die eigenen Module wichtig.
Weil sich die Reihenfolge mit und ohne Manifest ändert, schliesse ich daraus, dass es nicht nur an der Importliste liegen kann in welcher Reihenfolge die Module geladen werden.
Ein Kollege meinte, dass vermutlich alle Module beim Start geladen werden die dort drin stehen.

[Kas Ob.]

Hi, i am not sure i do understand the question !

You need a way to see and log the order of modules/DLLs/libraries being loaded ?
In that case, the debugger is the most trust one, and of course ProcMon will record them , and there is API Monitor too like this


If you asking what decide their loading order why do they change loading order, then the answer is that : there is background threads doing the loading, this might be your own threads or COM library with (hidden/not visible) OS thread doing that, you didn't mention if your application is using COM/DCOM..