Konsolenprogramm, Verhindern der Meldung mit den GPF und ok klicken müssen
-
Servus,
Folgendes: Apache auf Win XP SP 3, die CGI-Programme habe ich in C
geschrieben. Das System läuft stabil. Es kann natürlich vorkommen, daß
mal ein Programm crasht, ich erhalte dann eine Windows-Box mit der Nachricht
"Programmabsturz" oÄ und ein OK zum Anklicken. Kann man diese Meldung
irgendwie unterdrücken ?Speziell bei Konsolenprogrammen die aus einem Batchfile aufgerufen werden
ist das extrem lästig.
-
Behebe den Fehler...
-
Martin Richter schrieb:
Behebe den Fehler...
Die Fehler ergeben sich fast immer aus den Daten die ich geliefert bekomme.
Es ist schlicht nicht möglich da jeden Unsinn abzufangen den sich ein Kunde
ausdenken könnte und mir das Programm abschießt.Es ist halt extrem lästig, sich, wenn's sich zu lange nicht mehr rührt, sich
auf den jeweiligen Rechner einzuloggen und das "ok" zu klicken.
-
Dan überprüf nicht, ob die Daten fehlerhaft sind, sondern, ob sie richtig sind.
-
Ich bleibe dabei. Kein Dateneingabe darf zu einem UAE führen.
Diese minimale Sicherheitsprüfung muss sein.Alleine wenn die Daten "nur etwas fehlerhaft" sind un nicht den UAE herbeiführen aber Speicherzellen so verändern, dass daas Programm "massenweise falsche Daten" erzeugt.
-
Problem nicht verstanden ?
Ein Zustand eines Programmes daß es nicht bei jedem denkbaren Unsinn (das
Problem ist das "denkbar") aus der Bahn wirft wirst Du außer copy nicht finden.
Auf Fehler kann ich reagieren und diese abfangen wenn ich sie kenne.
-
Scheppertreiber schrieb:
Problem nicht verstanden ?
Doch. Ich denke ich habe das Problem versanden.
Meine Software verarbeitet ich "Import-Dateien". Da kommt ein Anwender auch mal auf die Idee und "importiert" eine EXE. Mein Programm kann das ab...
Doch man kann genau die Fälle (am meisten ist es ein Pufferüberlauf) abfangen.
Und ein UEA ist auch bei den unsinnigsten Eingaben zu vermeiden.
Wenn man nicht damit rechnet oder es behebt, geht man evt. weitaus schlimmere Flgen ein wenn die "falsche Eigabe" etwass bewirkt was "weniger als ein UAE" ist.Und ja. Ich bin mir sicher, dass man ohne großen Mehraufwand so programmieren kann, dass UAEs nicht vorkommmen.
Ich bleibe dabei: Behebe den Fehler...
-
Scheppertreiber schrieb:
Es ist schlicht nicht möglich da jeden Unsinn abzufangen den sich ein Kunde
ausdenken könnte und mir das Programm abschießt.Es ist möglich, und es ist deine Pflicht, dafür zu sorgen. Ich kann Martin Richter da nur zustimmen.
Ein Programm, das sich durch falsche Daten zum Absturz bringen lässt, ist ein Sicherheitsproblem und gehört auf den Müll.
-
Mannomann ...
Bis das Programm produktiv läuft passieren solche Sachen halt mal. Ist das
so schwierig zu verstehen ? Ich habe eine konkrete Frage und es kommen nur Allgemeinplätzchen.
-
Wenn du es wirklich so lösen willst, findest du in dieser (witzigerweise von Martin geführten) Diskussion eventuell einige Hinweise, wie du die Meldung unterdrücken kannst:
-
Scheppertreiber schrieb:
Mannomann ...
Bis das Programm produktiv läuft passieren solche Sachen halt mal. Ist das
so schwierig zu verstehen ?1. Nein! Solche Sachen passieten nicht mal so. Solche Minimal-Checks die einen UAE verhindern snd ein "must". Ich sage nicht, dass man keine Programmfehler verhindern kan. Aber UAE's Aufgrund unsinniger Daten...
2. Nein! Du hast einen Lösungsweg bekommen. Der gefällt Dir nur nicht.
-
_matze schrieb:
Wenn du es wirklich so lösen willst, findest du in dieser (witzigerweise von Martin geführten) Diskussion eventuell einige Hinweise, wie du die Meldung unterdrücken kannst:
Klar will ich es in dieser Richtung lösen.
Aus Laufzeitgründen ist es nicht möglich alle einkommenden Daten VOR der
Verarbeitung auf Sauereien abzuprüfen. Im produktiven Betrieb werden die
Daten kundenseitig automatisch exportiert und übertragen, da brennt normal
nichts mehr an.Lästig wird es bei Musterdaten wo manchmal schlicht Müll rüberkommt.
Die Testerei läuft dann halt auf dem schnellsten Rechner den ich in die Finger
bekomme auf einer lokalen Platte. Dann dort einloggen ist halt lästig um nachzusehen.Darum geht es und nicht um konspirative "Pflichten".
-
Scheppertreiber schrieb:
Im produktiven Betrieb werden die
Daten kundenseitig automatisch exportiert und übertragen, da brennt normal
nichts mehr an.Normal nicht, aber wenn doch, fällt das dann nicht auf dich zurück? Ich weiß genau, ich würde in solchen Fällen eins auf den Deckel kriegen. Vom Kunden und vom Chef.
-
_matze schrieb:
Scheppertreiber schrieb:
Im produktiven Betrieb werden die
Daten kundenseitig automatisch exportiert und übertragen, da brennt normal
nichts mehr an.Normal nicht, aber wenn doch, fällt das dann nicht auf dich zurück? Ich weiß genau, ich würde in solchen Fällen eins auf den Deckel kriegen. Vom Kunden und vom Chef.
Ich habe zur Verarbeitung nur ein begrenztes Zeitfenster. Alles kann ich da nicht
prüfen. Der Kram läuft nachts ab ca 3 Uhr und muß bis 6 Uhr fertig sein. Wenn
da zB ein Fehler passiert und das Programm (trotz aller Vorsicht) dennoch
abschmiert wäre es auch nicht so schlecht wenn das startende Batch in diesem
Fall eine Mail schicken kann anstatt in dieser blöden MsgBox stehenzubleiben.In diesem Jahr waren es für einen Kunden knapp 800GB ... wie soll da einn
Vorabtest aussehen
Der Test ist halt dann der Import.
-
Lösung für XP SP3 in C:
char *p = NULL;
SetErrorMode( SetErrorMode( SEM_NOGPFAULTERRORBOX)
|SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
strcpy( p, "Hallo");erzeugt einen GPF und gibt an das Batch einen errorlevel -1
-
Dazu muss er aber jede Anwednung anpassen, die er aber nicht hat...
