Advertisement

MiniDumpWriteDump gives useless callstack for offendig thread

Started by March 05, 2022 08:38 PM
2 comments, last by tanzanite7 2 years, 9 months ago

Trying to add minidump capabilities and for testing i trigger it with __debugbreak through SetUnhandledExceptionFilter (running the program on its own outside IDE as it would mess things up). Running debug build with optimizations disabled.

All other threads have full callstacks, but the thread (main) that triggered the unhandled exception shows only the frame/line where the __debugbreak is - nothing else shows up. Nothing.

// main thread code path
...
SetUnhandledExceptionFilter(...)
...
// first lines in offending function (has "this" pointer)
static int bar = 1; // value is reported to be 1 - which is wrong (see next line)
int foo = ++bar; // foo is inaccessible "unable to read memory"
// also, "this" does not show up (does for all the other threads that happen to have it)
// it just shows a greyed out "this" remnant from what i saw in other threads (instead of just removing it as thous have no relevance in this thread)
__breakpoint(); // line being marked via minidump (exception is listed also as breakpoint)
LOG(... using "foo" value)
// unhandled exception handler code path: unhandledException(EXCEPTION_POINTERS *ep)
HANDLE process = GetCurrentProcess();
DWORD processId = GetProcessId(process);
MINIDUMP_EXCEPTION_INFORMATION mei;
mei.ThreadId = GetCurrentThreadId();
mei.ExceptionPointers = ep;
mei.ClientPointers = TRUE; // tried FALSE too as the documentation is foggy - makes no difference
HANDLE fh = CreateFileW(LOG_DUMP_FN, FILE_WRITE_DATA, FILE_SHARE_READ, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
MINIDUMP_TYPE dumpType = (MINIDUMP_TYPE)( MiniDumpNormal | MiniDumpWithIndirectlyReferencedMemory );
MiniDumpWriteDump(process, processId, fh, dumpType, &mei, NULL, NULL);
CloseHandle(fh);

The dump file is right next to the matching PDB files.

I am at my wits end. How does one make this actually work and not be completely and utterly useless?

Maybe your crash is due in part to stack corruption? Blowing through an array on the stack can do it, as can stale pointers to objects on the stack.

Advertisement

No, there is no corruption. It is a well tested app with just the mentioned lines added (have also tried different debugbreak injection points, some extremely early in the apps lifetime, with exact same results).

Also, your opening sentence: what "crash" are you talking about? What you say does not make much sense to me - are you sure you did read the OP?

This topic is closed to new replies.

Advertisement