4

I have a C# application that calls a mixed mode C++ dll. I enabled dump generation via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps.

When the dll accesses invalid memory, the runtime converts the win32 exception to a managed System.AccessViolationException, and unwinds the stack before generating the dump, destroying the native stack information. I could catch the exception myself before .net gets at it and generate the dump manually, but running code on an already corrupt program could hang it, according to the msdn. So, how can I disable SEH translation?

Bruno Martinez
  • 2,850
  • 2
  • 39
  • 47

1 Answers1

1

You cannot disable that. The CLR will not unwind the stack unless you catch the exception. Make sure you don't. This needs to go through an AppDomain.UnhandledException event handler. The essential function you need is Marshal.GetExceptionPointers(), that's the one that will pinpoint the exception when you open the minidump.

You'll find resources in my answer in this MSDN forum thread and this pinvoke.net snippet, should be enough to cobble your own together.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you for the answer, but AppDomain.UnhandledException has the same problem as catching the exception before returning to managed code: the process is corrupt and trying to generate the dump within the process itself may hang. – Bruno Martinez Mar 21 '13 at 18:47
  • Sure, that's quite possible. The process state can be so corrupted that continuing to run code isn't possible anymore. A crash due to a corrupted process heap does this for example, it leaves the heap locked. You'll need another weapon for that, generating the minidump with another process. Either by hand from Taskmgr.exe or with a utility like [SysInternals' ProcDump](http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx) – Hans Passant Mar 21 '13 at 19:18
  • 1
    Windows Error Reporting is already configured to generate the dump externally. The problem is that it generates the dump when an exception is not handled, but .Net handles it and destroys the context. AFAIK, ProcDump also suffers from this problem. – Bruno Martinez Mar 22 '13 at 18:55