Archive
Finally a simple way to download the “Debugging Tools for Windows”
Since a few weeks (months maybe?) the only way to download the marvelous “Debugging Tools for WIndows” package is something quite difficult : first you have to go to the Microsoft dedicated website, then get the whole Windows SDK package (just a web download starter…) and find which option to install to finally get the Windbg executable. Beyond those annoying steps, Microsoft added another difficulty: the description of each option in the installer is not descriptive at all. And again, publish only an installer for a product that is have been designed to avoid any kind of installation (think about your production server where you really want to use that debugger…) is a little bit weird, isnt’it?
Following the advise of a good friend, I choose to reveal the almost-hidden checkbox and especially give the zipped file of the x86 and x64 version.
x86 and x64 : which version of a debugger should I use ?
Maybe this post will be the shorter ever of this blog, but I have to write something about it. Microsoft offer two version of their Debugging Tools: a x86 version, and a x64 version. Which one do you have to use?
On 32-bit OS, the answer is really simple: you don’t have the choice but to use the x86 version, as the OS will not be able to start a 64-bit executable. End of the decision tree :)
On 64-bits OS, it depends on what you want to debug. Unless you need to dig deep inside the Wow64 layers (and I never had to do that personally, but speaking about it makes me curious about what I can found), just use the x86 version to debug a 32-bits executable, and the x64 version to debug a 64-bits executable. If you mess up with this simple rule, you may encounter serious difficulties to get CLR information through SOS (well, it’s basically not possible as far as I know), have wrong data about common memory structure that Windbg can display, and maybe be unable to load your favorite extension.
How to debug a Windows service
Maybe you thought when you read this title: “well it’s kind of easy, I just have to attach any debugger to my running service“. And you’re definitely right.
But sometimes you have to debug the very beginning of your service (just after the “Start” control), or even before, when the main() function has just started. Or you’re experiencing a bug that happens only with a specific user, or only in a context of a Windows service (could be environment variables, registry keys, etc.). Hopefully, with a few tricks, you can easily setup a debugger that will attach to a process just after its creation.
A symbol server : what is it, and why you should use it
The more complex your information system is, the more you will have bugs, and the more you will have symbol files to manage. The cool thing is that second ones can help you resolve the first ones, read my first post if you are not sure about that. The sad thing is that you could end up with tons of symbol files, and finding the right one for every version of you binaries is just too complicated.
The first key for a successful debug on Windows : the Symbols
I have long pondered about the subject of my first post. Debugging subtle bugs on Windows can be easy or not, but one thing is sure: it is really a pain to understand what happen in a software (at least a native one) without the Symbols. There is lot to say about it, and you can find lots of article on the internet describing the contents and the benefits. My approach will be much more practical: a short description, and why you definitely have to create and use them.
BugSlasher 