SOS Best Practice: Match the SOS version with the process being analyzed

I haven’t seen a whole of of issues around this as of yet, but now that 3.5 SP1 has released that may change.  If you copy SOS.dll to another location and then load it out of that directory to troubleshoot dumps, you may start seeing problems.  Namely, things like !clrstack not returning any valid names for functions and just printing out the numbers.  For example:

 0:006> !clrstack
OS Thread Id: 0x1154 (6)
ESP       EIP     
0154cfdc 7614f35f [HelperMethodFrame: 0154cfdc] 
0154d080 5fb7b8cd 
0154d094 5fb7b78b 
0154d0bc 5fd26907 
0154d0d0 5f95a87c 
0154d0e8 5f959458 
0154d108 5f9634f1 
0154d124 5f96342d 
0154d150 65525e55 
0154d17c 5e339ea3 
0154d1f8 5e33ce4d 
0154d37c 5e3400cc 
0154d380 5dd60d14 
0154d3b4 5e56def3 
0154d408 5dce876b 
0154d438 5dd12799 
0154d47c 5dd0df51 
0154d4b0 5dcea92a 
0154d714 6e871b4c [GCFrame: 0154d714] 
0154d730 6e871b4c [GCFrame: 0154d730] 
0154d8a4 6e871b4c [ContextTransitionFrame: 0154d8a4] 
0154d9b8 6e871b4c [GCFrame: 0154d9b8] 
0154d99c 6e871b4c [GCFrame: 0154d99c] 
0154ec1c 6e871b4c [CustomGCFrame: 0154ec1c] 
0154ec30 6e871b4c [CustomGCFrame: 0154ec30] 
0154ec44 6e871b4c [CustomGCFrame: 0154ec44] 
0154ec58 6e871b4c [CustomGCFrame: 0154ec58] 
0154ec6c 6e871b4c [CustomGCFrame: 0154ec6c] 
0154ec80 6e871b4c [CustomGCFrame: 0154ec80] 
0154ec94 6e871b4c [CustomGCFrame: 0154ec94] 
0154f060 6e871b4c [TPMethodFrame: 0154f060] 
0154f07c 5dcea109 
0154f0f0 5dce9d1f 
0154f128 5dce9bed 
0154f170 5dce9b3a 
0154f194 5e3bf136 
0154f3f8 6e968c4e [GCFrame: 0154f3f8] 
0154f554 6e968c4e [ComMethodFrame: 0154f554] 

This is a sign that there may be something incorrect with SOS.  We can clearly see this is a managed stack, but we aren’t getting any values.

The reason for this is that we don’t guarantee SOS to work with any version of the framework other then the version that was running.  In other words, always match up the SOS version with the framework version.  If you are troubleshooting on the same machine you captured the dump from, or a machine running the same version of the framework, you can easily do this by loading SOS using:

 .loadby sos mscorwks

Please note that the SOS that ships with the debugger package is different from this.  This version will work correctly with any 1.x version of the framework.