Tarik Soulami - Inside Windows debugging: [practical debugging and tracing strategies]

One exciting aspect of software programming is that there are usually many ways to accomplish the same goal. Unfortunately, this also presents software engineers with unique challenges when trying to make the best design or implementation choice for each situation. Experience plays a major role, and the learning process is often progressive as one learns to avoid past mistakes. Sadly, though, experience is often a variable concept. I have met several software engineers who, after spending a very long time working on an area, still lacked a basic understanding of how it really worked beyond the repetitive day-to-day tasks they grew accustomed to. I have also met others who have perfected their craft in a field after only a few years of working experience.

This book introduces a few techniques for methodically approaching software development problems primarily using the two Swiss Army knives of expert Microsoft Windows developersnamely, the Windows debuggers (WinDbg) and the Windows Performance Toolkit (Xperf). By focusing on why features and components work the way they do in the system rather than simply on how they work or what they do, this book tries to accelerate the process of learning by experience and to minimize the number of mistakes made when approaching new problems. An important part of the process is learning to compare and contrast with known solutions to existing ones.

Software engineering is still inherently a practical science. (Some might even argue its an art rather than a science.) While there is certainly no substitute for real experience, the topic can definitely be approached with the same methodical persistence that works so well for other scientific disciplines. In fact, this approach works even better in software engineering because all behaviors can be explained rationally. After all, it is all just codewhether its your own code or code written by others that you end up consuming in your softwareand code can always be traced and understood.

Although this book deals with several architectural pillars of the Windows operating system as part of its debugging and tracing experiments, my main goal in writing it is less about covering those details and more about encouraging and developing this critical mindset. I hope to demonstrate how this approach can be used for solving a few interesting problems as part of this book, and that you continue to systematically apply debugging and tracing as you expand your learning beyond the topics directly covered here.

This book is not really about teaching native or managed code programming, either, although youll find several good coding examples in the companion source code. Because it takes an inside-out look at how to explore the system using debugging and tracing tools, this book will probably appeal more to software engineers with the desire to understand system internals rather than those with a need to quickly learn how to make use of a specific technology. However, I believe the approach and mindset it aspires to inculcate are applicable regardless of the technology or level of expertise. In fact, contrary to what many think, the higher the level of technology involved, the harder it becomes to grasp what goes on behind the scenes and the more expertise is needed in order to investigate failures when things inevitably go awry and require debugging skills to save the day. In pure C, for example, a call to malloc is just that: a function call. In C++, a call to the new keyword is emitted by the compiler as a call to the new operator function to allocate memory for the object, followed by code to construct the object (again, emitted by the compiler to possibly initialize a virtual pointer and invoke the constructors of the base classes, construct member data objects, and finally invoke the user-provided constructor code for the target leaf class). In C# (.NET), things get even more involved, because a one-line call to the new keyword might involve compiling new code at runtime, performing security checks by the .NET execution engine, loading the modules where the target type is defined, tracking the object reference for later garbage collection, and so on.