DLL debuggen - nur noch CPU-Haltepunkte?

[MarioM.]

Hallo zusammen,

ich möchte eine DLL debuggen, und habe dazu die Anwendung, die die DLL benutzt als Host-Anwendung eingetragen und (gültige!) Haltepunkte an diversen markanten Stellen in meiner DLL gesetzt. Die Host-Anwendung startet auch, allerdings bleibt der Debugger nicht an den von mir definierten Haltepunkten stehen. Stattdessen öffnet sich das CPU-Fenster und zeigt dort irgendeinen Haltepunkt an, mit dessen Daten ich nichts anfangen kann.

Ein Haltepunkt ist in der initialen Methode gesetzt; zumindest der müsste auf jeden Fall angesprungen werden.
Ich weiß auch, dass die DLL durchlaufen wird, da ich am Ende Logausgaben mache, die dann auch tatsächlich vorhanden sind.

Das Ganze hat bisher immer super funktioniert. Heute habe ich allerdings ziemlich große Änderungen am Quelltext vorgenommen, allerdings keine, wo ich jetzt einen direkten Zusammenhang sehe.

Im Projekt ist der Schalter 'Debug-Informationen', und in den Delphi-Optionen 'Integriertes Debuggen' aktiviert.

Ich habe auch schon ein komplettes Build der DLL gemacht, neu gestartet usw. aber nichts hilft.

Andere Projekte (auch DLLs) Lassen sich übrigens problemlos debuggen.

Hat jemand eine Idee?

Edit: habe gerade mal alle heute gemachten Änderungen rückgängig gemacht und auch uralte Versionsstände des Projektes getestet; es funktioniert aber noch immer nicht. Es kann also nicht an den heutigen Änderungen liegen.

Edit2: Habe mal einen Screenshot beigefügt - da bleibts stehen.

[himitsu]

Mach dort mal ein F7 und schau dann wohin zurückgesprungen wird.

INT 3 = Interupt 3 aka hardcodierter Debugbreakpoint
RET = Rücksprung am z.B. Ende einer Funktion


Wie wird die DLL geladen?
statisch oder dynamisch

[MarioM.]

Der wühlt irgendwie die ganze Zeit in der ntdll.dll rum. Das hat er wie gesagt vorher nie gemacht.
Die DLL wird dynamisch geladen.

Ich weiß echt nicht mehr weiter :(

[Die Muhkuh]

http://www.delphipraxis.net/internal...ighlight=patch

[MarioM.]

Hallo,

das ist mir bekannt. Das Problem ist aber nicht, dass er in der ntdll.dlll hängen bleibt, wenn er trotzdem meine Haltepunkte auch berücksichtigen würde :(

Hat niemand mehr eine Idee?

[himitsu]

Hmmmmm :gruebel:


im Notfall kannst du selber dieser "Haltepunkte" einprogrammieren

Delphi-Quellcode:

ASM INT 3 End;

an der gewünschten Stelle einfügen und neu kompilieren


Schau mal was passiert, wenn du diesen "irgendwo" einfügst.
Wenn er dort hält und es ebenfalls im CPU-Fenster passiert, dann ins Code-Fenster wechseln und dort ein F7 probieren.

Werden eigentlich diese blauen Pünktchen im Code-Fenster angezeigt, oder sind diese ausgegraut?

[MarioM.]

Danke für den Tipp. Ich werde mal schauen, wie ich weiterkomme. Ist schon sehr mysterös...

Edit: die blauen Punkte werden angezeigt.

[MarioM.]

Zitat:

Zitat von himitsu

Hmmmmm :gruebel:


im Notfall kannst du selber dieser "Haltepunkte" einprogrammieren

Delphi-Quellcode:

ASM INT 3 End;

an der gewünschten Stelle einfügen und neu kompilieren


Schau mal was passiert, wenn du diesen "irgendwo" einfügst.
Wenn er dort hält und es ebenfalls im CPU-Fenster passiert, dann ins Code-Fenster wechseln und dort ein F7 probieren.
?

Eine Neuinstallation von Delphi hat nun leider auch nichts gebracht :(

Ich habe das mit dem fest einprogrammierten Haltepunkt mal versucht, und der Debugger hält auch an; allerdings passiert auch das, wie Du schon vermutet hast, im CPU-Fenster. Ein Wechsel ins Code-Fenster und Drücken von F7 bewirkt lediglich, dass wieder ins CPU-Fenster gesprungen und dort ein Schritt weiter gegangen wird.

Ich bin echt am Ende, da soviel Arbeitszeit mit diesem Mist draufgeht :(

[christophspaeth]

Hallo,

ich hatte auch gerade dieses Verhalten beim debuggen einer dll (in meinem Fall eine COM-dll, die von der MMC verwendet wird) in einem neuen branch (noch keine Änderung, also gleicher Code, gleiche Projektsettings wie im trunk). In trunk funktionierte das debuggen nach wie vor einwandfrei.
Der einzige Unterschied: in der Arbeitskopie vom branch waren Leerzeichen. Diese durch _ ersetzen und auch im branch funktioniert debuggen wieder so wie es soll. Wobei ich mir sicher bin, dass das Debuggen früher in anderen ddls funktioniert, die auch Leerzeichen im Pfad haben - jetzt zeigt sich dort selbens Verhalten. Kann aber gut sein, dass ich dort das letzte mal noch unter Windows XP debuggt habe, jetzt verwende ich Win 7.

Ach ja: Ich verwende Delphi 2006

Ich stelle also mal die kühne Behauptung auf: Windows 7 (+ Delphi 2006?) + Leerzeichen im Pfad -> Debugger hat Probleme bei DLLs. Kann das jemand bestätigen oder wiederlegen?

Grüße,
Chris

[MarioM.]

Hallo,

ich verwende Delphi 2007 unter Windows XP, und der Pfad, in dem sich die DLL befindet, sowie der Dateiname selber, enthalten natürlich keine Leerzeichen (sollte man die als Entwickler nicht generell meiden? ;)), sondern ausschliesslich Unterstriche.

Edit: ich habe eine simple Exe erstellt, die die DLL anstelle der eigentlichen Exe lädt, und damit funktioniert es. MUss also in meinem Fall irgendetwas mit dem ladenden Projekt zu tun haben.

[himitsu]

Was mal ein Versuch wert wäre:

Hast du mal geschaut, ob deine DLL auch an ihrer Wunsch-ImageBase liegt, oder ob sie verschoben wurde.
Eventuell kommt der Debugger damit nicht ganz klar. :gruebel:

http://www.delphipraxis.net/internal...109314#1109314

[christophspaeth]

Hallo Mario,

"Sollte man" eigentlich, ja - da geb ich dir Recht. Wenn die Projektstruktur aber schon Leerzeichen hatte als man es übernommen hat (weil natürlich die Produktnamen welche haben) ist das nicht immer möglich, das so ohne Weiteres zu ändern...
Ok, bei dem branch war ich ganz allein selber schuld, ist aber nur der Pfad meiner working copy betroffen.

Zu deinem Problem: Du bist auch sicher, dass er genau die DLL von genau der Stelle wo du hincompiliert hast anzieht?
Ich hatte zwar früher die Überzeugung, dass überhaupt nichts - also auch keine Breakpoints - im Debugger funktioniert, wenn der vollständige Pfad der geladenen dll anders war als der Ausgabepfad (also dll compilieren und dann von Hand ins Programmverzeichnis kopieren hat nicht funktioniert), aber dann hatte ich bei meinen Versuchen gestern den Effekt, dass er auch die CPU-Breakpoints angesprungen hat, wenn die dll aus einem anderen Pfad registriert war (hatte da aber noch die Leerzeichen im Pfad, kann also auch nur daran liegen).

Ist das Verhalten das selbe, wenn du dich manuell an den laufenden Prozess verbindest?

Ansonsten fällt mir auch nix mehr ein.

Gruß Chris