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.