Exception in Laufzeitbibliothek einfangen unter Win 2019 server

[Jelen]

Das ist richtig, ich hatte vergessen zu erwähnen, es gibt eine weitere Exe, die dieselben BPLs verwendet.
Außerdem ist mein Test-Server ein virtueller, auf den ich per RDP zugreife, der Upload läuft trotz guter Internetverbindung recht langsam. Um überhaupt dahinter zu kommen, was da passiert, habe ich vermutlich 50 Updates aufgespielt, weil bei fehlender Exception-Behandlung nur aus dem Absturzcode 0eedfade ja nicht wirklich viel abzuleiten ist. Wenn man dann fast im Minutentakt Updates hochlädt, freut man sich schon über jedes MB, was gespart werden kann.

[himitsu]

70 MB für eine Single-EXE ist jetzt noch nicht soooooo groß.
Es ist lange her, als ich für einen Bugfix mit einem alten WinXP mal unser Projekt versuchte ohne Packages/DLLs zu kompilieren.

4-14 MB die EXEn
685 MB inkl. allen eigenen BPL/DLL
256 MB fremd-DLL/BPL + 115 MB Debuginfos (ohne DevExpress)
42 MB die Delphi-Packages
...

macht insgesamt, inkl. DevExpress
1,58 GB + 900 MB an DebugInfos (Delphi 11)



Eigentlich sollte es mit BPLs weniger Problemengeben,
aber bei DLLs, gibt es nerviges Verhalten, leider im einfachen TestCode nicht nachvollziehbar.

Irgendwo versteckt sich in System/SysUtils/... eine Funktion, welche beim Verlassen einer DLL-Funktion die Delphi-Exception in eine Systemexception zurückkonvertiert (vor allem EExternal ala EAccessViolation, EDivByZero usw)
Leider fand ich ihn nicht wieder.

Ist prinzipiell dafür gedacht, wenn eine Exception aus einer Delphi-DLL z.B. in ein C++-Programm durchrauscht.


Grundsätzlich würde dann auf der anderen Seite, wenn es wieder in ein Try-Except läuft, daraus wieder eine neue Delphi-Exception.

Drum ist auch ein Code ala

Delphi-Quellcode:

try
  ...
except
  on E: Exception do begin
    E.Message := E.Message + ' irgendwas';
    raise
  end;
end;

keine gute Idee, weil hier der geänderte Text wieder verschwinden würde, wenn sowas passiert.



Mit hart verlinkten Packages über einen WebShare .... boar, dank eines Bugs im Windows/Samba, haben wir grade wieder einen Kunden, wo es pro BPL 1-3 Sekunden zum Laden dauert und bei 355 BPLs macht das dann ............... bis der SplashScreen nacht knapp der Hälfte aufgeht.
Und wer bei Mikrosoft auf die schwachsinnige Idee kam, die PE-Flags für Caching von DLLs aus Netzlaufwerken/Wechseldatenträgern für JEDE einzelne DLL, anstatt einmal aus der EXE zu nehmen ..... (bei Fremd-DLL/BPL das Flag/Bit zu ändern ... bähhhhhhhh)

[Delphi.Narium]

Such bitte mal mit der Suchmaschine Deiner Wahl nach "0x0eedfade-Exception". Es gibt da so etliches, was für Dich letztlich relevant ist, kann ich nicht sagern. Es scheint aber alles (mehr oder weniger) mit dem Debuggen zusammenzuhängen.

Eine eher mutige Schlussfolgerung meinerseits:

Auf dem Windows-2019-Server ist der Just-In-Time-Debugger aktiv. Der bekommt die Exception mit, kann damit nix anfangen und killt Dein Programm.

Auf Windows 10 und 11 ist der Just-In-Time-Debugger nicht aktiv, deshalb muss sich Dein Programm selbst um die Fehlerbehandlung kümmern, was halt eben funktioniert.

Warum diese "steile" These? Es könnte (eine ggfls. auch fehlerhafte) Schlussfolgerung aus diesem Thread sein: Create 0x0eedfade exception in test project

Wie der Just-In-Time-Debugger zu deaktivieren ist, kannst Du eventuell diesem Artikel Debuggen mit dem Just-In-Time-Debugger in Visual Studio entnehmen.

Keine Ahnung, vielleicht hilft es ja den Grund für die zwei unterschiedlichen Verhaltensweisen einzugrenzen.

[himitsu]

0x0eedfade ist einfach nur der generische Code für eine Delphi-Exception, im Exceptions-Record des Systems/Windows.

Was für ein Exception-Nachfahre es dann ist und welche Message sie hat, das kann Windows nicht wissen.
Es ist einfach nur irgendein Fehlercode, eines ihm unbekannten Programms und es weiß nicht wie es die Parameter des Records auswerten, sicht zum Exception-Objekt druchhangeln und daraus die Infos bekommen kann.





Konnte man nicht auch irgendwie den Delphi-Debugger im Windows registrieren?

[Delphi.Narium]

Zitat von himitsu:

0x0eedfade ist einfach nur der Code für eine Delphi-Exception, im Exceptions-Record des Systems/Windows.

Was für ein Exception-Nachfahre es dann ist und welche Message sie hat, das kann Windows nicht wissen.

Und deshalb killt der Just-In-Time-Debugger (vermutlich) das Programm.

[Jelen]

@Delphi.Narium:
An dem JIT-Debugging liegt es wohl auch nicht. Mein Win 2019 Server Testsystem ist neu aufgesetzt und hat außer meiner Anwendung und einer MySQL Datenbank noch nicht viel gesehen. Die Registry- und .config-Einträge für jitDebugging gibt es darauf nicht, deshalb gehe ich davon aus, dass so etwas nicht aktiv ist.
Ich bin weiter auf der Suche und für jede Anregung dankbar !

[Kas Ob.]

Zitat von Jelen:

Hallo,
Wenn in einer der Laufzeitbibliotheken eine Exception auftritt und das Programm unter Windows 2019 Server läuft, verabschiedet es sich kommentarlos und hinterlässt nur den nichtssagenden 0x0eedfade-Exception Code im Event Viewer.
Unter Windows 11 und Windows 10 verhält es sich erwartungskonform, zeigt die Exception an und läuft weiter.
Exceptions in der EXE des Programms werden auch unter Win 2019 Server angezeigt.

Why not to fix the exception in Windows 10 and 11 ? this will remove the Server 2019 exception for good.

Now to my 2 cents, 0x0eedfade is generic and almost useless in this case, the only advantage of having it, is the exception generated by Delphi code, this is great to follow.
There many reason for the application to disappear, but to my experience i can point the two most popular reasons for this:
1) The stack is corrupted beyond usage for the system or to be exact to the system debugger to unwind after a raised exception.
2) the stack is there but while unwinding the system debugger find it pointing to a critical section in memory like somewhere where it should not be pointing to, here the system will see this as malicious code and will terminate the application, it will refuse to unwind beyond that point, many malicious code use the stack to attack the system.

My suggestion to catch and solve this:
1) Make sure you building your application with Stack frames enabled in code generation, this will build better stack header to unwind.
2) Enable Range checking and Overflow checking, to help detecting buffers overflow on the stack.

both steps will help you find it, while (2) might be very annoying for you if you never build with them enabled and your code missing hundreds of these exception, but you really should fix them or at least handle them right, also check for warnings.

My diagnose for the cause of the stack corruption is that your application is either:
1) there is an un-initialized variable on the stack, while it is harder to cause such fuss with Delphi because it does use the heap, it you might have local record with missed to fill/initialize elements or assumed zero content, this might worked for Windows 10,11 but on Server 2019 the stack was already have different values, or you are using inline variables and they are overflowing.
2) There is a unreferenced pointer, aka miss use a pointer, you are writing to it, may be most the times small amount and it does work, but some times with big writes it does overflow and remove an SEH structure frmo the stack or the worse case it does fill it with carbage addresses.

Hope that helps and good luck.

[Kas Ob.]

Off-topic question:

I am new here and might be missing something, I posted to this thread "Wie Speicher ich den Schlüssel für verschlüsselte Datenbanken oder Dateien" two days ago, in fact tried few times and every time there was fast page redirection to with some text that my post should be approved by an administrator, tries also yesterday and it just doesn't go, now my post here above went from the first time.
Why this is happening?


ps: I am refraining from adding links because this is what i am suspecting the cause of such ban, but even when i tried to post without links, same message kept appearing.

[Jelen]

Hi Kas Ob,
welcome to Delphi-Praxis and thanks for your answer!
Regarding your off-topic question, I don't know, never had problems like that, maybe someone else might answer that.
Let me tell you a bit about my intension in that thread.
My App is still "under construction" and shurely, I intend to avoid exceptions. But, in this early phase of development you can't avoid them, since there's always still something wrong with the code.
I'm testing my App on Win 10, 11 and 2019 server. The server system is the one where the final App should be running, but my IDE is on Win 11.
The whole thing started with a simple error, the server system was set to region "US" and my development system is region "germany". This caused a StrToFloat call to throw an exception on converting a string like "1,5". Usually this is really easy to fix, but it turned into a skill issue since the App disappeared without any trace except the useless exit code. Without debugger on the server system it took me quite a long time to figure out what happened.
Once I got this fixed, I wondered why this simple error caused the whole App to crash that way. I build in a simple raise statement in one of my BPL and saw the same behavior: On Win 10 and 11 the exception was shown, on 2019 server the App crashed. Further on I tried to catch the exception, but try ... raise ... except worked fine on win 10 and 11, but on 2019 server the App still crashed. It looks to me like my code doesn't see the exception at all, it rushes straight to the system causing it to kill my App. This happens only with exceptions in the BPLs, exceptions in the exe are shown also on win 2019 server.
I experimented also with safecall (no effect) and using an installer for my App on the server to tell him which libraries belong to my App (also no effect).
Meanwhile, to continue with development (I'm running out of time), I'm linking the App without BPLs (70 MB exe).
By the way, all the research on this issue lead me to madExcept - that's really a great help for developers since the bug report for every uncaught exception gives you a complete call stack with procedure names and even line numbers of your source code. Unfortunately even madExcept doesn't see the exceptions in my BPLs on win 2019 server.
I will reflect your idea with the corrupted stack. Maybe there's something wrong with my BPLs and the server system is more sensitive for this special misbehavior. If I find something I will surely post it here.
But I really appreciate any further ideas for this!

[Uwe Raabe]

Zitat von Kas Ob.:

my post should be approved by an administrator

We have had some problems with spam recently, so new users are currently treated with suspicion. It's not something personal.