When I joint Microsoft and the EMEA Internet Dev Support Team in late 2004, I soon realized that I had to build a new skillset to have a future in my new role; before that I was a kind of “self made” developer, in the sense that almost everything I learnt I did in “the hard way”, buying and readings my own books, building a lot of samples, testing, making a lot of mistakes etc… I’ve not had a real mentor, I simply tried to learn from my own experiences, testing things “in real life” and watching the results. And for me in that period the word “debugging” meant only the Visual Studio debugger, run the application and inspect my code hunting for bugs; I never thought to WinDbg, memory dumps and deep system internals (well, to he honest I knew something about memory dumps, but I thought it was too hard for me and never really tried to get my hands dirty with that stuff).
Then I join Microsoft and the iDev team, and my horizons expanded. Not too much time had to pass before I realized the kind of cases we were managing required some different (and deeper) skills/knowledge, and more and more often I had to seek assistance from my colleagues with this new stuff. That’s how thing goes at the beginning in a new role, but I like to “walk with my own legs” (if you understand what I mean) so I started searching for manuals, how to etc…, and guess what? I found a lot of information but not really organized so that a newby like me could start learning the subject… and the more I was asking advices about training and books, the more I was getting replies like “that’s a matter of experience, you need to jump on it and start digging!“.
To make a long story short, I’ve finally accepted the advice and made some kind of cut and paste of the information I needed to start. Here and in upcoming posts I’ll try to write down what I learnt so far; of course I’ve not the nerve to believe this will be a definitive guide to debugging (later on this post I’ll mention some docs and blogs which deals with advanced topics), but I’ll be happy if I’ll save you some time especially at the beginning when you’re trying to figure out how this new thing works, and someone will find this useful and intriguing enough to start digging into this interesting (and sometimes surprising) world. ?
The tool case
We have to start somewhere, so like an apprentice carpenter the first thing to do is to know our tool kit and which is the right one for the task at hand.
Debugging tools for Windows
(download) This is the foundation of managed and unmanaged debugging; of course you can find a lot of different debuggers out there on the Internet, but WinDbg is one of the most powerful you can find, flexible and extendible (through a sort of plugins/extensions you can develop with the SDK) which allows you to debug you managed and native code, and also the Windows kernel. Or you can attach it to a process to debug live. The setup package will install a number of useful tools like adplus (a .vbs script which takes some arguments to capture a memory dump you can then analyze offline with WinDbg), gflags and many others.
DebugDiag
(download) This has originally been developed by the IIS Escalation Engineers team and has a marked shape for IIS debugging (even if it can be also used to dump other processes); it has also a couple of built-in scripts useful to automatically analyze a crash or memory leak dumps and have a nicely formatted report which can give you an idea of what’s happening. To be honest I prefer to use adplus, but I find DebugDiag quite useful in some specific scenarios, particularly when we have an unmanaged memory leak: this is because DebugDiag uses a dll called LeakTrack which gets injected into the target process (usually w3wp.exe) to track memory allocations, and it can greatly help the automatic analysis to show where the memory is going, who is allocating it etc… This is not enough to resolve the problem, but it’s a quick way to find some good clues and steer your next steps in the right direction.
Reflector
(download) This is the tool to disassemble managed code, with an interesting list of add-ins to expand it’s capabilities; very handy to have a look at the source code of managed components extracted from a dump
LogParser
(download) I discovered this tool only recently and I’m still playing with it to explore all of its capabilities (see my previous posts here and here); anyway it’s very powerful and as the name implies can be used to analyze log files and other inputs (File System, Event Logs, IIS logs, CSV and many more) with a Sql-like query syntax and can output the result in as many formats
Sysinternals tools
There are a lot of them, but what I use most are Process Explorer, Process Monitor and the PSTools.
Of course there are many more tools I use in my daily job, but the above list should be enough for most occasions (and for at least half of them you’ll just need WinDbg with a good extension).
Some good docs
As you can guess, the right tools are like a gun without bullets, if you don’t know how to use them and most important how to understand and interpret the output they give; moreover, the more you know the platform (and with the term platform here I mean both the .NET world and the underlying OS where it runs) the more you’ll be able to understand the values you’ll get, spot possible incongruities and imagine understand why in the given scenario things are going wrong.
Unfortunately I can’t point you to the internal documentation I’m lucky enough to have access to, but you must definitely have a look at the following:
- Windows Internals (a must have for every serious developer)
I think that’s enough for this first post, just a short introduction of what I’ll try to explain in the upcoming weeks; by the way, if you have any topic about managed debugging you’d like me to discuss, feel free to drop me an email of leave a comment. If we can add some interactivity to this thing, we’ll hopefully have something useful for everyone interested.
Carlo
Quote of the Day:
Imagination is everything. It is the preview of life’s coming attractions.
–Albert Einstein