NAN Error nach Windows Update

[stalkingwolf]

Es gibt hier von 2010 einen Thread https://www.delphipraxis.net/151702-...h-0-nan-2.html
Aber das kann es bei uns nicht sein. Kunden von uns haben Windows Updates eingespielt und nun werfen unsere Programm ( nicht immer aber mehrmals am Tag ), den Fehler NAN ist kein gültiger Fließkommawert aus.
Programme die schon länger beim Kunden sind und kein Update erhalten haben.

Wir haben nun innerhalb einer Woche 3 kunden welche das Problem mehrmals am Tag haben und angeblich die Programme von uns komplett beenden müssen, damit es wieder funktioniert.

Dabei ist es scheinbar egal ob das Programm mit Delphi 6, XE4 oder Berlin kompiliert wurde.

[Mavarik]

MaskEdits?

Mavarik

[stalkingwolf]

Die Frage ist ob wie MaskEdit Felder benutzen?
Falls ja, dann nein das benutzen wir nicht.

[hoika]

Hallo,
MadExcept benutzen, um beim Kunden den Fehler zu finden.
Besser wäre es aber, den Fehler selber nachstellen zu können.

[Der schöne Günther]

Ist das nicht verwandt mit dem Problem wie z.B. Druckertreiber (oder andere Dinge die von der eigenen Anwendung verwendet werden) die FPU-Einstellungen des Prozesses ändern und nicht wieder auf Delphi-Eigenart zurückstellen wenn sie fertig sind?

[stalkingwolf]

Das stand in dem anderen Thread.

Laut unserem Kunden würde das neustarten des Programmes das Problem lösen.
Mad Except wäre eine Idee.

[Luckie]

Hat das Update eventuell das Dezimaltrennzeichen geändert und euer Programm kommt damit nicht klar?

[stalkingwolf]

Zitat:

Zitat von Luckie (Beitrag 1450448)

Hat das Update eventuell das Dezimaltrennzeichen geändert und euer Programm kommt damit nicht klar?

Nein hat es nicht. Unser Programm kommt aber eh damit klar, da wir auch Kunden in der Schweiz haben.

Der Fehler tritt auch nur sporadisch pro PC auf, wenn der Fehler da ist, behebt nur das neu starten des Programmes den Fehler.
Andere PCs mit dem gleichen Programm auf den gleichen Datensatz haben kein Problem, aber es kann 1h auf dem gleichen PC, der gleiche Fehler auftreten.

Alle PCs haben eins gemeinsam. Es sind Windows 10 PCs mit dem neuesten Update.

Bei einem Kunden müsste ich nach den Druckern fragen, aber die haben eine Kooperation mit Canon und nicht HP.

[stalkingwolf]

Ok das Problem ist relativ simpel, hat aber definitiv was mit dem neuesten Windows Update ( scheinbar für alle Windows Versionen ) zu tun.

Und zwar ist nach einem .navigate auf der TWebBrowser danach das Exception Handling im Eimer.
Das passiert sogar mit alten Windows/IE Versionen, wenn auf der Seite ein Fehler auftritt. 403, Script Error usw.
Aber mit den neuen gepatchten Windows Versionen reicht ein about:blank

Code:

procedure TForm1.Button1Click(Sender: TObject);
var a,b: real;
begin

    webbrowser.Navigate('about:blank');
 // webbrowser.Navigate('http://www.google.de');
    try
            a:= 100;
            b:= 100;
            a:= a / (100 - b);
            showmessage(format('<%.2f> <%.2f>',[a,b]));
    except
        // a := 0;
        // on e:EZeroDivide do showmessage('EZeroDevide');
        on E : Exception do
            ShowMessage(E.ClassName+' error raised, with message : '+E.Message);
    end;
end;

Resultat ist keine Exception und in A steht INF.
In ein paar anderen Konstellationen kann auch NAN drin stehen.

Edit : System.Set8087CW(Default8087CW); nach .navigate aktiviert das Handling wieder.

Edit2 : 100% kann man sich auf das Set doch nicht verlassen und letztendlich ist das Problem auch das sich einige bei uns das Leben einfach gemacht haben und mit try/except eine Div durch 0 abzufangen :-) Die sauberste Variante ist natürlich das abfangen ob durch 0 dividiert wird.

[TurboMagic]

Kannst du das Problem mit dem verstellten x87 Modus bitte in Quality.embarcadero.com erfassen?
Evtl. können die ja etwas tun und es wird auch für die internationale Community besser sichtbar.

[Der schöne Günther]

Heißt ich hatte Recht 😎

[mjustin]

Descha wü :)

Why 1.99 suddenly no longer equals 1.99
https://mikejustin.wordpress.com/200...hy-is-199-199/

"TIBDataBase.Create(nil) changes the value of Get8087CW from $1372 to $1272 ..."

[stalkingwolf]

Zitat:

Zitat von Der schöne Günther (Beitrag 1450549)

Heißt ich hatte Recht 😎

halb :-) War halt nicht der Druckertreiber, sondern die Integration vom Internet Explorer durch TWebbrowser, welcher einem durch die neuesten Update vom Betriebsystem untergejubelt wird.

[TurboMagic]

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

[TiGü]

Zitat:

Zitat von TurboMagic (Beitrag 1450626)

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

Schon mal drüber nachgedacht, dass nicht alles im Emba-Spielfeld liegt?
Hier hat Microsoft doch ein bestehendes Verhalten kaputt gemacht.

[TurboMagic]

Zitat:

Zitat von TiGü (Beitrag 1450634)

Zitat:

Zitat von TurboMagic (Beitrag 1450626)

Ja und, hat jetzt jem,and von euch geprüft, ob das bereits in QP erfasst ist und falls nicht es erfasst?

Schon mal drüber nachgedacht, dass nicht alles im Emba-Spielfeld liegt?
Hier hat Microsoft doch ein bestehendes Verhalten kaputt gemacht.

Naja, es mag ja sein, dass Microsoft jetzt das x87 Optionen Register vermurkst,
aber evtl. könnte EMBT drum herum arbeiten?

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen? Oder ist der Aufruf ein direkter COM-Aufruf ohne einen Wrapper drumherum?
Dann ginge sowas natürlich nicht.

Grüße
TurboMagic

[Der schöne Günther]

Zitat:

Zitat von TurboMagic (Beitrag 1450676)

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen?

Das ist eigentlich Aufgabe von demjenigen der es ändert, also in diesem Fall des Fremdcodes (TWebBrowser oder was auch immer es jetzt war). Embarcadero/Delphi hat hier echt keine Schuld.

[TurboMagic]

Zitat:

Zitat von Der schöne Günther (Beitrag 1450724)

Zitat:

Zitat von TurboMagic (Beitrag 1450676)

Ginge vielleicht so etwas wie alten Wert vor Aufruf merken und direkt nach diesem
Aufruf wieder setzen?

Das ist eigentlich Aufgabe von demjenigen der es ändert, also in diesem Fall des Fremdcodes (TWebBrowser oder was auch immer es jetzt war). Embarcadero/Delphi hat hier echt keine Schuld.

Grundsätzlich richtig, nur wer informiert diesen Hersteller, damit der das repariert?
Wer hat einen Draht zu dem? Evtl. EMBT? Falls dem so ist, sollte in einem QP report
drinstehen, dass das Problem an der Wurzel beseitigt werden sollte und EMBT da ruhig
seine Kommunikationskanäle nutzen kann um den Verursacher auf das Problem aufmerksam
zu machen.

Alternativ jemanden von EMBT kontaktieren, der das Problem weiter trägt oder direkt
den Verursacher kontaktieren. Ansonsten sind wir evtl. noch in 10 Jahren dazu gezwungen
den Workaround zu benutzen der derzeit wo dokumentiert ist?
Richtig, m.W. nur in diesem Delphipraxis.net Thread...

Oder sehe ich da was falsch und wir sollen unsere Software mit Workarounds zupflastern? ;-)

Grüße
TurboMagic

[Fritzew]

[QUOTE=TurboMagic;1450749][QUOTE=Der schöne Günther;1450724]

Zitat:

Zitat von TurboMagic (Beitrag 1450676)

Oder sehe ich da was falsch und wir sollen unsere Software mit Workarounds zupflastern? ;-)

Grüße
TurboMagic

Tja, das Problem ist nicht neu.... David H hat das oft auf Stackoverflow thematisiert.
Solange sich nicht alle daran halten die FPU-Flags wieder zurückzusezen nach einer Änderung, kommt man nicht darum herum
genau das zu machen. Ist nicht schön, aber....
Noch schlimmer ist, das die Flags auch in Threads geändert werden können. Habe gerade bei uns mal geschaut,
Wir haben über 1000 Calls zu reset FPU..... (Bin im CAD-CNC)