Question

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?).

Answer 1

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.