We deliver working software every week. That’s important in agile. It creates a lot of trust when our stakeholders can download the bits and try stuff out.
Unfortunately, this also means that they run into more, let’s say unpolished areas of our code. This is great news for us – we get high quality feedback early in the process, which helps us iron out the problems in the code earlier rather than later. But sometimes, the people running our software do stuff that we can’t reproduce. Since the users doesn’t have any debuggers installed, we don’t get enough debug information.
To counter this frustration, I’ve downloaded Debugging Tools for Windows, installed it and copied the folder in Program Files down to a USB key. Now I can run windbg from the USB key with no installation hassle. I thought I’d share the simple steps needed to see an exception.
- Start windbg and load the executable (Ctrl-E)
- Set up windbg to automatically download needed symbol files by writing !symfix
- Load SOS by writing !load C:\WINDOWS\Microsoft.NET\Framework\<version number>\SOS.dll
- Now run the application (F5)
- When your application throws an unhandled exception, you’ll end up in windbg again. Now run !pe to see information about the exception
You can get a lot more information than that. I usually do a !threads and !clrstack to get an overview of what’s going on. !help gives you a list of what available SOS commands you have.
Debugging makes me feel a bit like a detective sometimes, and like a I want to tear my arm of and hit me over the head until I pass out at other times. But good debug sessions are really enjoyable.
Want to learn more about debugging .NET applications in windbg? Go here or there.