As a side note, for a few months when working with Ubuntu, I’ve used GDB and learned LLDB. These are very intuitive debuggers, easy to use and learn. However they don’t come close to WinDbg in terms of integration with the operating system, commands and standard automation capabilities. But, let’s be fair, I love the fact you can use Python to extend GDB.
When working for Microsoft as a PFE (Premier Field Engineer), customers used to ask me a lot about the differences between Visual Studio and WinDbg and when WinDbg should be used, so let’s start with this explanation:
Visual Studio is heavy, but very intuitive, has a lot of features to debug and write code. This is the debugger you want to use when you are programming or when you can debug a problem using your development environment.
WinDbg is very light, but not intuitive. At all. So there is a learning curve but this is the debugger you want to use when:
- You need to do some live debugging on a production server. WinDbg is light and easy to install.
- You want to impress your friends 🙂
As you can see, for engineers working with production server problems, WinDbg is the debugger to use. Personally, I like to collect dump files with DebugDiag (discussed in my first post <<< hyperlink), use the DebugDiag automated analysis and, if needed, use WinDbg to really dig it deeper.
Now that you know when and why to use WinDbg, let’s continue on how to use it.
WinDbg has a lot of commands, and some of these commands come from extensions. Extensions are DLLs with commands, so you can load them on the fly during your debugging session according to your needs.
Tip: When debugging .NET applications, you need to load the sos.dll extension that is part of the .NET Framework, so you can debug .NET code and see managed code as well as native code. Just use: .cordll -ve -u -l
Tip 2: sosex.dll is another extension that complements sos.dll. They have commands in common but also different commands.
Notice that you can create your own WinDbg extensions or WinDbg scripts. Unfortunately, the WinDbg scripting language is very limited, cryptic, and error-prone, so a simple five-line script can take long hours to be programmed.
Here is an analogy I like to use: someone can learn how to use Wireshark and do some network troubleshooting. It’s definitely useful, however, when you face complex network problems you must know the fundamentals of networking in order to debug the problem. Only knowing how to use the tool is not enough.
WinDbg follows the same principle; if you learn some basic commands even if you don’t understand C/C++, assembly, and some level of OS internals, you still can benefit from the tool. On the other hand, if you face more complex problems, then a deeper understanding of the fundamentals will be necessary as mentioned on item #9 of this blog post.
Tip 3: This is the best book I’ve ever read about .NET performance optimization.
It may come as no surprise that I use WinDbg a lot at BitTitan. This is the ultimate tool when all the other tools are not enough to give us the root cause of some application problem.
Tip 4: This book is about the Sysinternals tools, like Process Explorer, Process Monitor, ProcDump, and the others indispensable tools that are part of Sysinternals.
So if you decide to give WinDbg a try, here are some good resources:
Tip 5: If you don’t use WinDbg all the time, you’ll forget the basic commands. To overcome it, you can have them as hyperlinks as part of the Debugger window, so you just click on the command you want and it runs. Here is how to do the trick.
At BitTitan we use WinDbg for User Mode debugging, but if you need to do Kernel debugging you can learn a lot from these videos.
By the way, did I mention that my team is hiring? We have a great, low-key, ego-free team—BitTitan offers an amazing work environment. If you’re thinking about changing jobs and is passionate about solving complex software problems and creating tools, this might be your dream job!