PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [VS2008] Keine lesbaren Debug-Fehler


Kennung Eins
2008-11-05, 14:28:19
Hallo, ich habe mich vor einigen Monaten von VS.NET 2003 auf 2008 gesteigert, und seit dem ersten Tag VS 2008 habe ich folgendes Problem:

Wenn ich im Debug bin (d.h. "F5" drücken in der IDE) und ein Fehler im Code steckt, müsste er eigentlich das Programm unterbrechen und mich zu der Stelle im Code führen, an der der Fehler auftritt.

Doch ich kriege (egal bei welchem Fehler) nur ähnliches wie:
http://img379.imageshack.us/img379/8136/fehlergr0.jpg (http://imageshack.us)
http://img379.imageshack.us/img379/fehlergr0.jpg/1/w654.png (http://g.imageshack.us/img379/fehlergr0.jpg/1/)
(nur die Nummer hinten "an der Stelle .." ändert sich)

Woran könnte das liegen?

Ich benutze ein ActiveX-Element in meiner Form, mit einigen Datasets etc - doch diese Art Fehlermeldung kriege ich bei allen Arten von Fehlern (Array Index out of bounds, nicht vorhandenenes Dataset-Element, zugriff auf nicht initialisiertes Element, etc ...). Also egal welcher Fehler es ist, ich kriege immer nur eine Fehlermeldung wie oben.

Hat jemand eine Idee?

[edit]
0xE0434F4D ist CLR, ich weiß.

Trap
2008-11-05, 15:16:23
Ist der Crash wirklich in dem Prozess der im Debugger läuft?

Kennung Eins
2008-11-05, 15:21:40
Er ist in nem anderen Thread aber im gleichen Prozess (sorry)


bzw... sollte er sein .. ich vergleiche mal PIDs

[edit]
hm ..
http://img293.imageshack.us/img293/851/fehler2wc4.jpg (http://imageshack.us)
http://img293.imageshack.us/img293/fehler2wc4.jpg/1/w361.png (http://g.imageshack.us/img293/fehler2wc4.jpg/1/)
War es das was du meinst? Sind auf jeden Fall andere Nummern...

Gnafoo
2008-11-05, 15:45:57
Blöde Frage, aber bist du sicher, dass du nicht im Release-Mode bist? F5 heißt nicht unbedingt Debug-Mode, sondern nur, dass VS den Debugger mit starten soll. Das geht auch im Release-Mode (und kostet da ganz gut Performance). Siehe Build -> Configuration-Manager bzw. die Toolbar.

Kennung Eins
2008-11-05, 15:51:03
Ja genau das habe ich auch gedacht am Anfang - es steht aber definitiv auf "Debug (Any CPU)" :(
Auch die anderen Unterprojekte sind auf Debug, hab grad nochmal geprüft.

Es verhält sich wirklich so, als ob es im Release wäre.

Gnafoo
2008-11-05, 16:00:10
Hm du könntest einmal versuchen die Anwendung extern zu starten und den Debugger dann nachträglich per "Debug -> Attach to Process" an den laufenden Prozess anzuhängen. Wäre interessant zu wissen, ob das geht. Auf der anderen Seite weiß ich auch nicht so recht, wie dir das wirklich weiterhelfen soll :D.

Kennung Eins
2008-11-05, 16:06:39
Hm du könntest einmal versuchen die Anwendung extern zu starten und den Debugger dann nachträglich per "Debug -> Attach to Process" an den laufenden Prozess anzuhängen. Wäre interessant zu wissen, ob das geht. Auf der anderen Seite weiß ich auch nicht so recht, wie dir das wirklich weiterhelfen soll :D.
Hehe lol .. bevor ich das mache, kann mir jemand bitte mal seine Einstellungen unter Extras -> Optionen -> Debugging -> Allgemein schicken bitte? (Screenshot reicht bestimmt)

Das VS2008 wurde per Remote vom Firmenadmin installiert, evtl waren da Dinge voreingestellt, die jetzt hier behindern. Wobei ich das bezweifle. Oder ich hab direkt nach der Installation an den Einstellungen gespielt nach dem Motto "cool ne neue Funktion" - ich erinnere mich nicht :(

[edit]
Oder hat das evtl was damit zu tun, was im Windows als Standard-Debugger eingestellt ist?

[edit2]
"An den abstürzenden Prozess kann nicht angehängt werden. Es wurde bereits ein Debugger angefügt"
:(

Gnafoo
2008-11-05, 16:37:40
Ist zwar auf Englisch, aber bitteschön:

http://img511.imageshack.us/img511/2937/gnarftn7.th.png (http://img511.imageshack.us/my.php?image=gnarftn7.png)http://img511.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Allerdings bin ich mir nicht sicher, ob ich da nicht selbst schon was verdreht habe (Enable Just My Code z. B.). Aber im Prinzip tut hier alles, von daher wird es halbwegs stimmen.


"An den abstürzenden Prozess kann nicht angehängt werden. Es wurde bereits ein Debugger angefügt"


Das passiert, wenn du das Programm extern (außerhalb von VS) startest und dich dann mit dem Debugger dranhängen willst (bevor es abstürzt)? Wäre komisch, wenn unter den Umständen schon ein Debugger dranhängen würde?!

Kennung Eins
2008-11-05, 16:52:02
Vielen Dank - ich hatte zwar einiges anders aber geändert hat es leider nichts :(

Ich reinstalliere mal VS, wer weiß ...

Kennung Eins
2008-11-05, 17:36:11
Mist der Fehler ist immernoch da, trotz Reinstall.

Wie es scheint, hängt sich zwar der/ein Debugger an das zu debuggende Programm dran, jedoch verliert VS scheinbar die Verbindung zum Debugger!? So würd ich das jedenfalls interpretieren.

Ich hab echt keine Lust mehr, mich mit diesen blöden Fehlermeldungen rumzuschlagen. Man findet Fehler zwar auch so, aber das dauert einfach zu lange ..

Kennung Eins
2008-11-06, 08:31:53
Moin, ich bin mir nicht sicher, ob das die Lösung ist - aber ich habe etwas gefunden:
http://stackoverflow.com/questions/103034/vs2008-debugger-does-not-break-on-unhandled-exception

Die mögliche Lösung: CTRL-D + CTRL-E, und jetzt in dem Menü waren bei mir nirgends Häkchen gesetzt. Ich habe mal alle angeklickt und siehe da, jetzt kriege ich lesbare Fehler!

http://img386.imageshack.us/img386/5896/fehler3wf4.jpg (http://imageshack.us)
http://img386.imageshack.us/img386/fehler3wf4.jpg/1/w700.png (http://g.imageshack.us/img386/fehler3wf4.jpg/1/)

Dennoch danke für den Hilfeversuch :)

Gnafoo
2008-11-06, 15:09:29
Das fängt aber afaik alle Exceptions in dem Moment, in dem sie auftreten und nicht nur solche ohne Exception-Handler. Ist also nicht ganz das selbe.

Siehe auch:
http://msdn.microsoft.com/en-us/library/x85tt0dd(VS.80).aspx

"If a non-ASP.NET exception occurs and is not handled, the debugger always breaks execution."
Das sollte eigentlich passieren.

"You can tell the debugger to break execution immediately when an exception is thrown, before any handler is invoked."
Das hast du jetzt aktiviert.

Gnafoo
2008-11-06, 15:24:53
Okay man kann dort auch "User-unhandled"-Exceptions ankreuzen, wenn man "Just My Code" aktiviert hat (ich glaube das habe ich verstellt bei meinem Screenshot oben). Das kommt der Sache am nächsten.

Aber so ganz verstehe ich das Ganze trotzdem nicht. Die Aussage der Dokumentation ("If a non-ASP.NET exception occurs and is not handled, the debugger always breaks execution.") ist ja eigentlich recht eindeutig. Oder wird dein Code von VS-generiertem Code einer anderen .NET Anwendung oder so etwas aufgerufen, der die Exception womöglich fängt?

Kennung Eins
2008-11-06, 16:08:28
Danke für den Hinweis - jetzt verstehe ich, wieso der auch bei try-catch stoppt ..

Hmm.. ich bin mir total unklar, wo die Ursache für das Problem liegt. Ich benutze ja ein eingebettetes ActiveX-Objekt, vielleicht passiert da beim Debuggen im Hintergrund irgendwas komisches. Aber auch in anderen Anwendungen ohne dieses eingebettete Objekt war das so .. habe leider keine Zeit zum Testen, das Programm muss weiterkommen - so geht es zumindest erstmal.

Gnafoo
2008-11-06, 16:25:14
Was mir noch zu dem Thema einfällt: Wenn du ein 64-Bit-Betriebssystem hast kannst du einmal versuchen in den Projektoptionen die Zielplattform von "Any CPU" auf "x86" zu stellen. Zumindest mit VS2005 hatte ich da mal Probleme mit dem Debugger.

Das ist allerdings nur so etwas was mir da noch im Hinterkopf rumschwirrt und wofür ich auch absolut keine Begründung habe :D. Im Zweifelsfall kann es aber nicht schaden, es auszuprobieren.

Kennung Eins
2008-11-06, 17:02:04
Ok .. probiere ich aus!

Wenn ich auf "x86" umstelle nehmen die Methoden des ActiveX-Plugins witzigerweise andere Parameter, als bei "Any CPU" und ich denke nicht, dass das geplant war (die Methoden funktionieren dann nicht mehr) ..

Nun gut :)

Gast
2008-11-06, 22:40:33
Wenn du eine unmanaged 32Bit dll hast, dann musst du den .NET Teil ebenfalls auf 32Bit umstellen. Dann darfst du nicht Any CPU nehmen. Oder du machst eben alles für x64.

Kennung Eins
2008-11-06, 22:43:42
Hm warum ging das mit VS.NET 2003?

Gast
2008-11-06, 22:54:11
Hm warum ging das mit VS.NET 2003?

Da gab's doch gar kein .NET 64Bit. Das Problem ist, dass bei Any CPU standardmäßig die 64Bit Runtime geladen wird, wenn ein 64Bit Windows/Runtime vorhanden ist. Wenn dann dort die 32Bit unmanaged DLL geladen wird, gibt's Probleme.