Exception in Laufzeitbibliothek einfangen unter Win 2019 server

[Kas Ob.]

Zitat:

Zitat von Jelen (Beitrag 1526486)

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 use EurekaLog and not really familiar with madExcept, both i think should do the job fine, both tools are like old habit, hard to die or change.

Now to the hardcore part:
Among developers there is slight lack of knowledge on how exception works, how the OS handle this, how your code should behave, in this case the compiler does most of the job by installing the SEH in specific OS works, and you know what, most developer doesn't need that much deep understanding, a simple or simplified version will help a lot, i am not pretending to know-all-man, neither i will go in great detail here but will try to explain in very simple way how your application might be behaving.

there is few sorts of exception, hardware triggered or software intentionally triggered, the place where did they triggered also play a great role, like did the exception raised by hardware (like accessing protected page) in virtual mode or protected mode ?!
Protected mode where the kernel reside, virtual mode is where the user application and most of the OS reside.

in both cases the System behavior will be different, if accessed protected page triggering AV on hardware level, the kernel debugger in protected mode will intervene and take handle of it, it will decide how, what, and from where, if it is from virtual mode like you application it go a head and classify it, few examples, is it writing to a write protected page ?, is it reading from un allocated virtual address ?, is it accessing a protected page with specific address!!!!, in this case it might be accessing the last protection page in a stack, here OS will rename the exception to stack overflow !... and so on many many example and they are irrelevant for us now.

On side note: not every access to protected page will trigger user mode exception(like accessing the pages protecting the stack) the protected mode will check if there is another pages in the stack, if there is then it will adjust the stack with lower protected pages as page triggered the exception in first place will automatically changed to read/write and no exception will be raised, the protected mode will trigger the CPU to execute the last assembly instruction that trigger the hardware exception in first place and this will continue like nothing happen, meaning you application will not know it did tripped a hardware exception, and you only can get to know such thing did happen by watching the soft Page Fault.

Along this process in the protected mode the kernel debugger will check few context of this exception, and then will forward it to.. (long story).. until it reach the virtual mode and if there is a debugger then it will be triggered, if not then the OS in user mode still have a debugger, that will forward it to your application in case there is SEH trap,..
Here the except part in an application will receive the execution from the same thread that triggered the exception, but to find the according SEH, it will start with a process called stack unwinding, in very simplified words (half wrong) it will search(just go back) the stack for the last valid SEH, from there it will grab an address which in Delphi case will be pointing to the except part/clause in try..except..end

so after all of the above, what might be went wrong with that exception ?, can't be sure 100% but for me it sounds like the two options i wrote in the last post, the stack either corrupted and the system couldn't find a valid SEH, or through the unwinding process it find an address that marked as dangerous and decided to stop the process.

Windows have zero tolerance with many exception, like, try to start a background thread with CreateThread API and raise an exception without catching it!, the application should be gone.

My example about threads also might be a cause for your problem.


Hope that give you some insight to solve your problem.

[Kas Ob.]

Zitat:

Zitat von Uwe Raabe (Beitrag 1526489)

Zitat:

Zitat von Kas Ob. (Beitrag 1526482)

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.

Personal never came my mind, but again my long post is stopped.

[Kas Ob.]

I am getting this, see the attachment when i post the other attachment

Hope they are readable.

[Uwe Raabe]

That looks like a similar post has been done before which may still wait for approval.

[Jelen]

Hello Kas Ob,
thanks for your tutorial regarding exception handling. By now I'm shure you're right, there's something wrong with my BPLs. I created an empty test project of the same structure (EXE and 2 BPLs). This is running fine and on win 2019 server it shows the correct exception handling, uncaught exceptions are shown as a message and the app continues, no crash. Even madExcept works fine within that.
I still wonder why I don't get the same error on win 10 and 11, but anyway, it's up to me to figure out what I did wrong within my crashing BPLs.

[Kas Ob.]

Zitat:

Zitat von Jelen (Beitrag 1526745)

I still wonder why I don't get the same error on win 10 and 11, but anyway

Are you sure that the EXE and BPL's compiled with Stack Frames ?

Also, I think it might shed some light if you capture and record or simply show the result of GetLastError in the error message.

[TUhr]

Mich würde mal interessieren ob die Software unter 2019 läuft, wenn Du die Datenausführungsverhinderung für dieses Programm deaktivierst.....

[Jelen]

Hallo TUhr,
was meinst du mit "Datenausführungsverhinderung"?
Das Programm an sich läuft ja weitgehend problemlos. Es ist aber noch in Entwicklung und problematisch für mich wird es erst, wenn auf dem Win 2019 Server System eine bislang nicht berücksichtigte Situation eintritt, die zu einer Exception in einer der BPLs führt. Dann ist das Programm einfach futsch und ich darf raten, was da passiert ist. Derzeit verzichte ich halt auf die Laufzeit-BPLs, um dieses Problem zu umgehen.
Immerhin ist ja inzwischen klar, dass es an irgendeinem strukturellen Problem in meinen BPLs liegt, denn bei einem leeren Testprojekt gab es ja auch keine Probleme.

[himitsu]

lmdmfdg Datenausfuehrungsverhinderung :wink:

https://support.microsoft.com/de-de/...8-512419135817
https://www.dell.com/support/kbdoc/d...rhinderung-dep

[Jelen]

Oups, dieses Unwort kam mir so komisch vor, dass ich nicht mal auf die Idee gekommen bin, danach zu googeln ... Asche auf mein Haupt :oops:.
Wenn ich DEP deaktiviere, hat das keinen Einfluss, dass Programm wird weiterhin bei Exceptions gekillt.
:idea: Aber: Wenn ich SEHOP deaktiviere (validate exception chains), dann ist das Problem weg. Das stützt die Vermutung von Kas Ob.
Ist aber letztlich auch keine Lösung, denn der Kunde wird wohl kaum die Sicherheitseinstellungen auf seinem Server reduzieren wollen.
Was ich mir nur nach wie vor nicht erklären kann, warum dasselbe Problem nicht auf meinen anderen Testsystemen (Win 10 und 11) auftritt, wo DEP und SEHOP aktiv sind, und unter Win 2019 Server wird meine App bei jeder Art von Exception in den BPLs gekillt.