Hi,
Thanks for your feedback. I see your concern.
Actually, .Net debugging is a bit different from the Win32 native code
debugging. Win32 native code debugging uses the debugging API of the
Windows OS, while .Net debugging uses the debugging service of the
underlying CLR instead of the OS. Internally, there is a dedicate debugger
thread running in the CLR(also in every .Net process) for debugging
purpose. The debugger team chooses this design to improve performance(the
debugger thread runs in the same process of the debuggee) of the debugging
and many other reasons. If you are curious, please refer to the links below:
"Implications of using a helper thread for debugging"
http://blogs.msdn.com/jmstall/archive/2004/10/13/241828.aspx
So every .Net debugger(except windbg) needs the support of the CLR debugger
thread for debugging. This means that the debugger is CLR dependent. When
the VS.net2003 debugger is released, the CLR2.0 is not released yet, so the
VS.net2003 debugger can not debug .Net2.0 application. We have to use a
newer debugger.
Regarding VC6.0 debugger, it only deals with the pure native code; it only
needs the support of the underlying OS and CPU. So far as we are using
Windows and the x86 compitable CPU, the debugging experience is the same
regardless of the compiler is VC++ 6.0, 2003, 2005 or 2008. For the VC
native debugger, all it sees is x86 binary machine code. Even if you are
debugging an .Net application from the VC6.0 debugger, it just deals with
the JITed machine code instead of .Net code, it needs no support of the
CLR. For example, you may use VS.net2003 debugger to attach a .Net2.0
application using pure native debugging. This will eliminate the support
from the CLR.
Finally, using windbg+SOS.dll for managed or interop debugging works on all
Net versions, since it is a pure native debugger while uses SOS.dll to
understand the CLR internal structures. You only need to load correct
version of SOS.dll for targeting CLR version.
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
==================================================
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.
