Two issues make debugging in the Microsoft Windows environment difficult and time consuming. The first issue is that debugging has always been a self-taught skill—you've basically been on your own to figure it out. Even if you have a computer science degree, I'm willing to bet that you never took a single college class dedicated to debugging. Other than some esoteric subjects, such as devising automatic program verification for languages that no one uses or developing debuggers for wildly optimistic, massively parallel-processing computers, the science of debugging as it applies to commercial software doesn't seem to be popular with the educational establishment. Some professors point out that you shouldn't be writing bugs in the first place. Although that's an excellent point and an ideal we should all strive for, reality is a little different. Learning systematic, proven techniques for debugging won't save you from ever writing another bug, but following these practices will help you to limit the number of bugs you add to your code and to track down those inadvertent bugs that do occur more quickly.

The second issue is that though many excellent books on specific Windows technologies are available, none of them cover debugging those technologies in enough depth to be useful. To debug any technology effectively, you have to know far more than a book focused on a specific technology provides. It's one thing to know how to write an ActiveX control to plug into Microsoft Internet Explorer—and another thing entirely to be able to debug that ActiveX control. To debug an ActiveX control, you have to know the ins and outs of ActiveX and the Component Object Model (COM), how dynamic-link libraries (DLLs) map into memory, and how COM goes about finding and creating controls. Some books make it look easy to implement sophisticated features, such as remote database connections, using the hot technology du jour, but when "db.Connect ("Foo")" fails in your Visual Basic program—and it always does—you're on your own to find and mend the broken link in the technology chain. Moreover, although a few books on project management do discuss debugging, they tend to focus on managerial and administrative issues rather than developers' concerns. Those books might include fine information about how to plan for debugging, but they don't help much when you're staring at a crash returning from a callback function.

The idea for this book came out of my trials and tribulations as a developer and manager trying to ship high-quality products on time. Over the years, I've learned skills and techniques that I use to deal with each of the two issues that help make developing Windows-based applications a challenge. To address the first issue, the lack of formal debugging training, I wrote the first part of this book to give you a crash course in debugging—with a decided slant toward commercial development. As for the second issue, the need for a book specifically on debugging in the Windows environment, I think I've provided a book that bridges the gap between specific technologies and nitty-gritty, real-world debugging techniques.