When your code goes into production, you usually no longer have access to its binaries when they reach their final destination. Whether that is someone’s desktop or a set of servers, you no longer have access to directly observe your code and its environment. Operating system patches are applied, network policies are changed, firewall rules are restricted, disks are configured… as your code lives its life in its new home, there’s a wide range of things that may change in its environment and affect how it behaves (or rather misbehaves). You liberally littered your code with lines of logging logic to learn in these lulls (long alliteration!), and that gives you an idea of where the code is not performing as expected, but you still are unaware of the exact reason (and thus, the fix) that your code is not working as expected.
Your challenge now is to try to figure out what is going wrong without wasting the customer’s time doing troubleshooting, because there’s nothing that a business user loves more than being asked by a technical guy which button is he really clicking to get that error. You don’t have the luxury (should have thrown that in the alliteration sentence previously) of spending days or weeks doing troubleshooting, you need to know what is happening right now.
In a perfect world, you would have the stack trace, you’d be able to inspect locals, you could debug the code. Well, it turns out, you can do just that… and never attach to the customer’s environment.
Download WinDbg and Get Started
Download the Debugging Tools for Windows to your local developer machine. You can get them as part of the Windows SDK. Choose the Debugging Tools for Windows in the Common Tools section if you only want the debugging tools for your current machine’s platform. If it is an x86 machine, then only the x86 tools are installed. If your machine has an Intel 64-bit processor, then only the x64 tools are installed. If you choose the redistributable version, then you get all three (x86, x64, and Itanium). After you download, install to your local developer machine (not the customer’s machine).
One tip is to change the installation path. By default, windbg will be copied to the Program Files directory. Instead, change the path to something like “d:\debug”. This will make it easier to add extensions.
Now that you’ve installed, in the start menu you will see a new program group, “Debugging Tools for Windows (x64)”, and a new program in it called “WinDbg”.
Install PssCor2
The next step is to install the extensions for managed code. By default, WinDbg is a tool designed for unmanaged code debugging, but an extension ships with the .NET Framework called SOS.dll that enables managed code debugging. An additional WinDbg extension called PssCor2 has been created that is a superset of SOS and provides additional functionality for managed code developers. This extension will allow you to inspect managed threads, the managed object heap, and inspect the CLR stack, among other things. Download PssCor2 and unzip it.
I unzipped PssCor2 to my “d:\debug” directory, this will make it much easier to use as you will see later in this post.
Read more: Kirk Evans Blog