Three years ago I blogged about obtaining SOS.dll and mscordacwks.dll indirectly from the Microsoft KB websites in case you only have a dump from the production system but can’t gain access to copy these files over.
(Reminder: SOS.dll is a WinDbg extension for debugging .NET processes and dump files. The DAC, or mscordacwks.dll, is a helper library used by SOS to access the inner workings of a specific CLR version’s data structures. The DAC is also used by ClrMD, a managed library that provides an API replacement for the SOS extension commands.)
It turns out that for Windows Phone applications (using the Windows Phone CoreCLR), there is no official place online where you can find the various CLR versions alongside with SOS and the DAC. In fact, it seems that Microsoft isn’t making SOS.dll for Windows Phone available as part of the phone image, so there is no way for you to put your hands on it. This is also why WinDbg’s !analyze -v command fails to provide any .NET-related information when you open a dump from a .NET Windows Phone application.
Not all is lost, however. First, we still have Visual Studio, which doesn’t need SOS. The Visual Studio dump debugging engine requires only the DAC DLL, which is available on the Microsoft symbol server. Just drop the dump file into Visual Studio and start debugging it.
SIDENOTE: Interestingly, even though the Windows Phone CoreCLR is built for the ARM processor, Microsoft makes available x86 versions of the DAC, so you can use them from your Windows desktop. For example, mscordaccore_x86_arm_4.0.30508.00.dll is the DAC you should use to debug Windows Phone processes using CoreCLR 4.0.30508.
If you need the SOS extension commands which aren’t provided by the Visual Studio dump debugging interface (such as !SyncBlk, !ThreadPool, !DumpDomain etc.), you can use ClrMD to build your own replacements of these commands. I have a blog post explaining how to use ClrMD for a couple of scenarios. More on that in a future post.