4. Breakpoints bei einer DLL klappen nicht

Breakpoints bei einer DLL klappen nicht

  • S

    Ich baue n Plugin für ein Tool. Generiert wird eine DLL mittels VC++ 9.0
    Nun muss ich diese DLL jedoch auch debuggen können.

    Für diesen Zweck habe ich unter Debug Optionen das Programm ausgewählt, was diese DLL benutzt und als Parameter eine Datei zum testen.

    Soweit ok, beim Debug-Start wird das Programm aufgerufen und ich sehe die geladene Datei, jedoch werden keine der Breakpoints von VC++ angesprungen.

    Der Code wird jedoch definitv ausgeführt (getestet mit ner exception, die auch an der erwarteten Stelle erscheint).

    Woran könnte es liegen, dass VC++ die Breakpoints nicht anspringt?

    Ein Rebuild wurden natürlich gemacht

    0
  • Mod

    Hast Du die PDB Datei im selben Verzeichnis! Existiert eine passende PDB Datei aus dem Build. Dann kannst Du auch Breakpoints im Sourcecode setzen.
    Schau Dir das Debug-Fenster Modules an. Odrt kannst Du sehen ob Debug-Infos bekannt sind!

    0
  • S

    Die DLL wird da garnicht aufgeführt.
    Ich vermute, dass die erst bei der Benutzung von einem anderen Prozess geladen und entladen wird

    0
  • Mod

    Seikilos schrieb:

    Die DLL wird da garnicht aufgeführt.
    Ich vermute, dass die erst bei der Benutzung von einem anderen Prozess geladen und entladen wird

    Sicher ist eine DLL alleine nicht lauffähig. Du musst den Prozess debuggen, der die DLL verwendet. Daz kannst Du idealerweise Attach to Process verwenden!

    0
  • S

    Öh nö?
    Wenn ich bei Debug Command Parameter ausfülle, wird das jeweilige Programm automatisch gestartet und debuggt.
    Blöd ist nur, dass das Programm eigentlich einen Prozess erst bei der Nutzung der DLL startet, ergo nützt mir das debuggen vom Parent Prozess nichts 😕

    0
  • Mod

    Seikilos schrieb:

    Öh nö?
    Wenn ich bei Debug Command Parameter ausfülle, wird das jeweilige Programm automatisch gestartet und debuggt.
    Blöd ist nur, dass das Programm eigentlich einen Prozess erst bei der Nutzung der DLL startet, ergo nützt mir das debuggen vom Parent Prozess nichts 😕

    Was "Öh nö?"?

    Was menst Du mit "dass das Programm eigentlich einen Prozess erst bei der Nutzung der DLL startet"?

    Du kannst jederezit in Deinen Code einen DebugBreak einbauen. Dann kannst Du Dich live in den Code reinschalten. Du bekommst eine Meldung Deiner IDE mit der Möglichkeit sich an den Prozess anzuklinken.

    0
  • S

    VS attached sich auf Prozess X, das ist der, der das Programm ausführt. Die DLL ist hier nicht geladen, die wird erst geladen wenn, ich eine Funktion in dem Programm nutze, darauf hin wird ein Prozess Y gestartet, der diese DLL lädt, da es aber nicht mehr Prozess X ist, merkt das VS nicht, das hängt weiterhin brav an Prozess X

    0
  • Mod

    Du kannst selbst wenn Du Prozess X debuggst zusätzlich auch noch Prozess Y attachen!

    Wenn das nicht hilft dann setze DebugBreak in Deinen Code!

    0
  • S

    Der Prozess Y wird nur für ne sehr kurze Zeit gestartet, für eine Sekunde, dann wird das Plugin verarbeitet und Prozess Y beendet, so schnell kann ich den nicht attachen.

    Das mit DebugBreak werden ich probieren

    Edit: Hat keine Auswirkung, wenn die Symbole nicht geladen werden, macht es keinen Sinn, da fremder Prozess

    0
  • Mod

    Dann musst Du IMHO mit dem DebugBreak arbeiten, aber Achtung nicht dass dies in der Release-Version auch drin bleibt!

    Dem Debugger ist wurscht was für Symbole geladen werden können. Es ist nur ein Frage eben was Du sehen kannst und was nicht...

    0
  • S

    DebugBreak ist drin, Debug Buidl rebuilt und getestet, merke jedoch nichts von dem Break

    0
  • Mod

    Dann ist DebugBreak in keinem Fall drin, oder er wird wirklich nicht ausgeführt. Dieser INT 3 sorgt für einen Crash wenn kein Debugger geladen ist, und kein Debugger installiert ist. Ist ein Debugger vorhanden bekommst Du eine nette Frage...
    Bau doch eine MessageBox mal vor den DebugBreak.

    0
Anmelden zum Antworten