VistualStudio 2010: wegen einer DLL keine Exception im Debug-Modus

Visual Studio 2010 (C#)
Windows 7 (64x)

Hallo,

ich habe in meinem Projekt mehrere DLLs eingebunden. Problem ist jetzt, wenn ich mich im Debug-Modus befinde und es kommt zu einem Exception-Fehler, springt der Debbuger in eine bestimmte Bibliothek in die Funktion CoreHookProc(...), anstatt mir den Fehler auszuspucken.

Wenn ich die Anwendung aus dem Studio raus starte und es kommt zu dem Fehler, dann erhalte ich ebenfalls keinen Exception sondern der macht einfach nicht mehr weiter. Die Anwendung stürzt aber nicht ab.

Starte ich die Anwendung direkt (ohne Studio) kriege ich ganz normal die Exception-Fehler.
Es ist also für mich irgendwie sehr schwierig auf Fehler zu stoßen, wenn ich nur aus dem Studio raus starte.

Meine Frage, kann ich bei dieser einen Bibliothek irgendwie einstellen, dass ich mit dem Debugger dort nicht mehr rein springen kann oder gibt es eine andere Möglichkeit? Raus nehmen kann ich die nicht.
Ich habe die Referenz nicht mehr als Projekt drin, sondern die DLL direkt. Das Projekt ist in der Solution deaktiviert. Leider klappt das nicht, der springt immer noch in die Funktion rein.
Was kann ich sonst noch tun?

Danke schon mal!

Gruß

Lukas

Hast du Zugriff auf die Quellen der betroffenen Bibliothek?

Guck mal, ob irgendwo *.pdb-Dateien der Bibliothek liegen, und lösche diese ggf.

Hallo dN!3L,

ja, ich habe die komplette Bibliothek als Projekt.
Habe alle pdb-Dateien gelöscht, trotzdem springt der in die Funktion rein. Klappt also immer noch nicht.

Lukas

ja, ich habe die komplette Bibliothek als Projekt.

Dann guck dir mal das DebuggerStepThrough-Attribut bzw. DebuggerHidden-Attribut an.

Danke für den Tipp, gut zu wissen, dass es so was gibt.
Leider springt der in den Disassembly rein, kriege also immer noch keine Exception. Hat also den selben Effekt, als wenn ich die Quellcode-Datei mit den Events umbenennen würde.

Lukas

Hallo lukasS,

wenn ein Fehler nur außerhalb von VS bzw. dem Debugger auftritt und sonst nicht, sollte man es mit Logging versuchen.

herbivore

Hallo herbivore,

was meinst mit logging?
Ich verstehe auch nicht, warum ich keine Meldung wie "Object reference not set to an instance of an object.", sondern der einfach dort abbricht und in einer anderen Bibliothek weiter macht.

Lukas

Leider springt der in den Disassembly rein, kriege also immer noch keine Exception.

Hm, hört sich nach einem disfigurierten VS an. Guck mal, was du bei Extras/Optionen/Debugger eingestellt hast. Punkte wie "Debugging auf Adressebene aktivieren" oder "Nur eigenen Code aktivieren" wären da interessant.

Hallo dN!3L,

beide sind aktiv, dort habe ich auch nichts seit der Installation geändert.
Hängt das vielleicht an den Bibl.-Funktionen? An dem DLL-Projekt selbst?

Wenn ich ein neues Projekt ohne diese DLL erzeuge, dann funktioniert ja alles. Also ich denke, dass das an der DLL irgendwie liegt, die permanent irgendwelche Messages über das Fensterverhalten meines Dialoges erhält.

Lukas

beide sind aktiv

Mach mal den Haken bei "Debugging auf Adressebene aktivieren" raus.

Also ich denke, dass das an der DLL irgendwie liegt, die permanent irgendwelche Messages über das Fensterverhalten meines Dialoges erhält.

Hm, ich bin mir nicht sicher, ob ich dieses Problem richtig verstanden habe. Kannst du da noch etwas mehr Details preisgeben? Insbesondere, was die Bibliothek so grob tut.

Wenn ich auf einen Fehler stoße erscheint bei mir ein Fenster mit der Überschrift "No Source Available". Im unteren Bereich steht user32.dll!76d...(). Sobald ich dann F5 drücke, läfut das Programm weiter.

Die DLL ist für die Fenstersteuerung alà Visual Studio zuständig, das heißt ich kann wie im Studio Panels im Hauptdialog andocken/verschieben etc. http://sourceforge.net/projects/dockpanelsuite/

Ich kenne mcih mit dem Bereich leider nicht so gut aus und kann nicht einschätzen welchen Einfluss eine DLL auf das Debuggen haben kann.

Hallo lukasS,
hast Du versucht die QuellCode-Datei der Bibliothek in VS mit anzuzeigen und dann zu debuggen?
Hast Du eine Try-Catch-Klammer über diese Bibliothek geöffnet?

Gruß, Karl

Hallo telfa,

hast Du versucht die QuellCode-Datei der Bibliothek in VS mit anzuzeigen und dann zu debuggen?

Den kompletten Quellcode habe ich ja und kann den debuggen

Hast Du eine Try-Catch-Klammer über diese Bibliothek geöffnet?

Um ehrlich zu sein, ich wüsste nicht wo ich dort die Klammer setzen müsste. Die DLL läuft ja korrekt, ich kann die einfachsten Fehler wie (siehe Bsp) machen und kriege keine Meldung.

MyClass1 c1 = null;
c1.Name = "test"; //Hier müsste ich einen Exception kriegen, dort der wandert in die DLL und dort kann cih weiter debuggen.

Gruß

Lukas

Hallo lukasS,

MyClass1 c1 = null;  
 c1.Name = "test"; //Hier müsste ich einen Exception kriegen, dort der wandert in die DLL und dort kann cih weiter debuggen.  

versuche einfach über einen Try-Catch-Block um diese Stelle zu setzen.
Optional noch einen Haltepunkt setzen. In dem Fall sollte der Debugger an dieser Stelle stehen bleiben.

Gruß, Karl

Morgen telfa,

im Debug-Modus springt der zwar in den catch, trotzdem läuft der danach in die DLL rein. Drücke ich dann F5 läuft das Programm mit Folgefehlern weiter (in meinem Bsp. ist der Dialog zum Teil ohne Steuerelemente, da ich diese nach dem Fehler per Laufzeit erzeuge). Das Try-Catch hilft zwar hier und dort einen Fehler ggf. schneller zu finden, aber die Lösung ist das nicht, da mein Projekt recht umfangreich ist.

Ich muss wohl weiter suchen.

Trotzdem danke!

Gruß

Lukas

Ok,
es liegt wirklich an der DLL. Dieses Problem habe ich nur in Dialogen, in einfachen CS-Dateien kriege ich die richtige Exception-Meldung.

Ich müsste wohl beim Entwickler der Library nach fragen.

Danke allen!

Lukas