MiniDumpWriteDump

[edchan]

Hi there,

I've added code to my app to generate a mini dump when an unhandled
exception occurs. I'm using MiniDumpWriteDump() specifying a dump type
of MiniDumpNormal.

I'm able to generate the dump. But when I open up the dump in WinDbg,
the call stack of the thread that crashed doesn't show anything. This
is all it shows:

WARNING: Stack unwind information not available. Following frames may
be wrong.
ntdll!KiFastSystemCallRet
0x150640

All the other threads' call stacks look fine. When I use adplus to
create a full dump, the call stack of the thread that crashed is
perfect. I understand that what I'm generating programmatically is a
"mini" dump as opposed to a "full" dump that is created with adplus,
but how can I also get a proper call stack for the thread that caused
the exception.

My test simply does the following to generate the exception:

int* p = 0;
*p = 1; // de-ref a null ptr to cause an exception

Thanks,
Ed

[Drew Bliss [MSFT]]

Are you calling MiniDumpWriteDump on the same thread that had the unhandled
exception? There isn't a safe way to get the current context for a running
thread, thus the dump will have whatever context it can recover and that may
be stale. Are you providing exception parameters in your call? If so
they'll be captured separately and you make them current with .ecxr, in
which case the thread's current context is irrelevant.

MiniDumpWriteDump does a bunch of things so calling it in a process that has
had an unhandled exception is not very reliable. For example, if the
unhandled exception was due to or was a symptom of heap corruption,
deadlock, out-of-memory or other process-trashing problems it's likely that
MDWD will be affected also. It's best to gather the dump from outside of
the process. The system will do this for you with Windows Error Reporting,
so in many cases it's best not to handle your own exceptions, just let them
go. This is especially true on Windows Vista as WER has been enhanced quite
a bit.

"edchan" <chan....@gmail.com> wrote in message
news:1138917885....@f14g2000cwb.googlegroups.com...

[edchan]

Yes I am calling it from the same thread that had the unhandled
exception. It's basically like this

__try
{
// do something that causes an exception; this could be several
stack frames deep
}
__except(CrashFilter(GetExceptionInformation(), GetExceptionCode()))
{
}

CrashFitler(LPEXCEPTION_POINTERS pException, DWORD dwExceptionCode)
{
MINIDUMP_EXCEPTION_INFORMATION mei;
mei.ThreadId = GetCurrentThreadId();
mei.ExceptionPointers = pException;
mei.ClientPointers = TRUE;

// create a file

MiniDumpWriteDump(GetCurrentProcess(),
GetCurrentProcessId(),
hFile,
MiniDumpNormal,
&mei,
NULL,
NULL);

// do some cleanup such as close file handle, etc.

}

So there's no way to reliably get the call stack up to the point of the
exception? Doesn't seem like this function is of much use then.
ADPlus gives me a very nice looking dump. Is there no way to tap into
whatever it is doing?

Thanks,
Ed

[Skywing]

Create a new process and have that process call MiniDumpWriteDump.

This is by no means guaranteed to work either but if you use CreateProcessW
(avoid the "A" version, extra heap allocations required) you will have many
less failure paths than for calling MiniDumpWriteDump in a crashed process .

"edchan" <chan....@gmail.com> wrote in message

news:1138933560....@o13g2000cwo.googlegroups.com...

[Oleg Starodumov]

> So there's no way to reliably get the call stack up to the point of the
> exception? Doesn't seem like this function is of much use then.
>

You create the dump correctly, and should be able to get the call stack
at the moment of the exception. You should use either one of the following commands:

> !analyze -v
(it will automatically switch to the context stored in the minidump's exception information,
obtain the call stack and report it)

or

> .ecxr
> kb
(.ecxr will switch to the context stored in the minidump's exception information, and then
kb will tell you the call stack)

If something still does not work, please post the output of these commands.

Two other things to remember:
- make sure that symbol path is set correctly
- make sure that the application uses the latest version of dbghelp.dll (6.5.x.x at the moment)
(e.g. copy it to the same directory with the application)

> ADPlus gives me a very nice looking dump. Is there no way to tap into
> whatever it is doing?

ADPlus allows to see the call stack right away because it writes the context
of the offending thread into the minidump exactly at the moment when the exception
was raised (by the nature of Win32 debugging, the debugger receives the proper
context with "exception" debug event).

When MiniDumpWriteDump is called in-process, from the thread that raised the exception,
the context of the thread is not the same as at the moment of the exception (because since
the moment when the exception was raised, the thread had to search for registered exception
filters, find your filter and call it). But if you properly pass exception information to
MiniDumpWriteDump (and you do), it is possible to recover this information in
the debugger, with the help of the abovementioned commands.

Regards,
Oleg
[VC++ MVP http://www.debuginfo.com/]

[Skywing]

You should not call MiniDumpWriteDump from the crashed process, period. I
can tell you from experience that you are very likely to have
MiniDumpWriteDump crash the process again if you are doing so from the
context of an unhandled exception, as Drew Bliss already pointed out.

I've made the mistake of doing this once for a particular service and I
often got usable dumps less than half of the time because MiniDumpWriteDump
would blow up when called in process so often. The (simple!) solution was
to just add a special command line argument to the service executable that
would have it operate in a special "dump mode" and make a minidump of the
process/thread given as command line parameters.

So, please, create a worker process to write your dump. This is the same
model that JIT debugging uses. If you corrupt the process state badly
enough, it is possible that CreateProcess(W) can crash or fail too, but this
is *much* less likely than MiniDumpWriteDump blowing up when called from a
crashed process.

"Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message
news:OLp9U5JK...@TK2MSFTNGP09.phx.gbl...

[edchan]

Thanks for this valuable info. Please forgive me for the dumb
questions since I'm a beginner with these debugging tools. But I'm
slightly familiar with WinDbg. These commands you mention, can I do it
from WinDbg? Or can I only use them with CDB or KD? I don't really
know much about these debuggers. Do I need to use them, or can I just
use WinDbg?

Thanks,
Ed

[Skywing]

You can use those commands from either.

In general, you can think of WinDbg as a superset of (kd, ntsd/cdb) with a
GUI instead of a console. There are a couple obscure things that you would
want to use ntsd/cdb for instead of WinDbg (like controlling a user mode
debugging from kd), but for the most part you can use WinDbg for anything
you would use ntsd/cdb/kd for.

kd is not relevant to you in this case, it only supports live kernel
debugging or kernel crash dump debugging. So you will want to use either
WinDbg, ntsd, or cdb. ntsd and cdb are about the same, the main difference
being that cdb inherits its console and ntsd creates its own. I would
recommend WinDbg as the UI is easier to work with.

To sum it up:

kd = kernel mode debugger
ntsd/cdb = user mode debuggers
WinDbg = kernel or user mode debugger

All three debuggers share much of the core debugging engine so you can often
interchange WinDbg with one of the other debuggers.

"edchan" <chan....@gmail.com> wrote in message

news:1138982520.9...@g49g2000cwa.googlegroups.com...

[Oleg Starodumov]

> You should not call MiniDumpWriteDump from the crashed process, period.
> I can tell you from experience that you are very likely to have MiniDumpWriteDump crash the process again if you are
> doing so from the context of an unhandled exception, as Drew Bliss already pointed out.
>
> I've made the mistake of doing this once for a particular service and I often got usable dumps less than half of the
> time because MiniDumpWriteDump would blow up when called in process so often. The (simple!) solution was to just add
> a special command line argument to the service executable that would have it operate in a special "dump mode" and make
> a minidump of the process/thread given as command line parameters.
>
> So, please, create a worker process to write your dump. This is the same model that JIT debugging uses. If you
> corrupt the process state badly enough, it is possible that CreateProcess(W) can crash or fail too, but this is *much*
> less likely than MiniDumpWriteDump blowing up when called from a crashed process.
>

I agree that out-of-process JIT debugging (including minidump creation) is more reliable than
in-process MiniDumpWriteDump, mostly because MDWD uses the default process heap,
which can be corrupted and thus render MDWD useless. Unfortunately, CreateProcessW
approach is also subject to the same problem, as well as Windows Error Reporting, since they
also use the process heap. So in general I prefer a 'watchdog' approach, where the watchdog
process is always running and waits for a special event (set by the crashed process) to create the dump.

(At the same time, I would not say that in-process MiniDumpWriteDump is that much
useless; it depends on the application and the ways its developers use to corrupt it :)
(in the era of PageHeap, heap corruptions do not happen too often, at least in the applications
I have to work with)

Additional information for the OP:

If out-of-process approach is used to create the dump, you have to invent a way to pass the exception
information from the crashed process to the process that creates the dump. In CreateProcess way, it can
be done via a command line parameter (e.g. pass the address of EXCEPTION_POINTERS structure
and the thread id as parameters to the new process, and change ClientPointers to TRUE).

Alternatively, you can create a minidump without exception information at all,
and (instead of !analyze/.ecxr approach) use the following method to find the exception context:
http://blogs.msdn.com/jmstall/archive/2005/01/18/355697.aspx

Oleg

[Skywing]

Yes, CreateProcessW won't work if the process is corrupted badly enough.

However, in my experience, this is *much* rarer than MiniDumpWriteDump
failing because the process is in a bad state.

"Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message

news:%23LM1nZQ...@TK2MSFTNGP14.phx.gbl...