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


im Notfall kannst du selber dieser "Haltepunkte" einprogrammieren

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 von himitsu:

Hmmmmm


im Notfall kannst du selber dieser "Haltepunkte" einprogrammieren

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.