Creating minidump for access violation exception using SetUnhandledExceptionFilter()

Question

I am using the following code to create a minidump file whenever there is a structured exception generated from my code:

void CreateMiniDump( EXCEPTION_POINTERS* pep ) 
{
  // Open the file 
typedef BOOL (*PDUMPFN)( 
  HANDLE hProcess, 
  DWORD ProcessId, 
  HANDLE hFile, 
  MINIDUMP_TYPE DumpType, 
  PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam, 
  PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam, 
  PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);


    HANDLE hFile = CreateFile( _T("C:/temp/MiniDump.dmp"), GENERIC_READ | GENERIC_WRITE, 
    0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL ); 

    HMODULE h = ::LoadLibrary(L"DbgHelp.dll");
    PDUMPFN pFn = (PDUMPFN)GetProcAddress(h, "MiniDumpWriteDump");

  if( ( hFile != NULL ) && ( hFile != INVALID_HANDLE_VALUE ) ) 
  {
    // Create the minidump 

    MINIDUMP_EXCEPTION_INFORMATION mdei; 

    mdei.ThreadId           = GetCurrentThreadId(); 
    mdei.ExceptionPointers  = pep; 
    mdei.ClientPointers     = TRUE; 

    MINIDUMP_TYPE mdt       = MiniDumpNormal; 

    BOOL rv = (*pFn)( GetCurrentProcess(), GetCurrentProcessId(), 
      hFile, mdt, (pep != 0) ? &mdei : 0, 0, 0 ); 



    // Close the file 

    CloseHandle( hFile ); 

  }

}

LONG WINAPI MyUnhandledExceptionFilter(
 struct _EXCEPTION_POINTERS *ExceptionInfo
)
 {
     CreateMiniDump(ExceptionInfo);
     return EXCEPTION_EXECUTE_HANDLER;
 }

And I am doing SetUnhandledExceptionFilter(MyUnhandledExceptionFilter); from the main entry point of my app ( I am not setting it for each thread though). After this to test this code I did the following to generate an access violation: int* p = 0; *p = 0; The dump file did get generated. Then I used windbg and opened the dump file and used .ecxr command to get the exception record. However, no information is coming there (i.e. I am not getting the call stack). Also if I use !analyze -v command then it is able to show the line where the crash occured. Does anybody know what I am missing and how to solve this?

BTW, I am using VC7 compiler with /EHa (asynchronuos exception model) flag.

I don't have an answer for you, but I'm not entirely sure that `mdei.ClientPointers` should really be `TRUE` — Hasturkun, Jan 31 '11 at 10:07
Be aware, that handlers installed using SetUnhandledExceptionFilter(), by my experience will not be called in all cases. I.e. crashes in windows kernel Dlls (which obviously occur sometimes) can only be reported using Windows Error Reporting. See my article "Post Mortem Debuugging revisited" on DDJ http://www.drdobbs.com/architecture-and-design/227900186 — RED SOFT ADAIR, Jan 31 '11 at 10:14
The function pointer declaration is wrong, it is missing WINAPI. — Hans Passant, Aug 12 '12 at 16:28
Also, don't forget to add stdcall: typedef BOOL (__stdcall *PDUMPFN) ( — egorFiNE, Feb 27 '13 at 19:21
A word of warning: Writing a mini dump absolutely must be performed out-of-process. One of the first things `MiniDumpWriteDump` does is to suspend all threads. If any of those threads holds a lock on a global resource that `MiniDumpWriteDump` requires later on (like the heap access mutex), you have an instant deadlock. Now you have two problems: In that case you are left with a deadlock an no dump file at all. — IInspectable, Jun 23 '17 at 07:59

score 3 · Answer 1 · answered Jan 31 '11 at 12:00

3

Your code creating minidump is OK, the problem is post-mortem debugging. Debugger must have access to the program source code, .pdb files (which should be pdb files created when this program executable was built), and OS debugging symbols. Only having all this information, debugger can show exception place in the source code and call stack.

Post-mortem debugging process using Visual Studio debugger is described in details here: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx For WinDbg, use Symbol, Source and Image file path to provide the same information for debugger.

answered Jan 31 '11 at 12:00

Alex F

42,307
41
144
212

1

Thanks for the answer..pdb files are there. Finally managed to track down the problem, it was caused as one more dll in my app was doing `_set_se_translator` before I could install the unhandled exception filter. If I remove that translator, it works fine. – Naveen Jan 31 '11 at 12:06
Yeah, there is exactly 1 unhandled exception filter, and other modules are free to write over yours - not a very good design – Ana Betts Jan 31 '11 at 16:13

score 3 · Answer 2 · edited May 23 '17 at 12:24

However, no information is coming there (i.e. I am not getting the call stack)

.ecxr isn't supposed to print a callstack, it's just supposed to set the context to that of the stored exception record - you'd want to do something like k 10 to actually print it. Or, since you're using WinDBG, open the callstack window.

(Maybe you're already doing this; I'm not sure from your description how .ecxr is failing - it should print something to let you know what it is / isn't able to do...)

Another thing to check is that you're actually getting exception pointers passed in - the code will generate a dump without them, but you'll get a funky callstack that way.

You mentioned in a comment on Alex's answer having some interference from a DLL overriding your filter with the runtime library's... This is a common problem. I've had good luck using the technique described by Oleg Starodumov:

There is one more approach possible, and it is much easier to implement than the previous two. After we have registered our own filter, we can patch the beginning of SetUnhandledExceptionFilter function so that it will not be able to register filters anymore.

He provides some handy example code for this purpose, which has served me well over the years.

Creating minidump for access violation exception using SetUnhandledExceptionFilter()

2 Answers2

Linked