Summary

Although you might think I've covered everything about WinDBG, I really covered only about half of the power of WinDBG. My goal was to show you the power of the debugger and help get you past the hurdles you'll encounter along the way. In case I haven't stressed it enough, let me say again that you really do need to read the WinDBG documentation.

The biggest trick with WinDBG is getting the symbols and source set up, and for dump file debugging, getting the image path set. WinDBG offers tremendous flexibility for controlling exactly where symbols are found and loaded. This helps tremendously in ensuring that you have the right symbols.

In addition to the ability to debug multiple processes at once, WinDBG offers outstanding breakpoint control, so you can stop exactly when and where you want. With the ability to execute commands on both breakpoints and exceptions, you now have extra super powers to track down extremely difficult bugs. With the extension commands, you can see things inside your process that you've never been able to see before.

One of the most important reasons for using WinDBG is its dump file handling. Visual Studio .NET, although finally allowing you to read dump files, is only suitable for dump files created on development machines. WinDBG, on the other hand, is the tool you'll be using to read real dump files from customer sites. That alone makes expending the effort to learn WinDBG well worth it.

Finally, I hope I was able to give you a starting point for using the interesting SOS extension DLL that supports .NET debugging. Although it's definitely hard-core for most developers, it's the only way to debug those combined managed and native applications that many developers are doing. As you can tell, you'll need to spend some time with SOS to take full advantage of it. Additionally, reading "Production Debugging for .NET Framework Applications" is crucial to understanding those tough conditions you might encounter with the largest heavy-duty applications.