Absturz ohne Fehlermeldung

Hi,

habe ein Programm das auf 3 gleich konfigurierten Rechnern (selbes Image) immer bei der selben Aktion abstürzt, dass Problem ist ich bekomme keinerlei Fehlermeldung oder sonstetwas es ist einfach komplett weg.
Wie kann ich an den auslöser herankommen? Und geht das überhaupt das es einfach so verschwindet? (.Net 2.0 ist es und sonst lässt sich das verhalten nirgendwo reproduzieren)

Meinst du mit Fehlermeldung keinerlei Exception oder irgendeine standart Fehlermeldung von Windows?

Hast du das Programm mal im Debug-Modus auf den Rechner laufen lassen ?

Handelt es sich um ein slebst erstelltes Programm oder ein fremdes?

Welche Aktion verursacht den Fehler?

Gibt es ein Log-File?

Hallo liam,

meine Vermutung ist, dass das Programm nicht abstürzt, sondern nur (aus deiner Sicht unerwartet) terminiert.

herbivore

Ist ein eigenes, dass Problem ist wenn man als erste Aktion auf eine Schaltfläche geht die ein Diagramm mit dummy Daten zeichnet passiert es, macht man irgendetwas anderes vorher passiert es nicht mehr.

Dann mach ein try catch drumrum und gibt die exception-message aus.

try{
//Dein Code
}
catch (Exception exc)
{
MessageBox.Show(exc.Message);
}

Evtl. Handeld es such um einen vollen Stack.
.NET applikationen rauchen dann kommentarlos ab (der stack ist ja voll, und es kann keine meldung mehr angezeigt werden).

Im Denug mode sollte die Exception allerdings abgefangen werden (Edit-And-Continue ist allerdings dann auch nicht mehr möglich.... stack ja voll)

Hallo cadi,

hm, also ich habe dann immer eine StackOverflowException oder zumindest die Meldung "Process is terminated due to StackOverflowException" bekommen. Auch im ReleaseMode. Aber eine Überlegung ist es natürlich wert.

herbivore

@ cadi .... kannst Du dazu ein bissel mehr sagen? Woran erkennt man das, dass der Stack voll ist? Wie groß ist er? Wie verhält sich .NET da insgesamt? ...?

@Golo,

soweit ich weiss nutzt .NET den stack, wie jedes andere 32bit x86'er Programm.
Die Größe ist im Exe-Heder hinterlegt:
SizeOfStackReserve : 00100000
SizeOfStackCommit : 00001000

d.h. 4kb vom start weg bis maximal 1MB (in c++ war 8kb default startwert).
Dieser Wert ist in C# fix. Dem linker kann man (zumindest im VisualStudio) da nix anders mitgeben.

Allerdings gibt es ein tool (editBin oder so), mit dem man die Stack-Size nachträglich ändern kann (im PE-Header).

Allerdings ist 1MB eine ganze menge und im Normalfall braucht es schon eine endlos-rekursion um den zum platzen zu bringen.
Ich habe es in c# erst einmal geschaft in einer terminirten rekusion so tief zu kommen, das der stack geplatzt ist (7500 geschachtelte suchen in einem B-Tree... schnell, aber extrem stack intensiv 😉

Äussern tut sich das mit einer simplen: 'System.StackOverflowException'

Die ist aber extrem gemein zu debuggen, da auch der Debugger den Stack zum evaluieren von Variablen braucht.
Im StackTrace sieht man dann meisten eine ewiglange liste mit funktionen die sich zirkulär aufrufen.

Zur Laufzeit ohne Deubgger wird es dann erst richtig gemein.

werder ein AppDomain.CurrentDomain.UnhandledException noch ein Catch können jetzt noch wirklich etwas ausrichten.
Es könenn ja keine calls mehr auf dem Stack platziert werden (die würden ja auch nur eine Stack-Exception auslösen). Somit verschwindet das Programm sang- und klanglos. (nichteinmal im eventlog wird das von der Runtime geloggt)

@herbivore: Diese Meldung kommt nur in einem Consolen-Fenster, wenn die app vom CMD aus gestartet wurde. Cmd wertet den ExitCode der Anwendung aus (-2147023895 = 0x800703e9 == StackOverflow ). Die Meldung kommt also nicht mehr vom Programm, sondern vom CMD.
In einer windows Anwendung kommt die Fehlermeldung im CMD nicht, aber die
ERRORLEVEL variable ist gesetzt.

Hallo cadi,

Diese Meldung kommt nur in einem Consolen-Fenster, wenn die app vom CMD aus gestartet wurde. Cmd wertet den ExitCode der Anwendung aus (-2147023895 = 0x800703e9 == StackOverflow ). Die Meldung kommt also nicht mehr vom Programm, sondern vom CMD. In einer windows Anwendung kommt die Fehlermeldung im CMD nicht, aber die ERRORLEVEL variable ist gesetzt.

man kann ein Windows-Awendung auch einfach als Consolen-Anwendung übersetzen und dann bekommt man die Meldung.

herbivore

@herbivore: jupp! aber eben nur, wenn es eine konsolen anwendung ist... wärend der entwicklung haben meine guis eh alle eine konsole zum schnell-mal-was-tracen 😉

Ich persönlich hätte es ja toll gefunden, wenn .NET den Stack schon ein paar byte vor dem platzen auf OS-Ebene mit einer Exception abgefangen hätte... dann könnte man wenigstens noch reagieren... so ist kann man die nichteinmal catchen!

Spannend wäre, ob die CriticalFinalizerObjects noch sauber zerstört werden.

Verwendest du irgendwelche Komponenten (DLLs)?

Hatte schon häufiger das Problem mit nicht sauber programmierten DLLs, die dann meine komplette Anwendung abgeschlossen haben. Einfach weg - ohne Fehlermeldung.

Was ähnliches hatte ich auch mal als ich mit C# im unmanaged-Speicher gearbeitet habe... nicht genug Speicher allociert und schon war die Anwendung weg - auch ohne Fehlermeldung (und noch dazu auf Windows Mobile 5 - das ist fies 🙂)

Nutzt du vielleicht was in der Richtung?

Hallo cadi,

danke für die sehr ausführliche Antwort. Ich habe zugegebenermaßen quasi null Ahnung von Stacks und Speichermanagement - daher eine etwas "dumme" Frage: Gibt es einen solchen Stack auch pro Thread, das heißt, könnte es aus diesem Grund passieren, dass ein Thread sich sang- und klanglos verabschiedet?

Viele Grüße,

Golo

@golo :ja, jeder thread hat einen eigenen Stack (eigentlich habe nur threads stacks, aber es gibt ja auch keien applikation ohne wenigstens einen thread)

Im stack wird quasi die ausführungs-history hinterlegt. (wie der stack-trace ja auch so schon zeigt... dieser zeigt allerdings den Call-Stack, nicht den Instruction-Stack).

Wenn du dir mal IL-Code anschaust siehst du, das z.B. Parameter auf den stack gelegt werden und dann eine methode aufgerufen wird. Die methode Pop't dann die parameter und Push'd ihr ergebnis auf den stack. Der Caller kann dann das ergebnis Poppen etc...

Letztlich liegt im Stack die gesamte Ausführungs-Hiostorie vom Main() bis zur aktuellen Methode. Das kann dann auch mal eng werden, vorallem bei rekursionen.
(Daher gibt es auch Menschen, die behaupten das rekursionen an sich böse seien... sehe ich nicht so, man muss nur wissen, welchen preis sie haben)

In c# kann man Stack-Size nicht setzen. Ich muss gestehen, ich weiss auch nicht ob die SizeOfStackReserve applikations-global oder thread lokal ist.

Was .NET allerdings macht ist - beim compilieren methode - ein metaproperty mitzugeben, in dem die maximale Stack-Nutzung (durch methoden aufrufe und lokale variablen) vermerkt ist (maxstack). Dieser Wert ist allerdings manchmal nicht berechnet, sondern einfach auf den default-wert 8 gesetzt (warum weiss nur MS)

Da der Stack-Overflow immer in einem Thread auftritt (sei es der Main-Thread oder irgendein innerhalb des main-threads gestarteter) macht es keinen unterschied wo das problem auftaucht. Stack-Overflow ist keine .NET exception, sondern eine OS-Exception. Wenn die gefuerert wird ist unweigerlich schluß mit lustig.

Man kann allerdings den CLR-Host anweisen, die AppDomain zu entladen, aber den Prozess weiterlaufen zu lassen.

Sang- und klanglosen Absturz kann ich allerdings durch StackOverflows unter 2.0 nicht erzeugen. Kommt immer ne entsprechende Meldung. Egal ob GUI oder CMD.

Aber zurück zum Thema: In 99% aller Fälle entsteht ein solches "unerwartetes Beenden" durch fehlerhaften Code, sprich unsauberes Exceptionhandling.

Original von svenson
Sang- und klanglosen Absturz kann ich allerdings durch StackOverflows unter 2.0 nicht erzeugen. Kommt immer ne entsprechende Meldung. Egal ob GUI oder CMD.

@svenson:
Auch ohne Debugger in einer reienen Windows Anwendung?
bei mir (auch 2.0) kommt da keien Meldung.

Original von svenson
Aber zurück zum Thema: In 99% aller Fälle entsteht ein solches "unerwartetes Beenden" durch fehlerhaften Code, sprich unsauberes Exceptionhandling.

Stack-Overflow lässt sich nicht per Catch abfangen!
Da kann man an der stelle nix richtig oder falsch machen. Die dürfen erst garnicht auftreten!

Original von cadi
@svenson:
Auch ohne Debugger in einer reienen Windows Anwendung?
bei mir (auch 2.0) kommt da keien Meldung.

Natürlich nicht die normale Exception-Dialogbox, aber diese "...hat ein Problem festgestellt"-Box.

Stack-Overflow lässt sich nicht per Catch abfangen!
Da kann man an der stelle nix richtig oder falsch machen. Die dürfen erst garnicht auftreten!

Keine Frage. Aber wenn ich den Thread richtig verfolgt hab, war die StackException nur eine Vermutung über die Fehlerursache. Und wenn die Anwendung ohne jede Box terminiert, dann wird es eben mit Sicherheit keine StackOverflowException sein. Denn weil man sie nicht fangen (und damit unterdrücken) kann, muss die o.g. Box kommen.

Wenn keine Box kommt, beendet eine Anwendung regulär oder schmiert u.U. in unmanaged Code ab (normalerweise erscheint ja auch hier ne Box, unter 1.1 hab ich aber auch schon komplettes Beenden beobachtet). Kann natürlich sein, dass der "reguläre" Code fehlerhaft ist und daher ein unerwartetes Verhalten zeigt. Darauf hat ja Herbi Eingangs schon hingewiesen.

Original von svenson

Original von cadi
@svenson:
Auch ohne Debugger in einer reienen Windows Anwendung?
bei mir (auch 2.0) kommt da keien Meldung.

Natürlich nicht die normale Exception-Dialogbox, aber diese "...hat ein Problem festgestellt"-Box.

Bei mir komm nicht mal diese Meldung! Evtl. ist mein DrWatson ja defekt 😉

Hmm, spannend. Interessiert mich nun auch woran das liegt. Wäre ja bitter, wenn man sich nicht darauf verlassen kann....

Hab hier nen Win XP SP2.

@svenson: Dito; XP mit SP2 und .NET v2.0.50727.
und auf einem Win2003 Server: das selbe Ergebnis (keine Meldung).

Ich hatte das Problem mal bei einem Kunden... Extrem gemein!
Kein Log-Eintrag, keine Meldung... NIX!
Und es war keine endos rekursion... Hat mich eine Stunde gekostet um den Fehler zu finden....

Hallo,
ich bin mir nicht ganz sicher, aber ich denke, ob die Meldung kommt hängt damit zusammen, ob die Fehlerberichterstattung in WinXP aktiviert ist.