Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MiniDumpWriteDump context problem

0 views
Skip to first unread message

Jonathan Arnold

unread,
Oct 9, 2004, 3:19:19 PM10/9/04
to
I'm looking into creating a crash dump capturer, and I'm having
a problem with the MiniDumpWriteDump API from DbgHelp.dll.

I've looked at all kinds of pages:


1] http://www.winwonk.com/writing/minidump/
2] http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
3] http://msdn.com/msdnmag/issues/02/06/Bugslayer/
4] http://msdn.com/msdnmag/issues/02/03/hood/

I have it working in my own exception handler, and I've tried
John Robbins' Bugslayer [3] but it still doesn't work the way I want
it to.

The problem is that inside an exception handler, as set like this:

::SetUnhandledExceptionFilter( IGExceptionHandler );

and defined like this:

LONG IGDebug::IGExceptionHandler( struct _EXCEPTION_POINTERS *pExceptionInfo )
{
...
}

if I call MiniDumpWriteDump from the exeception handler, I get the call stack
for the exception handler, *not* where the exception happened.

I looked at Matt Pietrek's WheatyExceptionReport [4], but it requires
the PDB file to be around when it is called - not something we're going
to ship to customers. It does, however, do what I think I need to do
with the MiniDump function - set the stack frame to be the one found in
pExceptionInfo, and not to use the current one from the exception handler.

Dr. Watson does it correctly, so I should be able to as well, right? How
can I set the context for the MiniDump?

--
Jonathan Arnold
inSORS

Kim Gräsman

unread,
Oct 10, 2004, 5:39:21 AM10/10/04
to
Hi Jonathan,

> if I call MiniDumpWriteDump from the exeception handler, I get the call stack
> for the exception handler, *not* where the exception happened.

I don't know the exact answer to your question, but I haven't had any problems myself...

Do you populate the MINIDUMP_EXCEPTION_INFORMATION properly?

What does your call to MiniDumpWriteDump look like?

--
Best regards,
Kim Gräsman

Jonathan Arnold

unread,
Oct 11, 2004, 8:28:06 AM10/11/04
to
Kim Gräsman wrote:
>>if I call MiniDumpWriteDump from the exeception handler, I get the call stack
>>for the exception handler, *not* where the exception happened.
>
> I don't know the exact answer to your question, but I haven't had any problems myself...
>
> Do you populate the MINIDUMP_EXCEPTION_INFORMATION properly?
>
> What does your call to MiniDumpWriteDump look like?

Thanks for the reply. Here's my structured exception handler code, strip
to its bare essentials:

LONG IGDebug::IGExceptionHandler( struct _EXCEPTION_POINTERS *pExceptionInfo )
{

LONG retval = EXCEPTION_CONTINUE_SEARCH;
HWND hParent = NULL; // find a better value for your app

// firstly see if dbghelp.dll is around and has the function we need
// look next to the EXE first, as the one in System32 might be old
// (e.g. Windows 2000)
HMODULE hDll = NULL;
std::string appPath;

GetMyFolder( appPath );

appPath += "\\DBGHELP.DLL";
hDll = ::LoadLibrary( appPath.c_str() );

MINIDUMPWRITEDUMP pDump = (MINIDUMPWRITEDUMP)::GetProcAddress( hDll, "MiniDumpWriteDump" );

char szDumpPath[_MAX_PATH];

// work out a good place for the dump file
if (!GetTempPath( _MAX_PATH, szDumpPath ))
_tcscpy( szDumpPath, "c:\\temp\\" );

_tcscat( szDumpPath, appName_ );
_tcscat( szDumpPath, ".dmp" );

HANDLE hFile = ::CreateFile( szDumpPath, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, NULL );

_MINIDUMP_EXCEPTION_INFORMATION ExInfo;
ExInfo.ThreadId = ::GetCurrentThreadId();
ExInfo.ExceptionPointers = pExceptionInfo;
ExInfo.ClientPointers = FALSE;

// write the dump
BOOL bOK = pDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, MiniDumpNormal, &ExInfo, NULL, NULL );
::CloseHandle(hFile);

return retval;
}

The only thing I'm a little unsure on is the value of ClientPointers. I've
tried both TRUE and FALSE, and neither seems to make any difference. The
dump file generated has a stack starting in the exception handler and going
up to the CRT, and not where the exception happened.

--
Jonathan Arnold
inSORS

Ivan Brugiolo [MSFT]

unread,
Oct 11, 2004, 11:24:44 AM10/11/04
to
That is expected.
The stack trace of the location can be gotten from
the debugger via the .ecxr / .cxr commands.
As far as using the MiniDumpWriteDump on your own,
I would recomend levereging faultrep!ReportFault
and the built-in error reporting mechanism.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Jonathan Arnold" <jdarnold_online@insors_comm.com> wrote in message
news:#F8pD34r...@TK2MSFTNGP12.phx.gbl...

Jonathan Arnold

unread,
Oct 11, 2004, 11:28:54 AM10/11/04
to
Ivan Brugiolo [MSFT] wrote:
> That is expected.
> The stack trace of the location can be gotten from
> the debugger via the .ecxr / .cxr commands.

Yup - just moments ago I found this magical .ecxr command! Works
like a charm.

> As far as using the MiniDumpWriteDump on your own,
> I would recomend levereging faultrep!ReportFault
> and the built-in error reporting mechanism.

I'm not sure what you mean by "faultrep!ReportFault", and the built-in
error reporting mechanism. Do you mean the Windows Error Reporting
stuff?

--
Jonathan Arnold
inSORS

Rhett Gong [MSFT]

unread,
Oct 12, 2004, 2:47:36 AM10/12/04
to
I think Ivan means the ReportFault api in ErrorRep.h. It allows an
application that performs its own exception handling to report faults to
Microsoft.
ReportFault can be found at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/
reportfault.asp

Best regards,
Rhett Gong [MSFT]
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

Please reply to newsgroups only. Thanks.

0 new messages