Getting SOS to work, a historical view

When you try to debug a managed application using Windbg and SOS, there have been issues over the years that have come up with trying to get the extension to work properly.

The major stumbling block has been to get it to load the proper files for it to work.  These files have changed over the years.  For example:

• For .NET 1.0, we required a BIN file
• For .NET 1.1, the BIN information was pulled automatically
• For .NET 2.0, we require a mscordacwks file

So why do we have these files?

These files are the method that the extension uses to know where specific information is inside of the process.  The easiest way to get this information is with symbol files.  The issue is that external to Microsoft that information is not available and so the extension would not be able to give you the information properly.  So the solution was to create a file which references where all of the important information is stored.  These offsets are then stored in this file and the extension can load that file and see where to pull the data from.

For .NET 1.0, you can still get the BIN files by searching for SOS on the download site like this.

For .NET 1.1, we moved this file to into the mscorwks.dll and mscorsvr.dll files.

For .NET 2.0, we moved this information into the mscordacwks file.  This file needs to match up with the given version of the framework.  It is also best to make sure the SOS.dll matches up with the version as well.  So if you want to debug .NET 2.0 SP2, use the SOS.dll that shipped with .NET 2.0 SP2.

One other side, note, you must use the same architecture of debugger as the process was.  So if you want to debug ia64, you must use an ia64 debugger.