Re: Function names for managed callstack under SOS debugging of .NET 2.0 app

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

If I set the "Image File Path..." in file menu to the
MiniDumpWithClrInfoTest.exe folder, the method name appears ok now. I
recommend you give this a try.

Regarding MiniDumpWithCodeSegs, I think it will include all code and
code-related sections from loaded modules to capture executable content,
so
it will eliminate debugger's need for searching Image File Path. However,
as you can see, it has the disadvantage of large dump file size.

Thanks!

After some experiments, and trying ngen on the application itself on a
different machine, it seems that I can indeed use MiniDumpNormal (with a
later dbghelp.dll) in the MiniDumpWriteDump call and get .NET function names
on the call stack if I explicitly set the "Image File Path..." (and reload)
to include the path where I have the EXE! Thanks! I even went back to some
older dumps where !pe and !clrstack had given us the !Unknown entries, and
tried setting the image file path for those, and it worked. Great.

We have a build machine that does our builds, and keeps the EXE, DLL and PDB
files, etc. for every build so that we can analyze crash dumps we get on any
build. We usually just copy all these files for a given build to a local
directory on a developer's machine, then open the .dmp file that was created
on a customer's machine. This has always let us get the images and symbol
files hooked up together well for at least native post-mortem debugging. (In
addition to setting up the symbol server for all MS images).

I'm guessing that with native code, it treats the directory that you're
opening the dump file from as part of the "image file path", but it looks
like SOS needs that extra push to be told specifically the directories to
include in the image file path.

Thanks!
-Daniel


.