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.

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

[haentschman]

Danke...:P

Zitat:

IMAGE_FILE_NET_RUN_FROM_SWAP

... wo kommen die hin? DPR?

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1482028)

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.

[himitsu]

Delphi-Quellcode:

{$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP}

// oder (jenachdem ob man die passenden Konstanten eingebunden hat)

// $0400 IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP   If Image is on removable media, copy and run from the swap file.
// $0800 IMAGE_FILE_NET_RUN_FROM_SWAP         If Image is on Net, copy and run from the swap file.
{$SetPEFlags $0C00}

Oder als Nummer in den Projektoptionen > Erzeugen > Delphi-Compiler > Linken > Zusätzliche PE-Header-Flags



Ja, bei vorkompilierten Packages/DLLs von Fremdherstellern könnte man nur noch nachträglich den PE-Header umschreiben.
Alternativ kann man bei allen geladenen DLLs in den Programmspeicher schreiben und so durch das Copy-on-Write der als Memory-Mapped-Files eingebundenen DLLs den Speicher permanend lokal halten. (und dabei hoffen der Virenscanner sieht das nicht als böses Omen und schreitet ein)

[haentschman]

Moin...:P

Zwischenstand:
:evil: keine Änderung! Anwendung wird ohne Fehlermeldung beendet!

Gemacht:
1. IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP
2. DevExpress zurückgesetzt
3. "Vielleicht brauchst Du eine aktuellere Version der Microsoft Visual C++ Runtime-Bibliothek"

Info:
Manchmal kommt es vor, daß vor dem Absturz eine MadExcept Meldung angezeigt wird. Die Mail kommt aber nicht an! In der Meldung steht "Unknown"...
http://docwiki.embarcadero.com/Libra...validOperation

Bild2:
So will ich auch programmieren! :stupid:

[himitsu]

Ach DevExpress ... joar, da knallt es hier auch ab und an, an den wildesten Stellen. :lol:

In TWinControl.CreateWnd gibt es nur eine Stelle für ein EInvalidOperation. Da läge es dann an einem fehlenden Parent.
Die anderen Stellen sollten alle nur EOSError liefern.
Hab hier kein Berlin und da stimmen im 10.4 bei mir die Codezeilen mit denen deines ErrorLogs nichtmal ansatzweise überein, aber wenn, dann kann es nur das InvalidControlOperation am Anfang sein (+13).

Potentielle EInvalidOperation und InvalidControlOperation findet man in der Vcl.Controls auch an zuvielen anderen Stellen.

[haentschman]

Danke...:P

Früher hatte ich ständig "Element hat kein übergeordnes Fenster". Irgendetwas ist seit geschätzten 3 Monaten anders. Diese Meldung bekomme nicht mehr...dafür aber der Komplettabsturz! Da war mir der Fehler aber lieber... :roll:

Damals hatte mir DevExpress einen Fix geschickt. Da war es mengentechnisch besser aber nicht weg. Den werde ich erstmal wieder ausbauen...

Zitat:

Ach DevExpress ... joar, da knallt es hier auch ab und an, an den wildesten Stellen.

VCL ist bei denen das Stiefkind. Aber bei so einem Preis sollte es funktionieren! :roll: Der Fehler "Element..." existiert seit mindestens 12 Jahren! :evil: