Summary

The Visual Studio .NET debugger has many powerful features for debugging, and this chapter introduced you to a set of features for native debugging. The most important conclusion you should have drawn from this chapter is that the debugger can do a considerable amount of work for you if you know how to utilize it effectively. You should strive to make the most of the Visual Studio .NET native debugger so that you can minimize the time you spend in it.

The native enhancements to advanced breakpoints help you avoid the tedium often associated with native debugging by allowing you to specify exactly the place and conditions under which a breakpoint triggers. The context part of the advanced breakpoint syntax is what you use to tell the debugger the scope and exact position of the breakpoints. The pseudoregisters, especially $TIB and $ERR, allow you extra power for your conditional expressions. The global data breakpoints let you set a hardware-assisted breakpoint memory location; then when that data location is written to and changed, the breakpoint fires. Additionally, the hardware breakpoint class provided by Mike Morearty allows true read and write breakpoints in your code.

The Watch window, with its wonderful flexibility, is where you can do amazing things to speed up your debugging. In addition to letting you change your variable values, the Watch window offers all sorts of formatting options so that you can view your data precisely the way you want to. The Watch window also lets you call functions in your program from the debugger. This feature allows you to create and use special debugging functions to automate your most tedious debugging tasks. Additionally, the ability to easily add your own type expansion and HRESULT values will save you many hours of debugging. Finally, the new EEAddIn model, where you can add your own custom display by having your DLLs called by the Watch window, opens up a whole new world of data display.

Although native debugging can take advantage of the excellent DCOM remote debugging, the Pipes solution unique to native debugging has some excellent features. Remote Pipes debugging now allows you to start processes under the debugger on remote machines, which will come in extremely handy for those developers working on large client applications. Additionally, with Pipes debugging, you can attach and debug multiple processes on the remote machine.

The second half of this chapter presented the Intel CPU assembly language that you need to know to survive in the Disassembly window. It started by covering the basics of Intel CPUs, such as setting registers and interpreting status flags, and then moved on to the instructions required to manipulate stacks, data, pointers, and strings; compare and test operands; and jump, branch, and loop, among other actions. After the assembly-language code were tips and tricks that will help you get the most out of debugging at the assembly-language level.

Being able to read assembly language makes all the difference in the world when you're in the debugger trying to figure out why your program crashed. Despite the fact that some people try to avoid it like the plague, assembly language isn't that hard, and there's certainly nothing mysterious about it. The information in this chapter will give you the power to solve many nasty bugs that once stumped you.