Feature request: Callback on crash to log extra information.

[daid]

First off, THANKS. DrMingw and especially the "exchndl" part that you can link to your application is a great help.

I was wondering if it's possible to add the functionality to get a callback when an a fatal exception happens, and then allow the application to log some additional information. I know there is the added risk of that code throwing an exception again, not sure what would happen then.

(I have the case where a crash happens inside some of my UI handling code, and I know the type of UI control that is clicked that is causing the crash, but due to the use of function pointers the exact control is hard to trace down. If I could log the mouse position on exception, which is accessible trough a global variable in my code then I would know where the user had clicked. Which is of great assistance in finding the offending code)

I wouldn't mind building&contributing this feature. But I'm not a 100% sure where to start and if you would like this feature as well.

[White-Tiger]

I can't see much against such a feature... it's as easy as a global variable that holds the possible callback, which gets fired before the exception is handled if it isn't NULL and an exported function that allows to set it up.

I thought about suggesting it myself, so I could manually print an "program caught an exception, generating stack trace...." to the console when the program crashes (and the user is thus informed) but I didn't because such an output is better to be build into Dr. MinGW itself... (to reduce the overall binary size since the presence of exchndl is optional in my case, so less code to set it up is always better)

The hard part is the question what such a callback should receive.. eg. nothing or actual crash information...

[jrfonseca]

I rather not maintain a complicated interface around ExcHndl.

What I could consider is exposing what's currently under src/common to 3rd parties, as a debug engine (similar to https://msdn.microsoft.com/en-us/library/bb145126.aspx ).

If you look at https://github.com/jrfonseca/drmingw/blob/master/src/exchndl/exchndl.cpp you'll see that ExcHndl is nothing but a thin veil around the engine the code in src/common. This is why I see little merit building a complex interface for ExcHndl.

Of course, src/common.cpp is not ready for 3rd party. Step 0 would be clean the interface to be concise and generic, and step 1 would be to expose it as a DLL instead of static library.

[Robyt3]

We'd also really like this feature for our project. We use ExcHndl to write crash dumps, but it would be very helpful, if we could include more information in the crash dumps like system/hardware information. We are currently limited by how much information we can put into the file name of the crash dump.

I propose the following additions to the ExcHndl interface (names subject to change):

EXTERN_C VOID APIENTRY
ExcHndlSetLogExtraDataA(const char *pszLogExtraData);
EXTERN_C VOID APIENTRY
ExcHndlSetLogExtraDataW(const WCHAR *pszLogExtraData);

This function (available as ANSI and Unicode variant) would simply set a string that will be additionally written at the end of crash dumps. This string can also contain line breaks. This would avoid issues introduced by using a function pointer like originally proposed. I think overall this is still a simple enough interface and a useful addition to ExcHndl as an embeddable exception handler.

I would write the implementation if you accept this feature.