<![CDATA[Debug vs. Release]]>hi,

ich versuche in einem größeren Projekt einen Fehler zu finden. Der tritt leider nur im Release Build auf (wahrscheinlich Heap Corruption). Ich vermute mal dass der Debug Heap dafür sorgt, dass nicht initialisierte Speicherstellen mit Debug Codes (Z.B.: 0xCDCDCDCD)überschrieben sind und daher die Debugversion durchläuft.

Da ich mit Visual Studio arbeite, kann ich den Just-in-Time Debugger benutzen, um an die Stelle des Absturzes zu gelangen. Jetzt hab ich zwar eine Speicheraddresse, an der kann ich aber nur im ASM Code stöbern und über den Callstack komme ich auch nicht zurück bis zur entsprechenden Stelle in meinem Programm (zumindest steht dort auch nur assembler code).
In solchen Fällen soll GFlags.exe (MS Debugging Tools) helfen. Sobald ich damit aber page-heap aktiviere, läuft die Anwendung wieder bzw. mein vorheriger Fehler lässt sich dann nicht mehr wiederholen(?).

Die Meldung im VS Debugger:

Critical Section detected c0000374
Windows hat einen Haltepunkt in xy.exe ausgelöst.

Dies kann auf eine Beschädigung des Heaps zurückzuführen sein, die auf ein Problem in xy.exe oder in einer der geladenen DLLs hinweist.

Dies kann auch darauf zurückzuführen sein, dass der Benutzer F12 drückt, während xy.exe den Fokus hat.
...

Gibts da irgendein Verfahren, wie ich dennoch (ohne allen Code durchzuarbeiten) an die Methode/Function ran komme, in der es hakt? ^^
Bin für alle Tips dankbar!

]]>https://www.c-plusplus.net/forum/topic/278870/debug-vs-releaseRSS for NodeMon, 24 Aug 2026 20:23:58 GMTTue, 14 Dec 2010 14:30:10 GMT60<![CDATA[Reply to Debug vs. Release on Tue, 14 Dec 2010 14:30:10 GMT]]>hi,

ich versuche in einem größeren Projekt einen Fehler zu finden. Der tritt leider nur im Release Build auf (wahrscheinlich Heap Corruption). Ich vermute mal dass der Debug Heap dafür sorgt, dass nicht initialisierte Speicherstellen mit Debug Codes (Z.B.: 0xCDCDCDCD)überschrieben sind und daher die Debugversion durchläuft.

Da ich mit Visual Studio arbeite, kann ich den Just-in-Time Debugger benutzen, um an die Stelle des Absturzes zu gelangen. Jetzt hab ich zwar eine Speicheraddresse, an der kann ich aber nur im ASM Code stöbern und über den Callstack komme ich auch nicht zurück bis zur entsprechenden Stelle in meinem Programm (zumindest steht dort auch nur assembler code).
In solchen Fällen soll GFlags.exe (MS Debugging Tools) helfen. Sobald ich damit aber page-heap aktiviere, läuft die Anwendung wieder bzw. mein vorheriger Fehler lässt sich dann nicht mehr wiederholen(?).

Die Meldung im VS Debugger:

Critical Section detected c0000374
Windows hat einen Haltepunkt in xy.exe ausgelöst.

Dies kann auf eine Beschädigung des Heaps zurückzuführen sein, die auf ein Problem in xy.exe oder in einer der geladenen DLLs hinweist.

Dies kann auch darauf zurückzuführen sein, dass der Benutzer F12 drückt, während xy.exe den Fokus hat.
...

Gibts da irgendein Verfahren, wie ich dennoch (ohne allen Code durchzuarbeiten) an die Methode/Function ran komme, in der es hakt? ^^
Bin für alle Tips dankbar!

]]>https://www.c-plusplus.net/forum/post/1994435https://www.c-plusplus.net/forum/post/1994435Tue, 14 Dec 2010 14:30:10 GMT<![CDATA[Reply to Debug vs. Release on Tue, 14 Dec 2010 14:39:57 GMT]]>Vielleicht hilft das hier weiter:

http://blog.m-ri.de/index.php/2008/10/27/vs-tipps-tricks-heap-bugs-finden-teil-1/
(ist insgesamt dreiteilig)

]]>https://www.c-plusplus.net/forum/post/1994444https://www.c-plusplus.net/forum/post/1994444Tue, 14 Dec 2010 14:39:57 GMT<![CDATA[Reply to Debug vs. Release on Tue, 14 Dec 2010 15:34:10 GMT]]>danke für den Tip! Werde mir das gleich mal ansehen.
Ein Problem hab ich schonmal selbst gelöst:
In den Linker Optionen kann auch beim Release Build "Debuginfo generieren" auf "Ja(/DEBUG)" gestellt werden. Damit sieht man statt dem Assembler Code wieder die entsprechenden C/C++ Zeilen.

Ich dachte nur dass sich der Release Build wieder wie die Debug Variante verhalten würde und dadurch keinen Heapfehler verursacht. Das hatte aber keinen Einfluss darauf..

]]>https://www.c-plusplus.net/forum/post/1994480https://www.c-plusplus.net/forum/post/1994480Tue, 14 Dec 2010 15:34:10 GMT<![CDATA[Reply to Debug vs. Release on Fri, 17 Dec 2010 14:53:53 GMT]]>also nochmals vielen Dank an _matze! Habe jetzt den Fehler, mit Hilfe der Debug-CRT wie in seinem Blog beschrieben, lösen können.
In meinem Fall (MFC Anwendung) hab ich einfach folgendes an den Anfang der InitInstance() Methode der Hauptanwendungsklasse geschrieben:

#ifdef _DEBUG
afxMemDF |= checkAlwaysMemDF;
#endif

Beim nächsten Debug kam ich zum nächsten "new" nach Auftreten der Heapbeschädigung. Also musste ich noch etwas suchen. Dazu einfach die Zeile mit dem "new" um ein paar Zeilen nach oben kopieren und neu debuggen. Letztendlich wars bei mir eine Schleife, die einen Zeiger auf einen Speicherbereich (im Heap) einmal zu oft inkrementiert :p

]]>https://www.c-plusplus.net/forum/post/1995882https://www.c-plusplus.net/forum/post/1995882Fri, 17 Dec 2010 14:53:53 GMT<![CDATA[Reply to Debug vs. Release on Fri, 17 Dec 2010 16:01:19 GMT]]>Schön, dass du den Fehler gefunden hast. 👍

]]>https://www.c-plusplus.net/forum/post/1995921https://www.c-plusplus.net/forum/post/1995921Fri, 17 Dec 2010 16:01:19 GMT