Board00 Geschrieben 5. April 2007 Teilen Geschrieben 5. April 2007 Hallo ich bins wieder und habe wieder eine tolle Fehlermeldung. Wenn ich die Funktion CreateWindow aufrufe bekomme ich eine AV (siehe Anhang). HWND Modulfenster = (info).handles.Modulfenster; HWND handle = NULL; HINSTANCE Instance = (info).hInstance; handle = CreateWindow (szAuswahlModule, "Modul", WS_CHILD | WS_VISIBLE , // Flags 0, 0, 0 , 0, Modulfenster, //ParentWindow (HMENU)NULL, // Menu? Instance, // Instanz des Programms (LPVOID)NULL ) ; info ist ein Paramter von der Struktur ProgrammInformation den ich übergebe. struct ProgrammInformation { HANDLEPUFFER handles; float Zoom; TYPE SPS_Typ; bool EA_aktiviert; SchalterLogik SchaltLogik; BildLeisteninfo AuswahlLeiste; BildLeisteninfo Zeichenblatt; MODUS Modus; HINSTANCE hInstance; int ModulBreite; int Raster; Schriften Schrift; BilderStruct Bilder; Elemente ElementAnzahl; Blattgroesse size; DateiInfo Datei; int AnzahlElemente; SpeicherLaenge Speichergroesse; Sprache SprachVersion; }; Die Werte werden beim Start alle schön eingetragen und wenn ich einen Haltepunkt vor CreateWindow setze steht überall was drin. Warum knallt es hier ab und zu. Das passiert nicht immer, aber ab und zu Mal. Wenn ich das Programm ohne Debugger starte (STRG + F5) gehts, nur beim Debuggen (F5) knallt es öfters mal. Habt ihr eine Idee (vllt du Klotzkopp? :hells: ) ? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Klotzkopp Geschrieben 5. April 2007 Teilen Geschrieben 5. April 2007 Die Fehlermeldung lässt auf einen Lesezugriff über einen Nullzeiger schließen. Wenn der Fehler im Debugger auftritt, kannst du über die Aufrufliste (Callstack) prüfen, aus welchem Teil deines Codes der problematische Aufruf kam, und dort prüfen, welcher Zeiger Null ist, der nicht Null sein darf. Dass es beim Debuggen passiert und sonst nicht, legt ein Timingproblem nahe. Hantierst du mit Threads? Wie "übergibst" du diese Struktur? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Board00 Geschrieben 5. April 2007 Autor Teilen Geschrieben 5. April 2007 Wenn der Fehler im Debugger auftritt, kannst du über die Aufrufliste (Callstack) prüfen, aus welchem Teil deines Codes der problematische Aufruf kam, und dort prüfen, welcher Zeiger Null ist, der nicht Null sein darf. Hi Klotzkopp, da ist keiner NULL: GrafikOberfläche.exe!erstelleAuswahlModule(ProgrammInformation info={...}, char * szAuswahlModule=0x004db0a8) Zeile 197 C++ GrafikOberfläche.exe!ErstelleModulAuswahl(void * * AuswahlSpeicherHandle=0x004dcff4, ProgrammInformation * info=0x004dcff8) Zeile 677 + 0x1c Bytes C++ GrafikOberfläche.exe!ArbeitsfensterProc(HWND__ * hwnd=0x00010ef0, unsigned int message=273, unsigned int wParam=57600, long lParam=0) Zeile 808 + 0xf Bytes C++ user32.dll!77d18734() [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für user32.dll] mehrere user32.dll-Aufrufe GrafikOberfläche.exe!ArbeitsfensterProc(HWND__ * hwnd=0x9de1a96a, unsigned int message=1243932, unsigned int wParam=2010220340, long lParam=69360) Zeile 759 C++ mehrere user32.dll-Aufrufe GrafikOberfläche.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * szCmdLine=0x00151f1d, int iCmdShow=1) Zeile 189 C++ GrafikOberfläche.exe!__tmainCRTStartup() Zeile 324 + 0x35 Bytes C GrafikOberfläche.exe!WinMainCRTStartup() Zeile 196 C kernel32.dll!7c816fd7() Dass es beim Debuggen passiert und sonst nicht, legt ein Timingproblem nahe. Hantierst du mit Threads? nein ich nutze keine Threads. Wie "übergibst" du diese Struktur? Erst wurde sie als Zeiger übergeben, dann hatte ich es umgeändert auf einen einfachen CallByValue, kein Unterschied. erstelleAuswahlModule(ProgrammInformation info,TCHAR szAuswahlModule[]) Kann es wegen dem szAuswahlModule knallen? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Klotzkopp Geschrieben 5. April 2007 Teilen Geschrieben 5. April 2007 da ist keiner NULL:Das kann man aus dem Callstack allein nicht ablesen. Kann es wegen dem szAuswahlModule knallen?Sicher. Ist Zeile 197 der CreateWindow-Aufruf? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Board00 Geschrieben 5. April 2007 Autor Teilen Geschrieben 5. April 2007 Das kann man aus dem Callstack allein nicht ablesen. Wie dann? Bei einem Haltepunkt davor steht eigentlich überall was drin, da ist nix NULL. Sicher. Ist Zeile 197 der CreateWindow-Aufruf? nee, das ist in Zeile 201. Ich hatte einfach ein _try _except drumgemacht und Zeile 197 ist das _try. Warum kann es bei szAuswahlModule knallen? Das wurde mit RegisterClass registriert und sollte gehen. Und es steht ja auch was drin. //Edit: Wenn ich das Programm über den Remotedebugger debugge, dann geht alles :eek Wieso gehts da, aber beim lokalen Debugger nicht? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Klotzkopp Geschrieben 5. April 2007 Teilen Geschrieben 5. April 2007 Wenn ich das Programm über den Remotedebugger debugge, dann geht alles :eek Wieso gehts da, aber beim lokalen Debugger nicht?Wie du an der Fehlermeldung sehen kannst, ist das eine "First Chance Exception". Das bedeutet, dass eine Exception innerhalb eines try-Blocks aufgetreten ist, dessen catch-Teil auf die aufgetretene Exception "passt". Die Exception wird geworfen und im catch-Block behandelt. Ob ein Debugger bei so etwas anhält, ist einer Frage der Einstellungen des Debuggers. Dein lokaler Debugger ist offenbar so eingestellt, dass er bei First-Chance-Schutzverletzungen anhält, der Remote-Debugger aber nicht. Hat dieser try-catch-Block denn an dieser Stelle wirklich einen Sinn, oder war das nur die Symptombehandlung eines Laufzeitfehlers? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Board00 Geschrieben 5. April 2007 Autor Teilen Geschrieben 5. April 2007 Wie du an der Fehlermeldung sehen kannst, ist das eine "First Chance Exception". Das bedeutet, dass eine Exception innerhalb eines try-Blocks aufgetreten ist, dessen catch-Teil auf die aufgetretene Exception "passt". Die Exception wird geworfen und im catch-Block behandelt. Ob ein Debugger bei so etwas anhält, ist einer Frage der Einstellungen des Debuggers. Dein lokaler Debugger ist offenbar so eingestellt, dass er bei First-Chance-Schutzverletzungen anhält, der Remote-Debugger aber nicht. OK, das klingt einleuchtend. Ich hab jetzt eine Idee, warum es knallt. Vor dem CreateWindow wird ja die WM_Create Message gesendet und die wird behandelt. Dort werden bestimmte Funktionen aufgerufen und das klappt wenn ich es im Remotedebugger starte oder ohne Debugger starte. Wen ich an einer anderen Stelle wieder eine der Funktioenn aufrufe die auch bei dem WM_Create aufgerufen werden knallt es bool TextEinfuegen(HDC *Abbhdc, HBITMAP *AbbBild, BlockSpeicherFeld *ModulDaten,ProgrammInformation *info) , da dort der Zeiger auf die ProgramInfo Struktur NULL ist :upps Nur wie bekomme ich raus, wo diese globale Variable ( :old ) auf einmal NULL wird? Hat dieser try-catch-Block denn an dieser Stelle wirklich einen Sinn, oder war das nur die Symptombehandlung eines Laufzeitfehlers? das war nur eine Symptonbehandlung :hells: :hells: :hells: Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.