visual studio .net debugging: Hi,

I'm using Vista 64 bit with visual studio 2005 on a 32 bit debug program
with native C++ dlls and .NET executables dlls using DllImports.

I'm trying to use a minidump of that program. I would like see the call
stack. But I fail to load the symbols files of my .NET dlls. The native dlls
symbols are loaded correctly.

I guess that's why the call stack seems to be correctly displayed in the
native code and not in the managed code.

I already rebuild the project and checked the pdb files are the good ones. I
checked the pdb with chkmatch tool from www.debuginfo.com which says the
exe/dlls and pdbs are matching.

I tried many ways of generating the minidump files :
- visual studio
- clrdump from www.debuginfo.com,
- direct call to 'MiniDumpWriteDump' in dbghelp.dll
- task manager


I tried to call the code to generate a minidump instead of doing that in a
filter of unhandled exceptions.

None of those attempts allowed to me to get a correct call stack in visual
studio.

By the way I noticed I can't load the symbols either when direclty debugging
the software. But then the call stack is displayed anyway.

Anyone has a idea ?

Hi Vinz,

Based on my experience, Stack walking in .Net does not need the symbol
files; it will retrieve the managed object types from the metadata for the
walking. As a proof, .Net provided StackTrace class which allows us to walk
the stack at runtime. Sure, we do not have any symbol files at runtime.

Regarding the symbol loading, are you debugging the dump files from VS2005
or windbg? Do you experience the symbol loading problem for all the managed
modules or only one specific managed module? If you are using VS2005, you
have to turn off the "Just My Code" option in Tools -> Options ->Debugging
-> "Enable Just My Code". If you still can not resolve it, you may first
open Debug->Windows->Modules to open the modules window. Then, you may find
your module entry, right click it and select "Symbol Load Information" to
examine the details of the symbol probing paths. Another way is using
windbg to debug your application and use "!sym noisy" command to examine
the symbol loading details.

I suspect the stack walking failure is caused by the lack of memory data in
your minidump. Have you tried to take a full dump and have a test, does
this problem still exist?

I will wait for your further test information, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for your reply Jeffrey

The Stack Trace string shows only managed code. So I would miss native-code
crashs. Using a complete dump would mean customers sending gigabytes of
data. So that would be almost unusable.

Thanks to your tips I found what was wrong.


1) small minidumps

I found out that VS2005 (and previous version) can't show the managed code
stack from a minidump (at least not with a small one).

It's still possible using SOS commands. I'm the following in Immediate
Window of VS2005 or in Windbg
[quoted text, click to view]
and it outputs the complete stack for both managed and native code with
matching source code.

2) full dumps

Anyway, full dumps could be usefull in some cases.

I tried the full dump debugging you talked about using VS2005 and disabling
'Just My Code' options . I still can't see the managed code stack using the
Call Stack window. it's is replaced by some '001ba8b()'-like lines.

It looks like the symbols loading error is not the problem as 'Symbol Load
Information ...' reports:
[quoted text, click to view]
So it justs means there is no native code in my .NET dll. That is to be
expected from a c# project!

Maybe there is a specific way to generate full dumps when using managed code
?

best regards,
Vinz

P.S: Sorry, I wrongly replied to your mail address instead of replying on
the newsgroup

Hi Vinz,

Thank you for the feedback.

I have further discussed this issue with the CLR team internally. As they
confirmed, VS doesn't support managed dump debugging. This is due to
architectural limitations within the CLR. We have to use WinDbg + sos.dll.

Assembly metadata contains function names and param types, but symbol files
provide source file names, line numbers, and local variable names. So
symbols are not as necessary when debugging .NET code, but they are still
beneficial. We do not have official document for this yet, but it's
mentioned in multiple places like the one below:
http://msdn2.microsoft.com/en-us/library/ms954590.aspx

It seems that minidump is not the root cause of this problem. Stacks are
contained in minidumps without heap information and you can view them in
WinDbg using sos (!clrstack). As mentioned above, your problem is caused by
that there is no integrated support (technically, you can use sos in VS as
well, but it's all via text commands and output in the immediate window)
for managed dump debugging in VS due to an architectural limitation of the
CLR. I hope this clears your confusion.

Finally, the best resource regarding minidump vs fulldump is the windbg
help document. After you installed windbg and opened the help chm, you may
open Debuggers->Crash Dump Files ->User-Mode Dump Files->Varieties of
User-Mode Dump Files ->Full User-Mode Dumps/Minidumps. By default, "/m" is
the default option, in which the dump will include module, thread, and
stack information, but no additional data.

If you still have anything unclear, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Jeffrey

I got trouble using this newsgroup against winmail. It's nice to have
assumptions being asserted by the CLR team.
It all makes sense now and I can work with that.

Thank you for your support.

Best regards,
Vinz


[quoted text, click to view]