Debugging managed code
Jochen Kalmbach
I downloaded the latest "Debugging Tools for Windows" (Beta).
In the documentation of windbg under "Debugging Managed Code" is the
following sentence:
"WinDbg, CDB and NTSD can debug managed applications. This requires
version 6.3 or later of Debbugging Tools for Windows, and version M2 or
later of the .NET common language runtime Microsoft Codename Whidbey.
This version of the runtime is present in version M6 and later of the
Windows codename "Longhorn" operating system."
Can someone please explain the versions
- M2
- M6
!?
Is with the current .NET runtime (1.1) no debuggung possible !?
Is it currently possible to write a minidump and see the (mixed)
callstack in WinDbg?
If not, is there a usefull solution to this problem (except on writing
the full memory dump) ?
I would use minidumps at our customers side if some exceptions races.
This minidump can be sent via E-Mail to me. And I want to be able to see
that (mixed) callstack incl. line infos.
Is this possible !?
For me it is no solution to use the "StackFrame" class, because I do not
have line infos.
Any comments are welcome.
--
Greetings
Jochen
Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp
Pat [MSFT]
w/1.1.
2) Yes, using SOS.dll (comes w/the framework)
3) Mini-dump debugs cannot be done. This is not a limitation of the
debuggers, rather a limitation of the information in the mini-dump. You
need full userdumps to debug managed code. The issue is that the managed
stack has virtually all of its information stored on the managed heap(s)
which are not captured in a minidump.
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns9432DC01CCF24no...@207.46.248.16...
Jochen Kalmbach
> 3) Mini-dump debugs cannot be done. This is not a limitation of the
> debuggers, rather a limitation of the information in the mini-dump.
> You need full userdumps to debug managed code. The issue is that the
> managed stack has virtually all of its information stored on the
> managed heap(s) which are not captured in a minidump.
So, what is the recommended way from MS to support our customers if an
problem occurs at the customer side !?
For unamaged apps I can use "minidumps" which can be sent via E-Mail to me.
Here I can view the complete callstack incl. parameters if I have the PDBs.
With managed apps I have the following problems:
1. I cannot generate PDB-Files with the IDE in release versions
2. I am not able to write (usefull) minidumps
3. I cannot get line infos from StackFrame-class...
What are the solution to this problems !?
Pat [MSFT]
Properties->Build->Generate Debugging Information (set to True)
2) Create a full dump and have the customer upload it (or provide a link for
you to download it). That is what MS-support does for debugging .Net code
or provide the release .pdb to the customer and help them generate the stack
that you need using WinDBG.
3) Correct, but you should be able to get the function name, which often
times will be enough to isolate the problem.
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns943361985F1B2J...@127.0.0.1...
Jochen Kalmbach
> 1) PDB's may be created w/Release builds (Project
> Properties->Configuration Properties->Build->Generate Debugging
> Information (set to True)
No. If you set this to true you will get an "Debug-Version" and NO
Release-Version (You can see this by looking into the assembly. You will
see an "DebuggableAttribute"; shich means it cannot be optimised.
> 2) Create a full dump and have the customer
> upload it (or provide a link for you to download it). That is what
> MS-support does for debugging .Net code or provide the release .pdb to
> the customer and help them generate the stack that you need using
> WinDBG.
<ironic>
Really great idea!!!!
That愀 the reason why MS introduced minidumps!
</ironic>
Pat [MSFT]
For 1.0 (VS2k2 or csc.exe), you are correct.
For 1.1 (VS2k3 or csc.exe), you can build optimized release symbols
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cscomp/htm
l/vcrefuenabledisableoptimizations.asp)
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns9433CC9187F2Bno...@207.46.248.16...
Pat [MSFT]
For 1.0 (VS2k2 or csc.exe), you are correct.
For 1.1 (VS2k3 or csc.exe), you can build optimized release symbols
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cscomp/htm
l/vcrefuenabledisableoptimizations.asp)
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns9433CC9187F2Bno...@207.46.248.16...
Jochen Kalmbach
> Which .Net version are you using?
>
> For 1.0 (VS2k2 or csc.exe), you are correct.
> For 1.1 (VS2k3 or csc.exe), you can build optimized release symbols
I am using VS2003.
And it is NOT possible!!!
If it is possible please explain it!
The only way is to use csc:
csc /o /debug:pdbonly
With the IDE it is not possible to build release versions (/o) with
debug symbols. You can only choose between using "/debug" or not. You
cannot choose "/debug:pdbonly".
If you only specify "/o /debug" then the optimization is ignored!
Please look into the assembly! You will see the
"DebuggableAttribute(true, true)" which means:
- JITTrackingEnabled
- JITOptimizerDisabled
If you have a working solution I would be happy!
Pat [MSFT]
With 1.0, if you create symbols, no optimizations
With 1.1, csc.exe /o /debug:pdbonly gets you symbols with optimizations.
With 1.1 & Visual Studio 2k3, /debug:Full is the only option, which will (as
Jochen correctly observed) disable any optimizations. I double checked
w/the dev team to make sure (which is why the delay).
So, for now, the only work around would be to do the dev work in VS (and
debug builds, etc.), but use the csc.exe directly for a release build.
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns94346D65B2DB1no...@207.46.248.16...
Jochen Kalmbach
> So I did some checking:
>
> With 1.0, if you create symbols, no optimizations
> With 1.1, csc.exe /o /debug:pdbonly gets you symbols with
> optimizations. With 1.1 & Visual Studio 2k3, /debug:Full is the only
> option, which will (as Jochen correctly observed) disable any
> optimizations. I double checked w/the dev team to make sure (which is
> why the delay).
>
> So, for now, the only work around would be to do the dev work in VS
> (and debug builds, etc.), but use the csc.exe directly for a release
> build.
Thanx for your answer!
Do you have some good news about writing minidumps in .NET 1.2 (2.0) ?
Is there an option in "Whidbey" to use "/debug:pdbonly" AND "/o" ?
Pat [MSFT]
when it goes into its official Beta/Beta2.
Pat
"Jochen Kalmbach" <nospam-Joch...@holzma.de> wrote in message
news:Xns94374C315BAF5J...@127.0.0.1...