I’ve just been asked through the “Ask” widget on the side of this blog on Yedda (my day job) this question:

Yedda � People. Sharing. Knowledge.Where is sos.dll for .net 3.5?

I installed Visual Studio 2008, but I don’t see sos.dll in the Microsoft.NET\Framework\v3.5 directory? What’s up with that?

Topics: , ,

Asked by dannyR on January 03, 2008

View the entire discussion on Yedda

To which I replied:

Yedda � People. Sharing. Knowledge.Where is sos.dll for .net 3.5?

There is a bit of confusion as to the .NET Framework versions as opposed to the CLR (Common Language Runtime) versions.

Up until .NET Framework 2.0, the CLR versions advanced side by side with the versions of the framework.

Starting from .NET Framework v3.0, the version of the CLR stated at 2.0 (there was no significant change in the CLR itself) and the framework’s version kept on going forward.

.NET Framework v3.5 actually runs on CLR 2.0 SP1.

This means that you can should be able to use the SOS.dll located at Microsoft.NET\Framework\v2.0.50727 with either Visual Studio (as I’ve explained on this post) or with WinDbg.

Dave Broman of Microsoft has written a post about the mapping of the versions of the .NET Framework to the version of the CLR. Do mind that as Dave states in his post, its the way he figures things up in his head and not the official documentation on this matter.

Topics: , ,

Answered by Eran on January 03, 2008

View the entire discussion on Yedda

I know its a bit confusing and I’m not really sure why Microsoft detached the versions of the Framework from the versions of CLR (well, I can understand some of the thoughts leading to this but I don’t think it was that good of a move) but Dave’s excellent post does put things in perspective and allows figuring out in what version of the CLR you are actually using.

I haven’t written in a while and I don’t like being an echo blog but this couldn’t pass right along.

ScottGu announced 2 days ago (yeah, I’m slow to catch that up, but its been a holiday here in Israel ;-) ) that they’ll release the full source code of the .NET framework library with Visual Studio 2008 so that everyone can browse it as well as be able to debug (which is always helpful).

In addition to that, it seems that VS 2008 will have integrated symbols server support which also includes downloading the debug symbols as well as source code directly from Microsoft.

Way to go Microsoft. This is exactly what I was missing for quite a long time!

Mike Taulty (which, by the way, has a great blog) wrote a short tutorial on how to figure out what the .NET Framework code does when you suddenly get an exception and you don’t really know why it is being thrown from the framework.

He also shows how to load our favorite WinDbg Extension – SOS – into Visual Studio and use it while debugging as well as use Reflector to disassemble the framework’s code into readable C# or VB.NET code.
I also briefly talked about loading SOS into Visual Studio a while back and mentioned the use of Reflector all over the place (because its such a great and useful utility!).

Mike, if you are reading this – Yes, I also do what you do and I suppose almost everyone who actually wants to know what is happening under the hood in the .NET framework :-)

Did you know that you can use SOS from within Visual Studio 2005, not just from WinDbg?
It has been previously discussed in a couple of places but most people don’t know it is possible to do that.

“Why should I use the SOS extension from within Visual Studio?”, you are probably asking.
The answer is quite simple.

Visual Studio is a rich debugger that shows us most of the information we want to know but it doesn’t show us a few important things like the actual size of an object and all of its references and who is referencing our object. While these things are not straight forward in Visual Studio, they are very easy to accomplish in SOS. For example, you can run the following command in SOS:

  • !objsize – to find out the actual size of the object and all of its referenced objects
  • !gcroot – to find who is referencing our object
  • !dumpheap – to see what’s all the stuff that we have on the heap. By using the -gen [generation number] parameter with !dumpheap, we can see all the objects that are currently in that generation
  • !SyncBlk – find out which managed locks are locked at the moment (I’ve talked about it before)

So, how do we actually do that?

Well, the first thing you need to do is enable “unmanaged debugging” by going to the “Project Properties” -> “Debugging” -> “Enable Unmanaged Debugging”.

After doing that, you can stop somewhere in your program, open the “Immediate” window (Debug -> Windows -> Immediate) and type:

.load sos

This will load the SOS extension. From there on you have most of the commands of the SOS extension at your disposal.
You might need to set the symbols path by calling .sympath, just like you would do in WinDbg.

An added bonus to this whole thing is that it also works on Visual Studio 2003, so you get to use it even with .NET Framework 1.1.

Francisco Martinez has some interesting tools that he developed to make it a bit easier to develop to .NET application to Mono using Visual Studio .NET.

These tools allow you to create a makefile from a Visual Studio project file enabling you to build the project in a complete Mono environment as well as import and export MonoDevelop project files from and into Visual Studio Project files.
It will also enable you to run your compiled code under Mono instead of the Microsoft .NET Runtime directly from the Visual Studio IDE.

I’ve been following the Mono project since its inception and it has come a long way since.

I know there are (and are going to be) a lot of legal issues that can do a lot of problems in regards to the project, but I still think its a necessary and welcome addition to the development platforms available on the different Linux flavors and UN*X operating systems.

I wonder if someone is planning to write a WinDbg extension to handle Mono ;-)
Though I’m not sure there will be a lot of market for it. People will probably use the Microsoft .NET Runtime for Windows development and/or deployment and Mono for a Non Windows development / Deployment.

I guess only time will tell :-)

I’m going to be helping out in the Visual Studio 2005 Launch Event here in Israel in a side session titled (and it’s a translation from Hebrew): “Error detection in off-road terrain and combining your application with Windows Error Reporting”.

Sounds a bit long for a title, isn’t it? ;-)

There are a few such side sessions which will be going on at the same time as other “Main” sessions. The main idea behind the side sessions is to have a smaller more intimate session (~50+ peoplee) that will allow better interaction between the lecturers and the people coming to hear the lecture.

We will be talking about how to do some production debugging at a customer site and how to handle memory dumps for post mortem debugging when you can’t have access to the client’s site. Gadi Meir of Idag (who is leading the session) will also talk about Windows Error Reporting (WER) and how to make your program work with it.
I will be talking about the managed areas of production and post mortem debugging as well as some samples on how to use, instrument and extend MDbg (which I talked about quite a bit in previous posts). Mainly these are topics that I’m usually covering here on the blog.

For some reason, since I’m a second chair in the presentation (and there are a lot of other second chairs for the other side sessions) I was not mentioned in the invitation.

That’s not nice, isn’t it? (remind me to have a small chat with the organizers. The second chairs should also be mentioned!)

Oh well… at least it’s going to be a cool event.
All of you in Israel – be sure to register here.

See you there and “Get Ready to Rock” (god, these marketing guys needs someone to help them a bit… ;-) )

If you want to catch me for a quick talk/question/whatever I will be hanging around the place where the session will be conducted and probably all around the place, so be sure to catch me!

I had a stupid problem today compiling MDbg in VS2005 and I thought I should share it with you so others won’t waste 10min for their lives.

I have both VS2003 and VS2005 (the RTM of course ;-) ) installed on my machine.

The MDbg source code that I talked about in the previous post, has one assembly called corapi2 which only includes IL source code since it has a few COM marshaling trickes that are not covered by IL code generated from C#.

corapi2 has a .csproj file and is a part of the MDbg solution for ease of use. it doesn’t compile C# code, but rather run a post build command that runs ILAsm.

I tried to compile the soultion but it failed saying that it cannot recognize the interface ICorDebugProcessEnum.

I started to investigate and saw that it is suppose to be declared in corapi2.
I dropped corapi2.dll into Reflector and saw no .NET code. Strange.

I tried manually compiling it and go a funny error about uint32 in line 88. Go figure.
Then I noticed that I’m running ILAsm of Framework 1.1 and not Framework 2.0 since, for some reason I have the Framework 1.1 folder in my PATH environment variable.

I open the the Visual Studio 2005 Command Prompt, changed dir to the Mdbg folder and run nmake (which is the other option of compiling it) and it compiled with no special problems :-).

Beware of the PATH!

[UPDATE - 9:30AM]
[Added some of the links from Rico's post and some more input on them]

This is a bit off topic, but I’d thought I’ll still give it a post since, as we all know, the best way to debug is to not debug at all. Avoiding common pitfalls and understanding how things work can save hours of debugging work at a later time.

Anyhow, I’ve stumbled upon a post by Rico Mariani in his blog about Whidbey Performance Opportunities.

(SIDE NOTE: his blog is full of interesting things since his current position is in the CLR performance team. If there is someone that knows how to squeeze extra performance from the CLR that’s him)

This post talks about some of the new things Whidbey (Visual Studio 2005) has to offer as well as the new .NET CLR 2.0.

The post offer links to each subject with additional information such as:

  • Review by Jason Zander of NGen – Its a little old but give a good insight as to what this tool does and how and when to use it. Keep in mind, as stated in the post, that NGen in v1.0 and v1.1 was mainly created for usage of the runtime itself. It got revamped a bit in Whidbey so that it is much better.
  • NGen is only good for a specific version of the CLR. If a new service pack was installed, there is a need to re-NGen your assemblies, otherwise their native image will be ignored and they will be considered as standard .NET assemblies that were not NGen’ed. As part of WinFX (which will be released in Windows codenamed Longhorn, now named Windows Vista) there is a new service called Native Image Service that does this tedious task of figuring out that certain assemblies needs to be re-NGen’ed and does that. You can use ceratin attributes in an assembly to give it better understanding of what to actually do with your assembly. You can read more about it here.
  • Another great post by Rico Mariani titled Six Questions About Generics and Performance.
  • An excellent two pieces post by Maoni about using GC Efficiently, Part1 and Part2.
  • Dodge Common Performance Pitfalls to Craft Speedy Applications using Reflection by Joel Pobar on this month’s (July) MSDN Magazine issue. It talks about imporvments of the reflection implementation in .NET 2.0 as well as the usage of some new APIs that lets you do things more quickly.Read, understand, let it sink in and by the time you’ll start working with it you’ll be better prepared.