From time to time I get questions about missing method names in the sos !clrstack output, like this:

0:019> !clrstack 
OS Thread Id: 0x5d0 (19) 
ESP      EIP 
0f31f340 7c80bef7 [HelperMethodFrame_1OBJ: 0f31f340] 
0f31f398 1449167a 
0f31f3c4 144915e6 
0f31f3f4 10d81b48 
0f31f4b4 793e25cf 
0f31f4bc 79366b3d 
0f31f4d4 793e2734 
0f31f4e8 793e26ac 
0f31f678 79e7c0e3 [GCFrame: 0f31f678]

Jonathan Dickinson from SourceCode, just emailed me and told me that he had written an article about this and how to resolve it.  You can read the whole article here: http://jonathan.dickinsons.co.za/blog/2010/08/windbg-stack-fix/
Thanks Jonathan for writing that article.

Solution:

As mentioned in the article there are a couple of things you need to get rid of the problem.

1. The correct version of MSCORDACWKS.dll

You can get this in two ways…

a. from the Microsoft public symbol server by setting the symbol path to srv*c:\mycache*http://msdl.microsoft.com/download/symbols

or

b. by copying it from the machine you got the dump from, it is located in the Framework\<version> directory.  The mscordacwks.dll needs to be copied to your symbol path, and to differentiate them if you work with multiple versions you can name it mscordacwks_x86_x86_2.0.50727.42.dll for example.    On my machine, because I am working with so many different versions i have a c:\dac\x86 and a c:\dac\x64 directory where I store these.

2. A compatible version of sos.dll

sos.dll can be found in your framework\<version> directory and needs to match the architecture and major version of the framework used in the dump.  If there is too big of a difference between the minor versions of the framework on your machine and the machine where you got the dump, you can try copying the sos.dll from the machine that the dump was taken from. Or you can use psscor2.dll.

 

Have a good one,
Tess