Introduction

Bugs suck. Period. Bugs are the reason you're subjected to death-march projects with missed deadlines, late nights, and grouchy coworkers. Bugs can truly make your life miserable because if enough of them creep into your software, customers might stop using your product, and you could lose your job. Bugs are serious business.

Many times, people in our industry portray bugs simply as annoyances. Nothing could be further from the truth. All engineers can point to projects with runaway bug counts and even to companies that have folded because they released software so full of bugs that the product was unusable. As I was writing the first edition of this book, NASA lost a Mars space probe because of a bug that snuck in during the requirements and design phase. While I was writing the second edition, a bomb was dropped on American Special Forces soldiers instead of the intended target because batteries were changed in GPS software, causing a programming error. The week before I wrote this introduction to the third edition, Microsoft released a software patch for a software patch that introduced a huge buffer-overrun vulnerability in Microsoft Internet Explorer 6. Although software bugs are starting to get more of their due, there's still a very long way to go until we have a development culture in which bugs are taken super seriously instead of as minor problems that just happen as a part of development.

My hope is that the information in this book will help you learn how to write your applications with fewer bugs in the first placeand that when you're required to debug, you can do it much faster. Without realizing it, most teams spend an average of 50 percent of their development cycle debugging. If you start debugging properly, you can drastically reduce that amount of time, which means that you'll ship your products faster. You can't cut corners when it comes to requirements gathering and design, but you can certainly learn to debug much smarter. This book takes a holistic approach to debugging. I don't consider debugging a separate step, but an integral part of the entire product cycle. I believe you need to start debugging in the requirements phase and continue through to the final release to manufacturing.

Two issues make debugging in the Microsoft .NET environment difficult and time consuming. The first issue is that debugging has always been a self-taught skillyou'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 code with 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 prevent you from ever writing another bug, but following the practices in this book will help you limit the number of bugs you add to your code and to track down more quickly those bugs that do occur.

The second issue is that although many excellent books on specific .NET technologies are available, none of them cover debugging 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 a Microsoft ASP.NET control that plugs into your ASP.NET page, but it's another thing entirely to be able to debug that ASP.NET control. To debug that ASP.NET control, you'll have to know the ins and outs of .NET and ASP.NET, how DLLs are put in the ASP.NET temporary cache, and how ASP.NET goes about finding those controls in the first place. Some books make it look easy to implement sophisticated features, such as remote database connections, by using the hot technology du jour, but when "db.Connect ("Foo")" fails in your programand it eventually willyou'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 on 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 corrupted database or a constantly restarting ASP.NET worker process.

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, and as a consultant trying to help others ship 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 Microsoft Windowsbased applications a challenge. To address the lack of formal debugging training, I wrote the first part of this book to give you a crash course in debuggingwith a decided slant toward commercial development. As for the second issuethe need for a book specifically on debugging .NETI think I've provided a book that bridges the gap between specific technologies and nitty-gritty, real-world debugging techniques.

I've been extremely fortunate to have had the opportunity to focus on debugging almost exclusively for the last eleven years. A few experiences have helped shape my unique perspective on the subject of debugging. The first experience was at NuMega Technologies (now Compuware), where I was one of the first engineers working on cool projects such as BoundsChecker, TrueTime, TrueCoverage, and SoftICE. While working at NuMega, I started writing the "Bugslayer" column in MSDN Magazine, and then I eventually left to write the first edition of this book. The fantastic e-mail exchanges and interactions I've had with engineers developing every type of application imaginable teaches me even more about the issues that engineers face today when shipping products.

Finally, the most important experience of all in shaping my view has been forming Wintellect, which gives me the chance to go out and help solve those amazing problems for companies all over the world. Imagine that you're sitting in some office at 2 A.M., you're out of ideas, and the client's going to go out of business if you don't solve the bugthis scenario can be scary, but it also gets your adrenaline flowing. Working with the best engineers at such companies as Microsoft, eBay, Intuit, and many others, is the best way I know to learn all sorts of great tricks and techniques for solving bugs.

Who Should Read This Book?

I wrote this book for developers who are tired of spending late nights at work debugging and want to improve the quality of their code and their organizations. I also wrote this book for managers and team leaders who want to develop more efficient and effective teams.

From a technical perspective, the ideal reader is someone who has one to three years of experience developing on the .NET or Windows platform. I also expect the reader to have been a member of a real-world development team and to have shipped at least one product. Although I don't care for the term, the software industry labels developers with this level of experience intermediate developers.

Advanced developers will probably learn a great deal as well. Many of the most enthusiastic e-mail messages I received about the previous editions were from advanced developers who didn't expect to learn anything. I was thrilled that the book was able to give them tools they could add to their toolboxes. Again, as in the previous editions, a wonderful group of friends named the Review Crew reviewed and critiqued the chapters before I submitted them to Microsoft Press. These engineers, who are listed in the Acknowledgments section of this book, are the crème de la crème of developers, and they made sure that everyone reading the book would learn something.

How to Read This Book and What's New in the Third Edition

The first edition focused on Microsoft Visual Studio 6 and Microsoft Win32 debugging. The second focused on Microsoft Visual Studio .NET 2003 and a completely new programming paradigm, .NET, along with native Windows development. This edition of the book focuses completely on .NET 2.0 and Microsoft Visual Studio 2005. For those of you still doing mostly native development, there will be another version of this book in the future that focuses entirely on native C++ development.

The first edition contained 512 pages just for native development, the second had around 850 for both native and .NET, and this edition consists of approximately 480 pages just for .NET. When I embarked on this .NET-only edition, I thought it was only going to be a partial rewrite, but it turned into at least an 80 percent rewrite. In Chapter 6, "WinDBG, SOS, and ADPlus" (the longest chapter in the book), the total shared text amounted to four paragraphs between the editions. Narrowing the book's focus and all the major changes in .NET 2.0 and Visual Studio 2005 caused a lot of the change. However, a major reason was all the wonderful e-mails and discussions I had with readers of the second edition and their excellent criticisms and suggestions on how to make the book better.

Code Samples

In the previous editions, the huge amount of code and utilities included with the book were something that everyone liked. The first edition had 2.5 MB of text source code, and the second edition had 6.9 MB. Even though the page count dropped with the .NET focus, Windows Explorer tells me that there's more than 9.7 MB of code for this edition! Remember, that's just text and supporting files, not compiled binaries. Several of the Review Crew said that the included code is bigger than most entire development books out there today. By the way, all of the code is brand new so it can take advantage of the .NET 2.0 features.

In the book I refer to source files that are part of the code samples with a ".\" in front of the directory. For example, when discussing the Connect.cs file in the WhoAmI add-in, which is in the WhoAmI directory where you install the source code, I show the file reference as .\WhoAmI\Connect.cs. Because of the many code references in the book's text, this saves having to read Book_Source_Code_Installation_Directory\WhoAmI\Connect.cs for each one.

Organization of This Book

I divided the book into three distinct parts. You should read the first two parts (Chapters 1 through 6) in order, because I build the information in a logical progression.

In the first part of the book, "The Gestalt of Debugging" (Chapters 1 through 4), I define the different types of bugs and develop a process for debugging that all great developers follow. I also discuss the infrastructure requirements necessary for proper team debugging. I strongly suggest that you pay particular attention to the discussion on setting up Symbol Servers and setting up Source Servers in Chapter 2, "Preparing for Debugging." Because you can (and should) do a tremendous amount of debugging during the coding phase, I cover how you can proactively debug as you're writing your code. The discussion on assertions in Chapter 3, "Debugging During Coding," should be the final word on the subject for. NET. To help you achieve the breadth and depth necessary to be a good debugger, in Chapter 4, "Common .NET Debugging Questions," I answer all the common debugging questions I've gotten since I wrote the last edition. I also included tricks on how to work around problems in Visual Studio so you won't pull your hair out wrestling with the tool.

In the second part of the book, "Power Debugging" (Chapters 5 and 6), I dive deep into all aspects of the two main debuggers you'll use in .NET development: Visual Studio and WinDBG. Visual Studio has undergone a substantial transformation compared to previous editions, and the power at your fingertips is astounding. Fortunately for me, the documentation does not do all the features justice, so I was able to dig deep and show you all sorts of amazing tricks for smarter and faster debugging with this wonderful tool. WinDBG, the Son of Strike (SOS) extension, and ADPlus are the tools that you'll use for the nastiest of production-only bugs. In Chapter 6, I've done my best to provide you with the direction you'll need to effectively use these tools even if you've never seen them before.

One thing I learned while working with developers from across the industryfrom the inexperienced to the very experiencedwas that they were using only a tiny fraction of the power of the Visual Studio debugger and almost none of WinDBG, SOS, and ADPlus. Although this sentiment might sound odd coming from an author of a book about debugging, I want to keep you out of the debugger as much as possible. As you read this book, you'll see that much of my goal for you isn't just to learn how to fix bugs and crashes but how to avoid them in the first place. I also want to teach you to use the debuggers to their maximum effectiveness because there will be times when you're forced to use them.

The last section, "Power Tools" (Chapters 7 and 8), discusses extending Visual Studio 2005 and building Code Analysis/FxCop rules. In the previous edition of this book, the Settings Master add-in proved hugely popular and I rewrote it to be even more powerful so you can apply project settings changes to all your projects at the click of a button. It's even easier to create new settings files, so making wholesale changes to your build is trivial. Additionally, I provide a new add-in, Hidden Settings, which exposes undocumented settings in the IDE so you can easily change their values. In Chapter 8, I tackled extending the undocumented Code Analysis /FxCop rules and came up with numerous rules that I felt should be part of any design guidelines.

In the previous editions, I offered a few sidebars about various debugging war stories I'd seen. I've added a few more war stories in this edition that I think you'll enjoy. I hope that by sharing with you some of the really "good" bugs I've helped solve (and some I've helped write!), you'll see the practical application of the approaches and techniques I recommend. I also want to help you avoid the mistakes that I've made.

System Requirements

To use this book, you'll need the following:

• Microsoft Windows 2000 SP4 or later, Microsoft Windows XP Professional, Windows XP Tablet PC Edition, Windows Server 2003, Windows XP Professional x64 Edition, Windows Server 2003 x64 Edition, or Windows Vista. There is no native code in the book's source code, so it should run on Windows XP Professional IA64 Edition and Windows Server 2003 IA64 Edition, but I did not have access to an Itanium-based machine for testing.

• For full functionality, you'll need Microsoft Visual Studio 2005 Team Developer Edition or Microsoft Visual Studio 2005 Team Suite. If you only have Visual Studio 2005 Professional, you will be able to build the utilities but not build or run any of the test code. The Visual Studio Express editions may be able to build the code, but I did not do any testing against them. Also, because the Visual Studio Express editions do not support any extensibility, they will not be able to use any of the macros or add-ins from Chapter 7.

What Comes with This Book's Sample Files?

As I've already mentioned, there's 9.7 MB of source files, and you can download the latest version at http://dtt.wintellect.com. Because the only way I know how to develop is to treat every project as a commercial project, I treated all the code as a library you would purchase (which in essence you've done by purchasing the book), so you have a full install and Readme.chm as you would expect. The tools and utilities that plug into Visual Studio 2005 also have a full installation. At Wintellect, we've been using this code in all our projects, and so have our clients. For example, several million lines of .NET code have been run through the Code Analysis/FxCop rules from Chapter 8, "Writing Code Analysis Rules" If you find this code good enough to use in your applications, I'm deeply honored.

The main installation file, Debugging.msi, runs in accounts with limited privileges so anyone can install it. The default installation location is the user's My Documents directory, but you can change that if you like. For more detailed information on building the projects, the change log, and links to all Web sites referred to in the book, read Readme.chm in the directory where you installed the program. Once you've done the main install, you can install WintellectToolsInstall.msi from an account with administrator privileges so you can include all the Visual Studio add-ins and tools for all users on the machine.

READ THIS! Running with Least Privileges

The first common question I answer in Chapter 4 is about why developers need to use only accounts that have user privileges. Let me make it simple: if you're logging on with administrator privileges, that's wrong! All the code in this book was developed and tested as a pure user under all the operating systems. Naturally, I also tested the code running with administrator privileges, just to be sure everything worked. If you are logged on with administrator privileges, some of the test code will fail because it assumes that you don't have access to items like the C:\Windows directory and other protected areas on the computer.

Feedback

I'm very interested in knowing what you think of this book. If you have questionsor your own debugging war storiesI'd love to hear them! Please don't hesitate to send e-mail to [e-mail]. Please keep in mind that I travel quite a bit and get a lot of e-mail, so you might not get an immediate response, but I will answer your e-mail messages. You will also want to subscribe to the Wintellog at http://www.wintellect.com/Weblogs/ because that's where I'll post notices about code updates and the like.

Thanks for reading, and happy debugging!

John Robbins
September 2006
Hollis, New Hampshire
Bob in 2020

Microsoft Press Support Information

Every effort has been made to ensure the accuracy of the book. Microsoft Press provides corrections for books through the World Wide Web at:

http://www.microsoft.com/learning/support/books

To connect directly to the Microsoft Press Knowledge Base and enter a query regarding a question or issue that you may have, go to:

http://www.microsoft.com/mspress/support/search.asp

If you have comments, questions, or ideas regarding the book or the CD-ROM or questions that are not answered by querying the Knowledge Base, please send them to Microsoft Press via e-mail to:

[e-mail]

or via postal mail to:

Microsoft Press
Attn: Debugging Microsoft .NET 2.0 Applications Editor
One Microsoft Way
Redmond, WA 98052-6399

Please note that Microsoft software product support is not offered through the above addresses.