Absturz Anwendung ohne Fehlermeldung

[haentschman]

Hallöle...

Seit einer Weile, ich kann es nicht genau beziffern, treten in unserer Anwendung Fehler auf die die Anwendung zum Crash bringen ohne daß der MadExcept eine Chance hat den Fehler zu schicken. Die Fehler sind aber im EreignisLog protokoliert. (Bilder)
Ich habe das nur mitgekriegt, weil meine üblichen DevExpress Meldungen quasi gegen 0 gesunken sind.

Der Fehler tritt auf wenn man von einem externen Fenster, Excel etc., wieder die Anwendung "aktiviert". (Mehrere User haben das berichtet)

Was ich diesem Zeitraum gemacht habe:
1. DevExpress von 18.1.3 auf 18.2.13 gehoben
2. Keine anderen Komponenten aktualisiert
3. Normale QT Änderungen

Die Anwendung liegt auf einem Netzlaufwerk. Das Problem haben trotzdem nicht alle Arbeitsplätze...

Ideen? Windows Update?

PS: Ich würde die DevExpress Version mal zurücksetzen...oder?

Danke

[DeddyH]

Vielleicht brauchst Du eine aktuellere Version der Microsoft Visual C++ Runtime-Bibliothek, zumindest legt die erste Meldung den Verdacht nahe.

[haentschman]

Danke...

Auf meiner Entwicklung ist die Letzte "2015" - 14.0.23

Was ist die aktuellste?

PS: Auf dem Problemrechner ist es exakt die selbe Version...Aktuelle Updates

[DeddyH]

https://support.microsoft.com/de-de/...f-95f26a218cc0
Die Probleme kenne ich im Zusammenhang mit der Swissbit-TSE, da war es angeraten, die 2015/2017/2019-Version zu installieren.

[haentschman]

Danke...

Läßt sich das auch über die Domain ausrollen? Oder erst mal ein Arbeitsplatz?

Arbeitsplatz erledigt...Test ...Crash

Fehler:
ntdll.dll
FaultTolerantHeap

[DeddyH]

Sollte es tatsächlich an DevExpress liegen, würde ich mal in deren Foren recherchieren, Du wirst das Problem ja nicht alleine haben.

[TigerLilly]

Hmm, so ganz obskure Fehler in der ntdll.dll lassen mich immer zuerst an einen Stacküberlauf denken. Kann es sein, dass da ein rekursviver Aufruf nicht terminiert?

[Bernhard Geyer]

Zitat von haentschman:

Die Anwendung liegt auf einem Netzlaufwerk. Das Problem haben trotzdem nicht alle Arbeitsplätze...

Bei den Problemrechnern soll das mal Lokal kopiert und gestartet werden.

In Delphi haben wir wegen bei Problemen bei Kunden mit Netzwerkstart jetzt die PE-Flags

IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP

gesetzt.
Damit sind einige Fehler beim Betrieb von Netzwerklaufwerk gelöst.

[himitsu]

Bissl ungünstig ist, dass diese Flags in JEDER DLL/BPL gesetzt sein müssen, weil es sonst absolut keinen Sinn macht.
(k.A. warum die Angabe in der EXE nicht für alle DLL/BPL verwendet werden)

[Bernhard Geyer]

Zitat von himitsu:

Bissl ungünstig ist, dass diese Flags in JEDER DLL/BPL gesetzt sein müssen, weil es sonst absolut keinen Sinn macht.
(k.A. warum die Angabe in der EXE nicht für alle DLL/BPL verwendet werden)

Ja. Leider. Sorgt aktuelle mit der CEF-Integration zu Problemen bei Netzwerknutzung.