Intro to WinDBG for .NET Developers

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”. 

Read more: Kirk Evans Blog
QR:

Posted via email from Jasper-net