Visual Studio- oder Computer kaputt?

B

baeman

Mitglied
Servus,

diesmal vielleicht eine etwas andere Frage.

Habe folgendes Problem:

Beim debuggen meines Programms ignoriert der Debugger(MS VisualStudio2003.NET) einige Zuweisungen

Bsp:

double dTime, dMins;
CString strTime;

dTime = 0; //Wird beidesmal ignoriert
dMin = 0;

dTime = atof(strTime); //funktioniert nicht
dMins = atof(strTime); //hier wuerde es dann wieder funktionieren

Dieser ganze Schwachsinn passiert auch nur manchmal.
Frage: Kann es eine Einstellung von Studio sein, oder doch eher an meinem Rechner.
Fuer irgendwelche Ratschlage und Tipps schon vornweg vielen Dank
 
A) prüf mal, ob in den Projekteinstellung noch DebugInfo generieren an ist.
B) prüf, ob Optimierungen im Debug ALLE ABGESCHALTET sind (wichtig)
B) prüf, ob auch Debug als Projekt-Variante ausgewählt ist
C) Mach ein schönes Rebuild All.

Das Überspringen macht er, wenn entweder die Debug-Info veraltet ist, oder Optimierungen an sind. Dann werden eine Codezeilen ja zusammengemanscht, und es gibt kein 1:1 Code zu Assembler mehr.


Nachtrag: Vielleicht ist doch dein Computer kaputt. Ich kauf ihn dir für 10 Euro ab. Na gut, 15. :)
 
... erstmal danke,


witzigerweisse bekomme ich jetzt ne unhandled exception allerdings erst beim aufruf von the app:

Unhandled exception at 0x7c901010 in lop_gui_v1.exe: 0xC0000005: Access violation reading location 0x20202050.

Projekt war auf Release gesetzt und nicht auf Debug.

Hab es gerade eben nochmals auf Release versucht, da bekomme ich keine unhandled exception, dafuer aber den sch... beim debuggen.
 
Release ist eben Release, da bekommst du das durch die Optimierungen.
Nimm nur Debug zum Debuggen, alles andere bringt nichts.
 
Okay war mir neu.

Gibt es ne Moeglichkeit rauszufinden wann genau die unhandled exception auftritt?
Da ich bis zu theApp debuggen kann, und der Fehler erst beim weiterlaufen kommt.

thanx
 
Genau dann, wenn die Exception auftritt, bekommst du doch einen lustigen Dialog, von wegen Retry, Cancel und Ignore. Dann einfach auf Retry gehen, dann sollte der Cursor an die Code-Stelle springen, die die Exception geworfen hat (Du startest das Ganze doch über die IDE?)
 
Ja verwende schon die IDE, wobei ich kein retry zum angebot habe, nur break und continue.
Und bei continue zeigt er mir nur das gleiche Fenster nochmal, aber springt nicht an die stelle.

Und kann leider nur bis theApp debuggen, ab da findet er den Source nimmer, also geht es nur noch mit dem continue butten in der Debugnavitation
 
Aber selbst wenn er den Source nicht findet, dann sollte er ja üblicherweise den ASM-Code anzeigen. Der nutzt zwar in den meisten Fällen nichts, aber du kannst im Call-Stack nachsehen, welche Routine bzw. welcher Aufruf von dir letztendlich zu dem Fehler geführt hat. Einfach im Call-Stack die nächste Routine suchen, von der er den Code anzeigen kann, drauf doppelklicken und du bist praktisch bei der Quelle.
Mal vorausgesetzt, dass der Fehler ein direkter ist, und nicht ein verschleppter, der sich erst dort auswirkt.


Nachtrag: Wenn du auf break gehts, müsstest du doch entweder den ASM-Code bekommen oder eine von deinen Dateien.
 
Also wenn ich auf break gehe, passiert gar nichts. Bekomme weder den ASM Code, noch eine meiner dateien.

Das mit dem Debuggen ist so ne Sache, um weiter als theApp zu kommen, musste ich automatic assembly... aktivieren. Und jetzt springt er dann in ne Datei namens :"Disassembly" und bleibt kommt nie wieder raus. Springt andauernt 5-6 Zeilen runter und dann wieder zurueck zu der ersten. Und beim Stack passiert nicht wirklich viel.
 
Hab es irgendwie doch geschafft das ich beim debuggen auf ne neue Zeile komme:

Wobei ich mit der nicht viel anfangen kann:
7C901010 cmp dword ptr [edx+14h],0

Ich denke 7C901010 ist Stelle im Speicher, aber der Rest?
Help!


 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück