I'm trying to use code similar to clrdump to create mini dumps in my managed process.
This managed process invokes C++/CLI code which invokes some native C++ static lib code, wherein SEH exceptions may be thrown (e.g. the occasional access violation).
C# WinForms
->
C++/CLI DLL
->
Static C++ Lib
->
ACCESS VIOLATION
Our policy is to produce mini dumps for all SEH exceptions (caught & uncaught) and then translate them to C++ exceptions to be handled by application code. This works for purely native processes just fine; but when the application is a C# application - not so much.
The only way I see to produce dumps from SEH exceptions in a C# process is to not catch them - and then, as unhandled exceptions, use the Application.ThreadException
handler to create a mini dump. The alternative is to let the CLR translate the SEH exception into a .Net exception and catch it (e.g. System.AccessViolationException
) - but that would mean 开发者_高级运维no dump is created, and information is lost (stack trace information in Exception
isn't as rich as the mini dump).
So how can I handle SEH exceptions by both creating a minidump and translating the exception into a .Net exception so that my application may try to recover?
Edit
By "not catching exceptions" I also mean catching and then rethrowing, which does preserve the rich exception information.
Right now I'm considering never supressing System.Exception
or anything deriving from System.SystemException
. This means AccessViolation
(and friends) always cause the program to end and produce a dump, and all other exceptions thrown need to derive from some sub-type (ApplicationException
?).
I found that with Vectored Exception Handling I can get a first-chance notification of any SEH exception and use this occasion to produce a mini dump.
精彩评论