Releaseversion funktioniert bei statischem Verlinken der MFC nicht mehr

fabbishmain

Grünschnabel
Hallo,

ich habe bei meinem Programm folgendes Problem: Ich habe dort eine Druckvorschau bzw. Drucken eingebaut und im Debugmodus funktioniert das auch alles prima. In der Release geht der Rest des Programmes auch einwandfrei, aber immer wenn ich auf die Druckvorschau gehe, stürzt das Programm ab (sowohl in Visual Studio 2005 wie auch die exe direkt). Kompiliere ich aber das ganze ohne statisches verlinken der MFC-Klassen, also unter nutzung einer öffentlichen DLL, dann funktioniert das ganze.

Hat jemand eine Idee, woran das liegen könnte? Ich muss das leider ziemlich schnell rauskriegen und würde nur ungern die Datei und zig Dlls abgeben...

Danke schon mal im Voraus
 
Da hilft an der Stelle eigentlich nur exzessives Loggen.

Erst mal einschränken, bei welchem Befehl genau das absemmelt.

Oder weisst du genau, bei welchem Kommando das passiert?

Wenn Debug geht, aber Release nicht, dann ist das meistens irgendein Zugriff auf nicht initialiserte Variablen oder ein Bounds-Überlauf. Dreh mal die Warnungen auf Volle Kanne (also Level 3, Level 4 ist zu heftig). Evtl. ist da was Brauchbares dabei.
 
Also Level3 hatte ich schon an. Es kommt folgende Fehlermeldung:
"
Windows hat einen Haltepunkt in BionicGUI.exe ausgelöst.

Dies kann auf eine Beschädigung des Heaps zurückzuführen sein und weist auf ein Problem in BionicGUI.exe oder in einer der geladenen DLLs hin.

Weitere Analyseinformationen finden Sie möglicherweise im Ausgabefenster."

Der Fehler scheint in der Methode COccManager::preCreateDialog aufzutreten.
 
Uhwei, das klingt sehr schwer rauszukriegen. Hast du den Source von MFC installiert? Wenn ja, zeigt er dir evtl. einen von MFC eingebauten Assert an? Oder hängt er immer an der selben Zeile im Sourcecode?
Daran könnte man vielleicht etwas festhalten.
 
Vielleicht weiß ja jemand, welche Methode zuerst aufgerufen wird, wenn ich in den Druckdialog gehe? Anscheinend geht da ja vorher schon was schief...
 
Ich hab jetzt noch mal nachgeschaut: Im Debugmodus gehts auch nicht, wenn ich statisch verlinke. Der Modus ist also egal, nur sobald ich nicht mehr mfc dynamisch verlinke, kracht es. "Debug Assertion failed" und Zeile 41 in der f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\bardlg.cpp werden in einer Messabox als Fehler ausgegeben. Das seltsame ist, dass ich überhaupt kein Laufwerk f besitze, sondern nur c bis e...

Kann es sein, dass er irgendwie auf den nichtgültigen Pfad zugreifen will? Aber warum krachts dann erst in Zeile 41? Ominös...
 
Das ist der Pfad, den der Entwickler der MFC-Dll hatte. Hmm, bei mir steht in Zeile 41 der bardlg.cpp kein ASSERT, da haben wir wohl unterschiedliche Dateien.

Hast du den Source von MFC installiert? Such mal in deinem Visual Studio Ordner nach dem Ordner atlmfc und von da aus die passenden Unterordner (src/mfc). Da sollte dann auch eine bardlg.cpp liegen. Da in Zeile 41 müsste ein ASSERT stehen. Daran kannst du vielleicht ersehen, weshalb es kracht. Üblicherweise stehen da Kommentare in der Nähe.
 
Am Ende der .rc -Datei steht folgender Block, in dem noch die Datei "afxprint.rc" included werden muss, siehe Beispiel:
Code:
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_DEU)
#ifdef _WIN32
LANGUAGE 7, 1
#pragma code_page(1252)
#endif //_WIN32
#include "res\MeinProgramm.rc2"  // Nicht mit Microsoft Visual C++ bearbeitete Ressourcen
#include "l.deu\afxres.rc"          // Standardkomponenten
#include "l.deu\afxprint.rc"        // DIESE ZEILE ERGÄNZEN !!
#endif

Gruß
MCoder
 
Danke MCoder für den Tipp. Ich weiß zwar nicht wieso, aber jetzt stürzt das Programm schon mal nicht mehr ab. In der Entwicklungsumgebung läuft jetzt alles prächtig.

Seltsamerweise stimmt allerdings die Skala des Koordinatensystems, welches ich ausgeben will, nicht mehr, wenn ich die Exe starte (also nicht mehr aus der Entwicklungsumgebung). Statt von 0 - 90 geht sie mindestens in den 5stelligen Bereich und man kann die Kurve nicht mehr erkennen. Gibts da viell auch noch einen Geheimtipp, wie ich das Problem lösen kann? ;-)

@Encoder: Danke schonmal für die Hilfe, ich werd mir morgen mal die Datei anschauen (so ich sie denn finde).
 

Neue Beiträge

Zurück