First, I’d like to point out we are happy with MadExcept. I just encountered something, I wonder if madExcept should/could intercept this.

This crash is reproducible (random, odds 1/10) by dragging my application to dock to the screen sides in a Windows 10 VM.

There appears a “QLedText has stopped working” dialog, and the software quits. I believe that this dialog is shown for uncatched exceptions, but madExcept was not triggered.

In the Windows event log, I see that the cause is related to “uxtheme.dll” which apparently is used by my Delphi 2010 application. I attached event log details in a post below.Is this something that madExcept should or could intercept?

And if anyone else had their Delphi application crash on uxtheme.dll .. insights welcome!

Last edited by BarryStaes on Tue Oct 27, 2015 10:26 am, edited 2 times in total.

madExcept by default does not care about handled exceptions. It does care about unhandled exceptions, of course. But what is really the difference between "handled" and "unhandled"? The way madExcept works is by hooking some RTL functions to be able to catch exceptions before they end up in the RTL default handler for unhandled exceptions. Furthermore, madExcept hooks into newly created threads so that it can catch exceptions which are not handled by the thread function itself.

madExcept doesn't seem to be handling this specific uxtheme.dll crash can have multiple reasons. Let me list by probability:

1) Could be that this crash neither ended up in any RTL exception handling related function, nor in any of madExcept's thread function wrappers, for some reason. One possible reason would be that there's some code somewhere, e.g. in uxtheme.dll, which catches exceptions and then directly passes them to the OS exception handler. Another possible reason would be that the crash occurred in a thread which wasn't protected by madExcept's thread function wrapper. This could happen if the thread was created before madExcept was initialized. Or if the thread was created in a way that madExcept's CreateThread() API hook didn't catch.

2) Could be a bug in madExcept of some kind.

3) Could be the process being in such a bad state that madExcept maybe caught the exception, but failed to do its work properly.

You could try calling madExcept.InstallUnhandledExceptionFilter() in your initialization. Does that make a difference? Or alternatively you could call madExcept.RegisterHiddenExceptionHandler() and in your handler set "handled := false" to force madExcept to take care even of properly handled exceptions. I'm not sure if either of these ideas will help, though.

Reason 1 seems probable, if only because the uxtheme.dll seems to be a part of Windows so its very possibly loaded before my application.I'll try your suggestions, and i'll post insights on resolving this here if only for posterity / others having such a problem.