memorydump in vista

[Dirk Reske]

Hello,

In Windows Vista I can make a memory dump of an application in the
taskmanager.
Is there an api call to create a memory dump, so that I can do that out of
my app?

thanks!

 

[Chris Taylor]

Hi,

Tee DbgHelp.dll exports function that can help you with this, take a look at
MiniDumpWriteDump you can find the online ref at
http://msdn2.microsoft.com/en-us/library/ms680360.aspx.

Hope this helps

 

[Willy Denoyette [MVP]]

Hello,

In Windows Vista I can make a memory dump of an application in the taskmanager.
Is there an api call to create a memory dump, so that I can do that out of my app?

thanks!

No, there is no such API, also, it would make little or no sense to dump your own
application. All you can do is attach a debugger like cdb or windbg to the running process
to produce a dump.

Willy.

 

[Andre Kaufmann]

No, there is no such API, also, it would make little or no sense to dump

IMHO I think it makes sense, at least for native applications. I've
implemented memory dump support in all our applications, written in C++.
As soon as the application crashes it will be written to a predefined
location and sent to us (which by default the error reporting service
would do anyway - but would send it to a Microsoft database.) or if an
application go instable (deadlock etc.) I'm able to write a memory dump
on demand an analyze the problem on my developer machine.

Advantages:

a) Don't need to reproduce a problem on my developer machine
b) I can evaluate bugs much faster, than I would be able to do with

your own application. All you can do is attach a debugger like cdb or
windbg to the running process to produce a dump.

I'm not experienced that much in creating memory dumps for managed
applications (we haven't that much of them yet). AFAIK memory dumps can
be used with manages applications too, but a full dump is needed for
debugging managed applications, though IIRC there are some "hacks
/tricks" so that mini dumps will work too.

Willy.

Andre

 

[Willy Denoyette [MVP]]

IMHO I think it makes sense, at least for native applications. I've implemented memory
dump support in all our applications, written in C++.
As soon as the application crashes it will be written to a predefined location and sent to
us (which by default the error reporting service would do anyway - but would send it to a
Microsoft database.) or if an application go instable (deadlock etc.) I'm able to write a
memory dump on demand an analyze the problem on my developer machine.

Advantages:

a) Don't need to reproduce a problem on my developer machine
b) I can evaluate bugs much faster, than I would be able to do with

Agreed, In case of a crash, that is from an unhandled exception handler, however, I was
talking about simply calling Dbghelp.dll API's from a running process.

I'm not experienced that much in creating memory dumps for managed applications (we
haven't that much of them yet). AFAIK memory dumps can be used with manages applications
too, but a full dump is needed for debugging managed applications, though IIRC there are
some "hacks /tricks" so that mini dumps will work too.

Yep, you can produce Minidumps from managed applications just like you woul do from
unmanaged code, basically what you need to do is register your own "unhandled exception"
filter and call MiniDumpWriteDump from that filter. Of course you need to make sure no one
else (sa a third party component) overwrites your filter, and make sure you redistribute the
dbghelp.dll version that comes with the (preferably) latest version of the debugger tools.
Be aware that, managed code minidumps do not offer most features of the sos.dll debugger
extention, this requires a full dump, which easely contributes in a dumpfile of ~60MB or
more.
Note that,while analysis of a "native code" minidump is just a snap ;-), post-mortem
analysis of a "JITted code" minidump can be a daunting task, even for an expert.


Willy.

 

[Andre Kaufmann]

[...]
Advantages:

a) Don't need to reproduce a problem on my developer machine
b) I can evaluate bugs much faster, than I would be able to do with

Agreed, In case of a crash, that is from an unhandled exception handler,
however, I was talking about simply calling Dbghelp.dll API's from a
running process.

Ok it's not that simple, as in the case of a crash. Though it's possible
to (simplified) "simulate a crash". E.g. John Robbins has written a very
good book about crash dumps and how to create them.

But I agree - in pure C# code it's not possible - don't know if Vista
supports a simple function for dump file creation.

The other simple solution would be to force a crash. Unfortunately this
can be done only once ;-9.

[...]

Note that,while analysis of a "native code" minidump is just a snap ;-),
post-mortem analysis of a "JITted code" minidump can be a daunting task,
even for an expert.

Agreed. I haven't tested it by myself (yet), but it surely isn't that
simple to evaluate managed crash dumps. To debug deadlocks it should be
also sufficient to dump the call stacks of all running managed threads.

Willy.

Andre

 

[Willy Denoyette [MVP]]

[...]
Advantages:

a) Don't need to reproduce a problem on my developer machine
b) I can evaluate bugs much faster, than I would be able to do with

Agreed, In case of a crash, that is from an unhandled exception handler, however, I was
talking about simply calling Dbghelp.dll API's from a running process.

Ok it's not that simple, as in the case of a crash. Though it's possible to (simplified)
"simulate a crash". E.g. John Robbins has written a very good book about crash dumps and
how to create them.

Yep, I have it on my desk ;-)

But I agree - in pure C# code it's not possible - don't know if Vista supports a simple
function for dump file creation.

Not that I know of, the latest dbghelp is what I'm using.

The other simple solution would be to force a crash. Unfortunately this can be done only
once ;-9.

[...]

Note that,while analysis of a "native code" minidump is just a snap ;-), post-mortem
analysis of a "JITted code" minidump can be a daunting task, even for an expert.

Agreed. I haven't tested it by myself (yet), but it surely isn't that simple to evaluate
managed crash dumps. To debug deadlocks it should be also sufficient to dump the call
stacks of all running managed threads.

Don't you mean "all running threads"? You can't distinct managed from unmanaged threads as
there is no difference at this level.
I've done some post-mortem analysis using dbghelp, and found out that you need at least the
following MINIDUMP_TYPE
MiniDumpWithDataSegs, & MiniDumpWithPrivateReadWriteMemory , to be able to get somewhere
with SOS.DLL. "Managed" threads only exist (though, they map to OS threads) at the CLR level
and therefore you need the SOS extentions if you need to analyse "managed threads" and other
CLR related datastructures.
Willy.

 

[Andre Kaufmann]

Agreed. I haven't tested it by myself (yet), but it surely isn't that
simple to evaluate managed crash dumps. To debug deadlocks it should
be also sufficient to dump the call stacks of all running managed
threads.

Don't you mean "all running threads"? You can't distinct managed from
unmanaged threads as there is no difference at this level.
[...]

I thought that call stacks (without debugging information) from native
threads wouldn't hold that much information. But there might be also a
native thread calling into managed code, so anyways it would be better
to dump all call stacks, and as you wrote managed ones can't be
distinguished easily from native ones - only perhaps by parsing the call
stack.

Andre