Absturz Anwendung ohne Fehlermeldung

[haentschman]

Hallöle...8-)

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...:roll:

Ideen? Windows Update?

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

Danke :wink:

[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 :stupid: ...Crash :evil:

Fehler:
ntdll.dll
FaultTolerantHeap :gruebel:

[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?

[haentschman]

Zitat:

Sollte es tatsächlich an DevExpress liegen, würde ich mal in deren Foren recherchieren

... wie immer "wir können es nicht repoduzieren" :?
PS: das gleiche gilt auch für user32

Zitat:

appcrash ntdll.dll when closing form containing TcxGrid and TClientDataSet
JJ
Jamie James
created 11 years ago

I have a simple sample program. It has a TcxGrid that gets data from a SQL Server DB by using a TClientDataSet. It successfully gets the data and populates the grid. However, intermittently (more than half the time), when I close the program, I get a crash error. Sample program is attached, including Word doc with screen shots of this error.
To reproduce, press the button once to populate the grid. Press the button again to clear out the grid. Then close the app by pressing the X in the upper right corner.
Here is the text of the error.
Problem signature:
Problem Event Name: APPCRASH
Application Name: Sandbox2PoleList.exe
Application Version: 0.0.0.0
Application Timestamp: 00000000
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7600.16559
Fault Module Timestamp: 4ba9b21e
Exception Code: 80000003
Exception Offset: 0009f9aa
OS Version: 6.1.7600.2.0.0.256.4
Locale ID: 1033
Additional Information 1: d1ab
Additional Information 2: d1ab624ec7d094c26a73530c245a3468
Additional Information 3: d1ab
Additional Information 4: d1ab624ec7d094c26a73530c245a3468
Read our privacy statement online:
http://go.microsoft.com/fwlink/?link...8&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
SandboxPoleList2.zip
Comments (1)
Ingvar (DevExpress Support)
11 years ago

Hello Mary.
Thank you for your message.
Unfortunately, I did not manage to reproduce this problem using your example. Perhaps, there are some other things involved at your end. First, please make sure that you have all available updates for your IDE installed. Also, please check whether this problem can be reproduced using the standard TDBGrid.
Please keep me informed of your progress with this issue.
Best regards,


Ingvar.
Leave a Comment

PS: Ich habe auf 18.1 zurückgesetzt. Schaun wir mal...

Zitat:

Kann es sein, dass da ein rekursviver Aufruf nicht terminiert?

In die Komponente kann ich nicht wirklich nicht reingucken. In meinem Code NEIN. Ist auch nicht relevant beim "Activate" der Form von Extern.

[Delphi.Narium]

Zitat:

Zitat von haentschman (Beitrag 1481991)

In die Komponente kann ich nicht wirklich nicht reingucken. In meinem Code NEIN. Ist auch nicht relevant beim "Activate" der Form von Extern.

Aber sicherdoch ist das relervant: Wenn (aus welchem völlig unnachvollziehbarem Grund) das Activate ein Activate auslöst, das dann ein activateauslösendes Activate auslöst, das wiederum auch ein activateauslösendes Activate auslösen möchte, um so ein activteauslösendes Activate auszu... ...
Und schon hast Du einen derartigen Fehler :-(

Ist zwar schon lange her, aber genau sowas hab' ich mal gehabt und mir erstmal 'nen Wolf gesucht, bis ich dahintergekommen bin. Zumal: Im Debugger mit Haltepunkten durchbricht man quasi diese Kette, da ja der Debugger da dann in der IDE entsprechend stehen bleibt und dadurch das Problem behebt.

Da was bei, das weiterhelfen könnte? https://stackoverflow.com/questions/...-tolerant-heap

[Bernhard Geyer]

Zitat:

Zitat von haentschman (Beitrag 1481975)

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

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.