Debuggen einer DLL

[ngott2]

Hallo,
ich habe angefangen meine erste DLL zu Programmieren klappt so weit auch ganz gut. Nun wollte ich gestern was Debuggen und musste leider feststellen das die Haltepunkte nicht gesetzt werden.

Ich habe ein Host Projekt ausgewählt. Das Abgabeverzeichnis der DLL entspricht den Pfad meiner Host Anwendung. Selbst wenn ich meine DLL Compiliere geht er wenn in der DLL eine unabgefange Exception auftritt in die Hostanwendung rein.

Die beiden Projekte sind in einer Projektgruppe.

Hat jemand eine Idee woran es liegen kann das ich in der DLL nicht Debuggen kann ?
Die Sachen die ich im Internet gefunden habe funktionieren leider nicht.

Nutze Delphi XE6.

Vielen Dank im Voraus.

[Union]

Hast Du den richtigen Eintrag in der Projektgruppe aktiviert?

[ngott2]

Wie meinst du das ? Was ist der richtige Eintrag ?

[Perlsau]

In Dll-Projekten zu debuggen gestaltet sich nicht einfach. Auch bei mir werden Haltepunkte in Dll-Projekten nicht angesprungen, und das völlig unabhängig davon, ob ich im Debug- oder Release-Modus starte. Ich behelfe mir mit Debugbreakpoints, indem ich den Befehl

Delphi-Quellcode:

ASM INT 3 End;

an die Stelle setze, die ich normalerweise mit einem Haltepunkt versehen würde.

Weitere Links zum Thema:

Embarcadero-Debugger
StackOverflow
DLL debuggen - nur noch CPU-Haltepunkte?
Debugger-Meldung "ntdll.DbgBreakPoint" verhindern
Tipps&Tricks zum Debuggen einer DLL
How to debug a DLL called from a DLL in Delphi
Breakpoint not honored while debugging a DLL
Google

[jaenicke]

Eigentlich gibt es da gar keine Probleme. Wichtig ist nur eine Sache:
Debuginformationen und externe Debuginformationen müssen in den Projektoptionen aktiviert sein. Am besten für Hostanwendung und DLL gleichermaßen.

Dann sollte es problemlos möglich sein in den Quelltexten beider Projekte normal Haltepunkte zu verwenden und von der Hostanwendung in die DLL und umgekehrt zu debuggen.
(EDIT: Übrigens auch, wenn man die Hostanwendung startet und das DLL Projekt einfach nur in der Projektgruppe liegt, man muss nicht unbedingt das DLL Projekt mit Hostanwendung starten.)

EDIT2:
@Perlsau: Ich sehe schon, das steht in einem deiner Links auch. Deine Assemblerlösung ließ mich das nicht vermuten.

[Sir Rufo]

Irgendwie mache ich das dann komisch, denn bislang hatte ich keinerlei Probleme damit eine DLL zu debuggen.

• DLL-Projekt und ein Projekt was die DLL verwendet in eine Projektgruppe
• Abhängigkeiten des Projekts definiert (benötigt das DLL-Projekt)
• Ausgabepfade angepasst (die erzeugten EXE/DLL Dateien im gleichen Verzeichnis)
• Beide Projekte auf Debug
• Einen Haltepunkt im DLL-Projekt setzen
• Das normale Projekt starten und schwupps wird an dem Haltepunkt in der DLL brav angehalten

[himitsu]

Zitat:

Zitat von Perlsau (Beitrag 1270084)

In Dll-Projekten zu debuggen gestaltet sich nicht einfach. Auch ...

Dem kann ich eigentlic nicht zustimmen.

Egal ob DLL und EXE als Host gedebuggt wird,
die EXE, in welcher die DLL "zufällig" geladen wird
oder eine andere DLL, mit einem Host der die eigentliche DLL läd,
es lässt sich alles meistens problemlos Debuggen.

Auch ob die DLL statisch, delayed oder dynamisch geladen wird, macht keinen Unterschied.
Sobald der Debugger die Debuginfos der geladenen Module (EXE, DLL, BPL und selbst wenn die DLL nicht DLL heißt) findet, versteht und läd, ist oftmals alles OK.
Ob er die Debuginfos fand, kann man

Es gibt nur Probleme, wenn der Debugger die Debuginfos nicht findet, womit er dann die Positionen der Zeilen nicht kennt.
Genauso ist es blöd, wenn veraltete Debuginfos geladen werden, da dann die Zeilen mit den Codeadressen nicht mehr übereinstimmen.
Oder beim Compilieren von Projekten/Projektgruppen mit unterschiedlichen Ausgabe- und Suchpfaden.
Oder beim externen Kompilieren (z.B. FinalBuilder) mit anderen Projekteinstellungen (z.B. reingehacktem Eurekalog) oder wenn das Skript nach dem Kompilieren "aufräumt". :wall:

Eventuell kann es auch besser sein das Programm erst zu starten und es dannach mit dem Debugger zu verbinden.

Zitat:

Zitat von Sir Rufo (Beitrag 1270091)

• Beide Projekte auf Debug

Besch* Einstellungen sollte man natürlich vermeiden.
* Release
* oder "exotische" Compilereinstellungen (nur weil der Punkt "Debug" heist, muß er noch lange nicht auf De)
* auch im Code kann der Compiler gesteuert wurden sein

[ngott2]

Wenn ich die DLL Debugge kann ich auch meine Host Anwendung Debuggen. Aber meine DLL ignoriert meine Versuche leider weiterhin. :x

[ngott2]

Zitat:

Zitat von Sir Rufo (Beitrag 1270091)

Irgendwie mache ich das dann komisch, denn bislang hatte ich keinerlei Probleme damit eine DLL zu debuggen.

• Abhängigkeiten des Projekts definiert (benötigt das DLL-Projekt)
  

Wie definiert man diese Abhängigkeit ?

[ngott2]

Funktioniert jetzt. War ein Problem mit dem Pfad der Hostanwendung und den Pfad der Ausgabe der Hostanwendung. :oops:

[Sir Rufo]

Zitat:

Zitat von ngott2 (Beitrag 1270098)

Zitat:

Zitat von Sir Rufo (Beitrag 1270091)

Irgendwie mache ich das dann komisch, denn bislang hatte ich keinerlei Probleme damit eine DLL zu debuggen.

• Abhängigkeiten des Projekts definiert (benötigt das DLL-Projekt)
  

Wie definiert man diese Abhängigkeit ?

Wenn du mehr als ein Projekt in deiner Projektgruppe hast, dann hast du über das Kontext-Menü des Projekts (rechte Maus auf das Projekt) den Menüpunkt "Abhängigkeiten..." und klickst dann ganz einfach die Projekte an, die vorher erstellt werden müssen.

http://docwiki.embarcadero.com/RADSt...jektverwaltung