Chapter 3. Debugging

Faulty code has been with us since the dawn of computing. The first general-purpose stored-program computer to become fully operational was the EDSAC,^[1] built at England's University of Cambridge. Maurice Wilkes was in charge of this project and recalls that while writing the computer's first real application, "the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." If his 126-line program running within the confines of the EDSAC's 2-kilobyte memory capacity proved so difficult to debug, then what hope can there be for modern computer systems, which are many orders of magnitude more complex? Fortunately, debugging technology has improved since the 1940s.

^[1] ENIAC was completed first, but unlike all modern computers, it was unable to execute code out of its own storage—programs were quite literally hardwired. The Manchester Baby was the first computer with a "stored-program" facility ever to execute a program, but EDSAC was the first to execute production code for real applications.

Visual Studio .NET moves the state of the art of debugging forward. As you would expect, it provides all of the features we now consider mandatory in a debugging tool—source-level debugging, single-stepping, breakpoints, and variable watches. It also has many new and powerful features. Multiprocess and multihost applications can now be debugged from a single session. Multilanguage projects are supported. A single debugging session can deal seamlessly with code written in radically different technologies such as managed code, native code, and T-SQL. Web applications can now be debugged with ease.