views:

57

answers:

2

I followed these steps to be able to debug in the .Net framework code. This work well for some parts of the framework (for example for System.Drawing.dll), but not for other parts (clr.dll, mscoree.dll, ...).

This seems a bit strange to me since the code in these dlls was released by Microsoft (at least the parts I see in the call stack).

I am using VS2010 & .Net 4.

Did I do something wrong, or are the correct pdb files not released by Microsoft?

+1  A: 

Microsoft released a shared-source implementation of the whole common language runtime, including mscoree.dll, but this isn't the source code that goes into the real .NET framework.

On the other hand, the source code you've obtained for System.Drawing.dll etc. is the real source code to the .NET framework, but you can't get at the runtime code this way.

Here's the download for SSCLI, otherwise known as Rotor: http://www.microsoft.com/downloads/details.aspx?FamilyId=8C09FD61-3F26-4555-AE17-3121B4F51D4D&displaylang=en

More explanation on the differences: http://stackoverflow.com/questions/1893892/what-is-the-difference-between-sscli-2-0-rotor-and-net

Tim Robinson
I do have to code I'm interested in, I just can't use it in the debugger (meaning: step through it) and I wonder how to do that.
eli
Have you got the SSCLI source code? Since that's not the same source that was used to build the .NET framework (there's no SSCLI release for .NET 4, for instance), I wouldn't have thought it would be much use in the debugger.
Tim Robinson
I got the code here: http://referencesource.microsoft.com/netframework.aspxI guess that's not the SSCLI source
eli
Did you get C++ sources from referencesource.microsoft.com? Which link did you use?
Tim Robinson
See the link above: I downloaded .Net 4
eli
OK, that's the one I got. It appears to be an offline copy of the framework C# sources, so it's missing the C++ code that makes up mscoree.dll. To my knowledge, the source to the official mscoree.dll build has never been released.
Tim Robinson
+1  A: 

I think VS allows you to debug only managed libraries of the framework. If you really need to debug the unmanaged (native) code of the CLR you should use WinDBG, but this is way more complex...

munissor
Visual Studio can debug managed and unmanaged code at the same time, if you enable unmanaged debugging for a managed project
Tim Robinson