VisualStudio 6 und Vista
-
OK, ich werde mal mein Glück versuchen, einen Fehler zu finden.
-
Wenn ich nun Debuginformationen in der Release-Version einstelle, bekomme ich wieder keine Fehler. Ich habe es dann soweit einschränken können, dass nur noch bei der Laufzeit-Bibliothek die Debug Version von Multithreaded-DLL verwendet wird. Wenn das eingestellt ist bekomme ich keine Fehler. Werden die nicht Debug Laufzeit Bibliotheken benutzt kommt der Fehler.
Kann es Probleme geben oder Laufzeitverluste, wenn ich diese einfach Standardmäßig weiterbenutze?
-
Naja, das größte Problem dabei wird wohl sein, dass man glaube ich die Debug-Versionen der Laufzeit-Bibliothek lizenzrechtlich gar nicht mitliefern darf.
vllt. verrät ja "WinDbg" oder so noch was...
-
IngoF schrieb:
Wenn ich nun Debuginformationen in der Release-Version einstelle, bekomme ich wieder keine Fehler. Ich habe es dann soweit einschränken können, dass nur noch bei der Laufzeit-Bibliothek die Debug Version von Multithreaded-DLL verwendet wird. Wenn das eingestellt ist bekomme ich keine Fehler. Werden die nicht Debug Laufzeit Bibliotheken benutzt kommt der Fehler.
Kann es Probleme geben oder Laufzeitverluste, wenn ich diese einfach Standardmäßig weiterbenutze?Du hast es falsch verstanden! Du sollst nicht die Debug-DLLs verwenden, sondern Du sollst den Compiler umstellen, dass er Debug Infos erzeugt! Dito für den Linker.
Du fragst warum Dein Programm unter Vista abschmiert. Ganz einfach. Dein Fehler ist abhängig z.B. vom Inhalt des Stacks. Bestimmte Stackbereche sind unter Vista anders initailsierst als unter XP. Normalerweise haben Dich solche "fremden" Bereihe ja auch nicht zu interessieren. Du hast aber einen Bug in der Software!
Das hier die Ursache liegt zeigt alleine schon die Tatasche, dass Dein Debug Build läuft. Hier werden nämöich alle Stackbereiche der Funktion und auch alle Heap-Bereiche mit einem "no-Land"-Marker initialisiert.100% Dein Code ist Buggy!
Erzeuge Debug Infos (nicht die Debug-Crt/Dlls verwenden!) Dann schau Dir an, wo die Applikation abschmiert!
-
Sobald ich Debug-Infos generiere schmiert das Programm nicht mehr ab, dass ist ja mein Problem.
-
Das würde mich sehr wundern. Du sollst in deinem Release-Build Debug-Infos mit reinkompilieren. D.h. vor allem, dass der define _DEBUG nicht gesetzt werden sein darf!
-
dEUs schrieb:
CodeFinder schrieb:
IngoF schrieb:
Ist nun meine VisualStudio Version einfach zu alt für Vista [...] ?
Also eigentlich ist es schon zu alt für Xp
. Ladt Dir doch einfach die VC 2005 Express Edition (kostenlos) herunter. Bringt doch nix auf diesem alten Mist aufzubauen.Keine Alternative für den OP. Er verwendet die MFC.
Naja... dann könnte er es mit der WTL versuchen
http://www.codeproject.com/wtl/WTLExpress.asp
-
Ich werde es jetzt mal mit dem VisualStudio 2005 versuchen.
-
Achja noch was: Hast Du für VC++ 6.0 das Service Pack 5 und 6 installiert ? Ich hatte mit dem Ding auch schonmal ziemlich unerklärliche Probleme...nach den Updates waren die verschwunden
. Würde aber trotzdem von dem Compiler Abschied nehmen 
.
-
Ich bin nun mit den Debug-Infos durch das Programm bis zu der Stelle gegangen, an der der Fehler auftaucht. Das einzige was mir aufgefallen ist: Bei der Debug-Version haben die Thread-Objekte immer unterschiedliche Heandels (CWinThread.m_hThread). In der Release Verison hat der erste Thread-Objekt vor dem Aufruf von CreateThread den Wert 0 und nachher einen Wert größer Null. Den selben Wert hat das Objekt vor dem zweiten Aufruf. Der erste Thread ist dann schon beendet. Ich weiß nicht, ob das so in Ornung ist, aber das ist bisher das einzige, was mir aufgefallen ist.
dEUs schrieb:
Das würde mich sehr wundern. Du sollst in deinem Release-Build Debug-Infos mit reinkompilieren. D.h. vor allem, dass der define _DEBUG nicht gesetzt werden sein darf!
-
Also der häufigste Fehler in Bezug auf CWinThread Objekte ist, dass AfxBeginThread aufgerufen wird und der Zeiger danach benutzt wird, ohne das m_bAutoDelete auf FALSE gesetzt wird.
Zeig mal wie Du den Thread startest und wie Du prüfst, dass der Thread zu Ende geht!
