Debugging Windows programs is a large, complex subject. A book that covered all possible aspects of Windows debugging could easily be twice the size of this book. The problem with such a comprehensive approach to the subject is that the results would be so large and intimidating that few people would want to read it. Consequently, we had to draw the line somewhere and focus on some aspects of Windows debugging at the exclusion of others. Let's start by explaining how we chose to draw that line.
The fundamental motivation behind this book is the belief that programmers' debugging skills could be much improved if they had access to better debugging information. Although plenty of debugging information is available, it is not currently in a form that a programmer can read and then have mastery of the subject. Too often the information is vague and incomplete, or the focus is on debugging tools instead of debugging concepts. The ultimate debugging tool is the programmer's mind, and too often that tool has been neglected. Mastering fundamental Windows debugging concepts will help you prevent many bugs and find the remaining bugs more efficiently, even if you are the most gung ho tool user.
This book identifies the fundamental debugging skills required for effective Windows debugging. Once you have read a chapter, you should have that chapter's subject wired. Part I of the book focuses on debugging strategies to help you understand the debugging process and how to use the C++ language, assertions, trace statements, and exceptions to prevent, reveal, diagnose, and remove bugs. Part II focuses on debugging tools included inVisual C++ as well as Windows. Part III focuses on debugging techniques to help you get the most out of Visual C++ debugging tools, with special attention to debugging memory-related problems, multithreaded programs, and COM.
Some subjects addressed here straddle the border between programming skills and debugging skills. However, since bug prevention is very much a part of debugging, you need to know the common programming mistakes in order to avoid making them. Most programming texts avoid the subjects of debugging and bug prevention, so these subjects need to be addressed.
What's missing in the presentation is also notable. We have largely avoided discussing third-party debugging tools or any Microsoft debugging tools that are not part of Visual C++ (such as WinDbg) or Windows. There are several motivations for this decision. The obvious motivation is to stay focused on debugging concepts and not get side tracked by documenting tools. Another strong motivation is that Visual C++ programmers need better information on how to use the tools they already have. Finally, we doubt that we could say anything about these other tools that would be more helpful than the information provided by the tool vendors themselves.
But I Use BoundsChecker . . .
Some readers are now thinking, "But I use BoundsChecker, so why should I read this book?" Excellent question. Debugging tools, such as Compuware NuMega's BoundsChecker and Rationale Software's Purify, do an excellent job of finding many types of runtime errors—bad pointers and handles, memory corruption and leaks, bad Windows API parameters, and so on. What they don't do is help you understand the debugging process, including how to use the C++ language, assertions, trace statements, and exceptions to prevent and remove bugs, how to take full advantage of the debugging tools that are part of Visual C++ Windows, or how to debug multithreaded programs and COM—all of which this book does.
Furthermore, these tools certainly do not detect all bugs, and they do nothing to help you prevent bugs. If you are totally dependent on debugging tools, you will be helpless when presented with bugs these tools don't find. In addition, using these tools requires you to perform an extra development step, and they can have a significant impact on runtime performance, whereas many of the bug-detection techniques described in this book happen automatically whenever you run the debug build and have a minimal impact on performance. Debugging is a complex puzzle, but these debugging tools will help you with only one piece.
How to Read This Book
Although our hope is that you will read this book from cover to cover, we realize that many readers are in a hurry and won't have the time to read a whole book in order to track down a bug. Consequently, each chapter is largely self-contained so you should be able to read only the chapters you need in the order you want. This self-containment approach means there are some bits of redundant material that apply to more than one chapter, although we tried to keep such redundancy to a minimum. We hope you will agree that this approach makes the book a much more useful reference.
After the Contents, there is a list of answers to frequently asked questions, which can quickly guide you to solutions to many common debugging problems. Chapter 8 is also organized in this way, and either the FAQ list or the chapter can help you quickly find an answer to a specific debugging question.
There are many different types of Windows programs, so there are many different types of debugging techniques. Debugging is presented from the point of view of the Windows API, as well as the MFC and ATL application frameworks. We have clearly identified the material that is specific to MFC and ATL; so if you're not using these frameworks, feel free to skip over those sections if you are in a hurry. If you're not in a hurry, you might want to read them because it is often useful to look at debugging from other points of view.
Finally, each chapter contains key points of advice about debugging, which are presented in a special format as shown here.
These tips highlight the most useful debugging ideas, make the text easier
to scan, and will help you locate important debugging topics quickly.
Windows Versions and Hardware
To simplify the presentation, we refer primarily to the current versions of Windows, which at the time of this writing are Windows 2000 and Windows 98. Almost everything said here about Windows 2000 applies to Windows NT 4.0, and nearly everything said about Windows 98 also applies to Windows 95. We mention Windows NT 4.0 and Windows 95 only when referring to those specific versions of Windows.
To further simplify the presentation, we assume you are using Windows on an Intel x86 central processing unit (CPU). Although most of this book is CPU independent, the specific CPU becomes a factor when you are reading hex dumps or debugging at the assembly-language level. For those of you doing assembly-level debugging on a non-Intel platform, you have our sympathy, but not much else.
Who Is "I"?
Although there are two names on the cover, we wrote this book using the first person. Each chapter tells its story from the point of view of a single author. Mike Woodring wrote Chapter 10, Debugging Multithreaded Programs, and Chapter 11, COM Debugging, whereas Everett McKay wrote the remainder. Consequently, the "I" in Chapters 10 and 11 refers to Mike Woodring, whereas the "I" in the other chapters refers to Everett McKay.
For Updated Information
Theinformation in this book is based on Microsoft Visual C++ version 6.0. If you are using a later version of Visual C++, chances are the majority of this book is still accurate but a few details related to the compiler or debugger have changed. To help keep this book's information fresh, we will post any updates or corrections at http://www.windebug.com, along with selected debugging tools. Should you find any errors or out-of-date information, please let us know by sending an e-mail message to corrections@windebug.com.
Format: Paperback, 592 pages
