Eigene, kompilierte DLL debuggen?
-
Hallo zusammen,
ich verzeifel gerade an folgendem Szenario. Ich schreibe eine dll, nennen wir sie DLL_1, für eine Fremdanwendung, nennen wir sie EXE. Die Fremdanwendung lädt beim Starten diese dll. DLL_1 lädt ihrerseits wieder eine andere dll, welche auch von mir entwickelt worden ist. Sagen wir das ist DLL_2
Allerdings ist DLL_2 bereits im Release-Modus kompiliert. Trotzdem würde ich während ich DLL_1 entwickel gerne breakpoints in DLL_2 setzen können um die Kommunikation der beiden dlls besser debuggen zu können. Genau das kriege ich aber einfach nicht hin.
Bis jetzt habe ich die folgenden Sachen berücksichtigt:
- DLL_2 wurde mittels "Hinzufügen->Vorhandenes Project..." als Projekt zu der Solution von DLL_1 hinzugefügt
- Die Option "Nur meinen Code" ist deaktiviert
- Sowohl die gebuildete DLL_2 als auch deren .pdb Datei befinden sich im Projektordner von DLL_1
- Auch ein "Attach to process" an Anwendung EXE brachte keinen Erfolg
Was läuft hier falsch? Wenn ich einen Breakpoint in dem Source Code von DLL_2 setze (welchen ich ja habe, da es meine dll ist), wird dieser auch angezeigt (ausgefüllter roter Kreis) aber während dem Programmablauf einfach ignoriert.
Aber irgendwie muss das doch gehen, oder?
-
Du müsstest wenn dann auch den Code neu kompilieren, also die Source-Dateien deiner DLL_2 in dein Projekt einbinden und diese DLL immer neu kompilieren lassen. Du hast sonst ja auch nur Maschinencode, falls du aber den Maschinencode debuggen willst, musst du dafür halt irgend einen anderen Debugger nehmen, da dies Visual Studio nicht kann.
-
Ja, also ich hab das Projekt ja schon mittels "Hinzufügen->Vorhandenes Project..." zu meiner Solution hinzugefügt. In meiner Projektmappe befinden sich beide Projekte, das Projekt zu DLL_1 und das Projekt zu DLL_2, Quellcode inklusive.
-
Ich mache gerade zufällig das selbe, funktioniert bei mir aber ohne Probleme. Kannst ja mal versuchen den Fehler nachzustellen und das Projekt hochladen.
-
Schau bitte in das Debug Fenster Modules!
Dort steht woher eine Modul (DLL) geladen wurde du welche PDB Datei gefunden wurde.
-
Hallo,
Danke schonmal für die Antworten. Also die Module werden soweit ich das sehe richtige geladen. Also im Module Fenster steht dass sowohl die dll die sich nicht debuggen lässt als auch die exe welche zu debug-Testzwecken verwendet wird "an der Standard-Ladeaddresse geladen" wurden.
Mir ist allerdings beim rumprobieren noch etwas aufgefallen: Ich kann die besagte dll schon debuggen, allerdings nur ihren Einstiegspunkt (DllMain). Wenn ich dort einen breakpoint setze stoppt der Debugger auch.
In den weiteren Funktionen der dll geht das aber nicht mehr, in keiner davon. Ich habe folgende Funktionen in der dll:
- Zwei mit extern "C" __declspec(dllexport) deklarierte Funktionen
- Eine LRESULT CALLBACK WndProc welche zum Subclassen einer externen Anwendung verwendet wird
- Eine normale Funktion, die aber von einer der oberen Funktionen aufgerufen wird
Kann es vielleicht irgendwie damit zusammenhängen dass es nicht funktioniert? Also dass die Funktionen extern sind oder zum Subclassen verwendet werden?
-
Könntest ja mal einen Int 3 Breakpoint setzen, wenn das Programm dann nicht abbricht liegt es daran, dass dieser Punkt niemals erreicht wird:
__asm { Int 3; }
So bald der Prozessor den Opcode 0xCC (Int 3) erreicht, schmeißt der Prozessor eine Exception.
In Visual Studio kannst du sogar
__debugbreak();
schreiben.
-
Du meinst der Punkt wo ich meinen Breakpoint setze? Also der wird schon erreicht, das hab ich sichergestellt (MessageBox, cout, etc.). Daran kanns nicht liegen, sonst würde mein Programm auch gar nicht funktionieren weil das die betroffenen Funktionen dringend braucht...
-
Dann wird dieser Code auch nicht ausgeführt.
Geh mal bis zu der Stelle im Debugger in der die EXE den DLL Code ausführt. Dann schalte auf Assembler um und mach einen Step-Into.
In welchem Modul landest Du?
-
Martin Richter schrieb:
Dann wird dieser Code auch nicht ausgeführt.
Äh doch, also wie gesagt ausgeführt wird der Code definitiv. Wenn ich die dll mittels AllocConsole ein eigenes Konsolenfenster öffnen lasse kann ich von der Funktion aus mittles cout text ausgeben. Oder einfach mittels MessageBox.
Martin Richter schrieb:
Geh mal bis zu der Stelle im Debugger in der die EXE den DLL Code ausführt. Dann schalte auf Assembler um und mach einen Step-Into.
In welchem Modul landest Du?Also das geht nicht so einfach. Ich hab eine Debug-Exe, welche zu debugging Zwecken meine erste dll lädt (welche sich auch problemlos debuggen lässt). Diese dll lädt dann wiederum eine zweite dll und platziert in der externen Anwendung mittels SetWindowHookEx eine Hook.
Also unmittelbar von meinem Code selbst aufgerufen wird keine Funktion der zweiten dll, es wird lediglich eine
extern "C" __declspec(dllexport) LRESULT CALLBACK hook_proc(int msg, WPARAM wP, LPARAM lP)
Geladen und in der externen Anwendung mittles SetWindowHookEx eingesetzt. An den eigentlichen Aufruf komm ich also gar nicht ran, da der ja in der externen Anwendung liegt...
Durch diese hook_proc (und von ihr aufgerufene Unterfunktionen) will ich aber debuggen können.
-
Dann stimmt dennoch 100% etwas nicht mit dem Modul...
Dieses Modul ist NICHT geladen!
Schreib einen INT3 in Deinen Code und lass ihn in den Debugger rauschen.
-
Ok, hab ich gemacht (sowohl __debugbreak als auch Int3). Resultat war dass die externe Anwendung abstürzt mit der Windows-Fehlermeldung "Die Anwendung funktioniert nicht mehr".
Breakpoints werden trotzdem nicht erreicht
-
Debuggger natürlich attachen. Oder hinterher mit JustInTime attachen. Wieso stürzt das überhaupt ab. Normalerweise bekommet die Frage ob man debuggen möchte...
-
Hm, also wie genau soll ich das jetzt machen?
Wenn ich in meinem Projekt auf "Debuggen->An den Prozess anhängen..." gehe und dort den Zielprozess der externen Anwendung auswähle dann läuft der Debugger ja schon, ich kann dann eigentlich nur auf "Stop" drücken.
Ich kann zwar im Projektmappen-Explorer Rechtsklick auf mein Projekt und dann "Debuggen->Neue Instanz starten", aber gestoppt wird der Code trotzdem nicht an dem Breakpoint... Auch das Programm crasht weiterhin einfach.
Habe auch sichergestellt dass unter "Optionen->Debugging>Just-In-Time" alle Codetypen aktiviert sind. Trotzdem geht es immer noch nicht
-
Hi,
ich hab ein clr-Projekt übernommen, bei dem ich in den dlls zwischen nur verwaltet und automatisch bzw. gemischt umschalten muss, damit ich dort debuggen kann.
MfG