If you are an advanced developer that often needs to debug either native or managed Windows applications, you should be quite familiar with WinDbg, a low level debugger from Microsoft. It has a sharp learning curve, but is indeed the ultimate tool for debugging.
The WinDbg installers can be found in latest Windows SDK downloads/images and I suggest you find an x64 machine and install both 32 bit and 64 bit of WinDbg.
OK, then let’s create a single folder such as
E:\Debuggers\ on your machine, and copy both
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64 and
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86 directories to it.
Note that the directories are available on Windows 8 after installing Windows 8 SDK.
OK. In the future we will only launch WinDbg from either
x64 folder under
Launch WinDbg from
File | Symbol File Path … and then type
File | Exit and click Yes when a prompt appears.
After setting this, WinDbg will store symbols downloaded from Microsoft to the symbol folder we set.
SOSEX is a famous WinDbg extension for managed debugging. So let’s download the bits from
http://stevestechspot.com/SOSEXV40NowAvailable.aspx and then put the 32 bit dll in
E:\Debuggers\x86, and 64 bit dll in
E:\Debuggers\x64. Bitness must match.
We can do the same for PSSCOR2 and PSSCOR4. You can add other extensions you like follow the bitness rule.
The patching mechanism of .NET Framework sometimes introduces new versions of
mscordacwks.dll. As this is a critical part of .NET debugging, such updates can lead to a common issue called “Failed to load data access DLL, 0x80004005”. So whenever we try to analyze a .NET application dump file captured from another machine, we should try to get
sos.dll from that machine (pay attention to .NET Framework version used by that application, and process bitness). If the failure occurs when we try to execute a command in SOS, please rename the received
mscordacwks.dll to the proper name mentioned in the WinDbg error message (as that’s the name expected) and then put it into either
E:\Debuggers\x86 to match the bitness. Then you should be able to analyze the dump.
There is a tool called Mscordacwks Collector to help you get the files. Find it on GitHub.
Note that under some scenarios you even need to explicitly load the
sos.dllreceived. For example, debugging a .NET 4.0 dump on a .NET 4.5 installed machine is such a case.
OK, if you have followed the tips and prepare the folder, then
E:\Debuggers becomes your magic box for debugging, as it contains almost every bits you need.
Under corporate network, you can even share this folder with others, so they can be enabled by your magic (just remember that on another machine the symbol path should be adjusted a little bit).