2016-06-27 11 views
3

Ich habe große Legacy-C++ - Anwendung (Visual Studio 2010), und ich muss etwas Code ausführen, bevor eine bestimmte DLL geladen wird. Das Problem ist, dass die DLL geladen wird, bevor ich irgendeinen Code ausführe, also versuche ich herauszufinden, was das Laden auslöst.Finden Sie, wo DLL geladen wird in C++ - Programm (MFC)

Ich habe DELAYLOAD für die DLL in den Link-Optionen angegeben, die das Laden der DLL stoppen sollte, bevor es benötigt wird. Aber es wird immer noch geladen, bevor ich irgendeinen Code ausführe. Die Anwendung ist MFC, also ist mein Einstiegspunkt eine Überschreibung von CWinApp :: InitApplication().

Ich vermute, dass es eine globale Variable in der Anwendung sein muss, die auf einen Typ in der DLL verweist, aber ich bin mir nicht sicher, wie die Variable zu finden ist (die Codebasis ist groß und Globalen werden nicht konsistent benannt).

Irgendwelche Ideen, um zu finden, was die DLL-Last auslöst, oder wie man die globale Variable findet?

+0

Suchen Sie nach 'LoadLibrary'-Aufrufen, oder laden Sie implizit' #pragma comment (lib ...) 'Zeilen. – PaulMcKenzie

+1

@PaulMcKenzie: Das OP sucht nach DLLs, die geladen werden, bevor ein Benutzercode ausgeführt wird. 'CWinApp :: InitApplication' ist das moralische Äquivalent von C's' main'. Das OP sucht weder nach expliziten LoadLibrary-Aufrufen, noch sucht es nach Linker-Direktiven (sie wissen bereits, dass die Bibliothek verknüpft ist). Sie suchen nach dem Grund, warum eine Delay-Load-Bibliothek geladen wird, obwohl anscheinend noch kein Export erfolgt ist. – IInspectable

+3

Sie könnten die delay-load * -Helferfunktion * außer Kraft setzen und prüfen, welche Symbole das Laden der DLL auslösen. Siehe https://msdn.microsoft.com/en-us/library/09t6x5ds(v=vs.100).aspx. – dxiv

Antwort

3

Ich habe das Problem behoben, indem ich einen Haltepunkt auf der delay-load helper-Funktion, __delayLoadHelper2, gesetzt habe. Diese Funktion finden Sie in:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\delayhlp.cpp 

Sie wird aufgerufen, wenn eine DLL geladen wird, die für die Verzögerung geladen wurde.

Ich legte den Haltepunkt in __delayLoadHelper2 und sah den Call-Stack, wenn es getroffen wurde. Dies zeigte die Funktion in meinem Code, die die DLL-Last ausgelöst hat.

Es wurde von einem globalen Singleton-Konstruktor ausgelöst, der einen Typ aus der DLL erstellte. Dieser Code wird vor CWinApp::InitApplication() ausgeführt.

+0

Ich verstehe nicht, wie der Debugger den Objektcode der Quelle zuordnet (delayhlp.cpp). Ich konnte keine passende .pdb-Datei finden, die mit Visual Studio ausgeliefert wird. Weißt du zufällig, wie (und warum) das funktioniert? – IInspectable

+1

@Ilnspectable Delayhlp.cpp ist kompiliert mit (Zitat aus der Quelldatei) 'Build Anweisungen: cl -c -O1 -Z7 -Zl -W3 delayhlp.cpp'. Das '/ Z7' bedeutet, dass die Debug-Informationen in der Objektdatei enthalten sind und wiederum in die delayimp.lib, in die das Programm eingebunden ist. Von [Debug Information Format] (https://msdn.microsoft.com/de-de /library/958x11bc.aspx): 'Um eine Bibliothek zu erstellen, die Debugging-Informationen enthält, ohne PDB-Dateien zu verwenden, müssen Sie die C 7.0-kompatible (/ Z7) Option des Compilers auswählen. – dxiv

+1

@dxiv: Perfekt! Da es mit dem Compiler von Microsoft allgegenwärtig ist, Debug-Informationen und Objektcode zu trennen, fiel mir nicht einmal ein, dass Sie Debug-Informationen in das endgültige ausführbare Modul einbetten könnten. Dies ist für die delayimp.lib eine großartige Anwendung, die das Debuggen von verzögerten Ladevorgängen ermöglicht. Manchmal bin ich beeindruckt von der Liebe zum Detail, die all die anderen Zeiten wieder gut macht, wenn ich nicht ... – IInspectable

Verwandte Themen