Anwendung stürzt ausserhalb Visual Studio ab

das_brot

Guten Abend!

Ich hab' mir eine Direct-X Applikation geschrieben, welche sich nun etwas komisch verhält:

-Release und Debug, gestartet aus VS (F5/Play-Taste) funktionieren tadellos
-Release, gestartet ausserhalb VS, hängt sich nach einer gewissen Zeit (aber immer am gleichen Ort) auf ("Das Programm hat einen Fehler verursacht und muss geschlossen werden")
-Debug, gestartet ausserhalb VS, hängt sich beim Schliessen des Fensters auf (Fehler wie Release).

Ich poste gerne Code und gebe weitere Auskünfte, da ich den Fehlerverursacher aber nicht wirklich eingrenzen kann, habe ich vorerst nicht den ganzen Post zugemüllt... (könnte ja was bekanntes/simples sein)

Wäre cool, wenn mir jemand helfen könnte
grZ
/me

estartu

Arbeitest du irgendwo mit Dateien?
Die Pfade sind anders, je nachdem ob du aus VC oder aus dem Explorer startest.

Bau dir doch mal AfxMessageBox Aufrufe an markanten Stellen ein, so kannst du nach und nach den Fehler einkreisen.

Es gibt dann noch Remote-Debuggen, vielleicht hilft dir das ja weiter. Siehe auch mein Artikel Kapitel 14.

hustbaer

Verwendest du Threads? Wenn ja hast du u.U. ne race condition - die Symptome würden passen. Sowas zu finden macht viel Spass

Versuch mal ein paar CPU-Zeit-Fresser (kannst dir auch ein kleines "while(1);" Programm schreiben zu dem Zweck) nebenbei laufen zu lassen. Wenn das auch das Verhalten deines Programmes verändert ist es fast sicher eine race condition.

Wulk

das_brot schrieb:

Guten Abend!

Ich hab' mir eine Direct-X Applikation geschrieben, welche sich nun etwas komisch verhält:

-Release und Debug, gestartet aus VS (F5/Play-Taste) funktionieren tadellos
-Release, gestartet ausserhalb VS, hängt sich nach einer gewissen Zeit (aber immer am gleichen Ort) auf ("Das Programm hat einen Fehler verursacht und muss geschlossen werden")
-Debug, gestartet ausserhalb VS, hängt sich beim Schliessen des Fensters auf (Fehler wie Release).

Ich poste gerne Code und gebe weitere Auskünfte, da ich den Fehlerverursacher aber nicht wirklich eingrenzen kann, habe ich vorerst nicht den ganzen Post zugemüllt... (könnte ja was bekanntes/simples sein)

Wäre cool, wenn mir jemand helfen könnte
grZ
/me

Hi,

leider verändert sowohl die Verwendung von Optimierungen (Releasebuild) als
auch die Anwesenheit eines Debuggers das Verhalten eines Programs oft entscheidend.

Solltest Du also nicht weiter kommen, empfehle ich Dir, folgendes in Erwägung zu ziehen, um wenigstens an einen finalen Callstack zu kommen.

Voraussetzung ist zunächstmal ein Releasebuild mit Debug Informationen

- Schau Dir an, wie structured exception handling funktioniert (SetUnhandledExceptionFilter)
- Schau Dir an, wie die DbgHelp.lib zu verwenden ist. Sie brauchst Du hauptsächlich, um Adressen Symbolnamen zuordnen zu können
- Schau Dir an, wie die StackWalk64 Funktion zu verwenden ist. Mit Ihrer Hilfe
kannst Du Dich durch den Callstack hangeln

Falls Du hierzu weitere Fragen hast, nur zu.

Gruß,

Matthias.

Martin Richter

Kannst Du den Debugger nicht nachträglich an das abgestürzte Programm anhängen?
Oder Attache das Programm kurz bevor Du es beendest. Evtl. führt das den Crash auch herbei.

Ich hatte mal genauso ein Problem und dort kam es sehr darauf an, wie bestimmte Adressbereiche alloziert wurden und der Speicher benutzt wurde. War der Debugger von Anfang an im Prozess wurden gänzlich andere Speicherbereich erzeugt und der Fehler nicht nachvollziehbar.

Den Grund verrate ich auch gerne:
Ich hatte eine Routine, die CR/LF Sequenzen in einfache LF's verwandelt. Leider war der Speicher zu groß angegeben und also suchte er über den angegebenen Text hinaus. Danach lag eine nette Zeigertabelle. Alles klar solange nicht eine Adresse mit der Kombination 0d0a vorkommt. Und das ist nicht unbedingt häufig...

Danke erstma für eure Anregungen!
Die Pfade habe ich natürlich berücksichigt, ich probier' mal, den Debugger nachträglich anzuhängen, werde dann schreiben, was das genau gebracht hat.

Gruss
me