0 / 0 ergibt BlueScreen

[Mario.Noack]

Hallo NG,<p>
ich habe ein großes Problem. Ich verwende in meinem Programm folgende Routine:<p>
<PRE>
TRY
Wert1 := Wert2/Wert3;
EXCEPT
ShowMessage('Geht nicht');
END;
</PRE>
Die Werte sind vom Typ Double. Das Problem ist auf manchen Systemen kommt bei der Division ein BlueScreen, wenn Wert2 und Wert3 Null sind. Ich glaube es auf Systeme mit ATI128, VIA und Windows98 eingrenzen zu können. Leider ist mir die mögliche Ursache nicht ganz klar, weil ich den Fehler ja nicht nur umschiffen möchte. Wird denn bei Null/Null nicht auch eine Exception ausgelöst? Die Installation dieser betreffenden Rechner ist in Ordnung. Wir haben bei uns extra einen Rechner neu aufgezogen, um andere Programme ausschließen zu können und es war auch da reproduzierbar.<p>
Was könnten wir noch nachschauen? Wir nehmen für die Programm Delphi 5 mit SP1. Bei Compileroptionen sind wir alle möglichen Einstellungen schon durch.<p>
Es wäre toll, wenn jemand einen Ansatz hätte, was ich schauen könnte. Besten Dank,<p>
Mario Noack

[Thomas Melchert]

<p>Hallo Mario,<br>
<br>
die Execption die Du suchst ist <b>EMathError</b> bzw. <b>EZeroDivide</b>. Nähres dazu in der Delphi-Hilfe.<br>
Sollte sich damit der Fehler nicht abfangen lassen, dann bleibt Dir nichts anderes übrig, als den Wert des Teilers vor der Division zu prüfen.<br>
<br>
Gruß Thomas</p&gt

[Mario.Noack]

Hallo Thomas,<p>
ja, auf die Exception habe ich abgefragt. Die kam halt dann auch vor dem BlueScreen nicht. Von den ca. 10000 Installationen waren ca. 5 Rechner betroffen, bzw. von denen haben wir solche Rückmeldungen. Ich habe es nun so gelöst, daß ich wirklich auf den Wert 0/0 vorher abfrage. Das hilft sehr wohl, dieses Problem zu umschiffen, aber so richtig zu frieden bin ich irgendwie noch nicht damit. Weil ich ja in Zukunft nicht ausschließen kann, daß an andere Stelle eine ähnliche Situation auftritt. Trozdem vielen Dank Thomas<p>
Grüße, Mario Noac

[Thomas Melchert]

<p>Hallo Mario,<br>
<br>
die vorherige Abfrage ist bedeutend schneller, als in einer try .. except - Anweisung. Vor allem dann, wenn mehrere hundert bis tausend Anweisungen hintereinander ausgeführt werden müssen...<br>
<br>
Gruß Thomas</p&gt

[Hagen Volpers]

Ich bin nicht mehr so ganz wach und habe den Thread nur überflogen, aber warum überprüfst du nicht einfach Wert3 auf 0 ??? Das wäre doch einfacher und sicherer oder nicht ???<BR>
Wenn das schon gesagt wurde, sorry das ich mich eingemischt habe ... <BR><BR>Ciao Hage

[Mario.Noack]

Hallo Hagen,<p>
das habe ich auch jetzt so gemacht, anders ging's halt auch wirklich nicht. Das Problem ist halt nur, dass ich dafür den ganzen Code ändern musste, da solche Sachen teilweise ja auch in komplexeren Formeln [w1=w2/(w3+w4)] auftraten. Naja, nun ist alles geändert, war damals aber schon ärgerlich...<p>
Grüße, Mario Noac

[Andreas Kosch]

Hallo,

ist auf diesen Rechnern ein HP-Druckertreiber installiert? Wenn ja, ist der Übeltäter gefunden. Microsoft hat in seiner <i>Knowlegde Base</i> eine Warnung, dass HP in seinen Treiber-DLLs die Win32-Exception-Behandlung für diese Exception versehentlich global abschaltet, so dass jeder TRY..EXCEPT-Block im Programm wirkungslos ist

[Mario.Noack]

Hallo Andreas,<p>
ich bin mir nicht mehr ganz sicher, aber ich dächte, der Rechner wäre ganz frisch aufgesetzt und hatte noch gar keinen Druckertreiber. Das Problem lies sich wirklich auf neueren Athlon-Kisten reproduzieren (in Kombination mit VIA). Zudem war es nicht das Problem, dass der Exception-Block nicht kam. Vielmehr kam ein BlueScreen und das ist bei einer Exception eigentlich nicht so unüblich.<p>
Ich habe damals extra mit D3 & D5 ein Demoprog geschrieben, was auf Buttonclick nur das Ergebnis von 0/0 ausgeben sollte. Sobald der Button geklickt wurde, kam auf meinem Rechner (mit HP-Treiber) ganz sauber die Exception und auf dem Testrechner der BlueScreen. Ich denk mal, da war noch ein Fehler beim Ansprechen der Fliesskommaeinheit.<p>
Schöne Grüße, Mario Noac

[Andreas Kosch]

Hallo,

da schein noch ein anderer Übeltäter diese Win32-Exception abzuschalten. Normalerweise löst Win32 in derartigen Fällen eine Exception aus, die von der Anwendung aufgegriffen werden kann (es kommt niemals zum "Screen of Death"). Allerdings darf man diese Win32-Exception-Behandlung gezielt abschalten, indem sich die eigene Anwendung als zuständig erklärt. Wird dieses Umbiegen am Ende nicht rückgängig gemacht, bleibt das Betriebssystem mit dem BlueScreen stehen, da niemand mehr diese Exception als bearbeitet deklariert und die CPU daher die Notbremse zieht

[Mario.Noack]

Hmm.. und das könnte dann unter Umständen ein Treiber sein, zum Beispiel der vom Chipsatz. Klingt logisch..<p>
Danke, Andrea

[Andreas Kosch]

... oder ein Spiel. Gerade die Spiele (die um jede Microsekunde feilschen) schalten gerne alles ab, was CPU-Zyklen kosten könnte :-