After I've loaded sosex, I'm getting the following error. Any ideas? The hang dump is from a 32 bit machine, mine is 64-bit. Do I need to install something?
!clrstack
CLR DLL status: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3623.dll, Win32 error 0n2
The problem is the version of mscordacwks on your machine is a different version than the one from the crash dump. It's not a bitnesss issue - even though your machine is 64-bit, you have a 32-bit .NET installed. Mine is under C:\Windows\Microsoft.NET\Framework\v2.0.50727.
The copy you have won't have that long name, it'll just be called mscordacwks.dll. When the debugger sees your "active" copy is different, it'll search for one with the long name (avoiding dll hell) and that also tells you what version you need to get. After I get the correct mscordacwks.dll (eg from the original machine), I copy it into my framework directory and name it as it shows in the error message. I also set the image path of windbg to include the framework directory.
sos must use the mscordacwks framework assembly to understand the in memory data structures. This is all explained in the blog post “Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll? on the Notes from a dark corner blog.
You'll find the internet littered with questions about how to get various versions of that dll. Assuming you can't get the one from the machine that created the crash dump and it doesn't get downloaded from the microsoft symbol server, what I've done in the past is search microsoft.com for mscordacwks and the version I need (eg 2.0.50727.3623). It's usually in a security patch you can download.
If you don't have an appropriate system to install it on, I've had luck opening the install exe with 7zip. I've found the mscordacwks file in a cab that was in a patch file (an MSP file) that was in the security patch install executable. Each of those can be opened with 7zip.
When you hit a CAB file, sometimes it's better to use expand.exe as it can decompress files 7zip (v4.65) doesn't. If you open a CAB with 7zip that has an _manifest_.cix.xml, use expand instead as it uses the manifest to extract, decompress and rename the contents. 7zip (doing a simple extract to...) leaves it raw with bunches of files named numerically, literally 1, 2, etc. Those files may still be compressed. The way you know is if you open them (eg with SciTE),they'll start with a signature like PA30 (it will match the source "type" attribute from the manifest).
