Debuggers
| I l @ ve RuBoard |
DebuggersDebuggers are truly the developer's bread and butter. Without these critical tools, it would be challenging to diagnose most runtime problems. We all know how difficult it can be to spot even minor errors in code. Without the benefit of runtime debugging, the challenge of development would be much harder than it is now. Thankfully, we don't have to worry about this possibility because there are more than enough debuggers to go around. In fact, the choices can be somewhat daunting. To simplify our discussion, I'll lump debuggers into two categories: the Visual Studio .NET debugger and everything else. Note You might ask, why talk about other debuggers? Isn't the Visual Basic .NET debugger good enough? It's true that the Visual Basic .NET debugger is very capable and full-featured , but it has some limitations. In addition, you must install Visual Basic .NET to get it. This is not usually feasible on a production server or typical client workstation. In these cases, the other tools can give you a lightweight way to diagnose problems regardless of where the application is. The Visual Studio .NET DebuggerThe Visual Studio .NET debugger, shown in Figure 10-1, is an extremely powerful and full-featured debugger and yet one of the easiest to use. You've likely used it many times. After all, when you build and run an application (by hitting F5), you're already using the Visual Studio .NET debugger. This is the debugger that Visual Basic developers most commonly use ” certainly through all of your development and some runtime testing. Figure 10-1. The Visual Studio .NET debugger with process dialog boxes open . The Visual Studio .NET debugger is designed to work well with simple projects and also provides a bevy of advanced features that can address a wide variety of needs. Here are some of these advanced features:
You can, of course, avoid all of these features if you don't need them. But it's nice to have the flexibility. Other DebuggersDebuggers can generally be classified into those that support managed code and those that don't. Table 10-1 compares some of the debuggers. All of the "classical" native debuggers, such as the Windows Debugger (WinDbg), don't understand managed code or managed stack traces. Another major distinction between debuggers is the user interface: some are console-based, and others are GUI-based. Their raw functionality might not very different, but they often use dramatically different syntax and commands. The console-based category of debuggers generally requires a better low-level understanding of debugging in general. Table 10-1. Debuggers and Supported Environments
Why turn to any of these debuggers? Remember that you do not always have the luxury of installing the Visual Basic .NET IDE on every machine your application is running on. All of the debuggers listed in the table are relatively lightweight and can be easily removed. This makes them extremely useful when you're working with production servers and client machines because you're unlikely to want or be able to install the full Visual Basic .NET IDE. If you're interested only in debugging managed code, CorDbg and DbgClr are great choices. Both of these debuggers are available with the .NET Framework SDK. You can install the SDK with Visual Basic .NET, but the SDK is also available in standalone form. The native debuggers are designed ”surprise ”to debug only native applications. All of these debuggers can be considered very sophisticated and hence rather obtuse and nonintuitive. But they are not without their uses. You should at least know they are available. All of the native debuggers I'll discuss here can be found in one easy place. By installing the Debugging Tools for Windows toolkit, you get three debuggers: CDB, NTSD, and WinDbg. You can go to the Debugging Tools for Windows page at http://www.microsoft.com/ddk/debugging/ to get not only this toolkit but additional information on how to get symbols to help you with your debugging efforts. The Microsoft CLR DebuggerThe Microsoft Common Language Runtime (CLR) Debugger (DbgClr.exe) is a managed GUI debugger. If you're most comfortable with a GUI system instead of a console-based application, the CLR Debugger is a great choice. Even if you aren't familiar with debugging managed applications, this debugger can be a great tool to help you learn the ropes and are comfortable enough to move to another debugger. The CLR Debugger is actually a subset of the Visual Studio .NET Debugger, so the interface should look somewhat familiar ”see Figure 10-2 ”but it is more lightweight and doesn't require installation of Visual Studio .NET (quite an advantage). It is a very capable managed debugger and is easy to use. If you're already comfortable with the Visual Studio .NET debugger, you'll be immediately comfortable with this tool. Figure 10-2. The Microsoft CLR Debugger. Unfortunately, this debugger is not without its limitations. Because it is only a subset of the Visual Studio .NET Debugger, it does not support all of the parent debugger's features. For example, it does not support remote debugging or native code debugging, and the Disassembly and Register windows aren't very useful. The CorDbg DebuggerCorDbg is a console-based managed debugging tool. (See Figure 10-3.) I love using this debugger, especially for performance and stress debugging. The simple interface, combined with a great set of debugging features, makes it an invaluable tool. CorDbg is by far the lowest -level managed debugger and is extremely lightweight (hence its usefulness in performance and stress scenarios). However, it also has certain limitations ”it can't be used to perform remote debugging, for example. Figure 10-3. The CorDbg command-line debugger. CorDbg is so named because it is an application that implements the ICorDebug set of debugging interfaces. If you have the .NET Framework SDK installed, you'll discover a wealth of low-level debugging samples and information. Microsoft even ships the source code for this tool so you can learn how the runtime debug API can be used. Unfortunately, the examples are in Visual C++ and are well beyond the scope of this text. The Microsoft Console Debugger and Microsoft NT Symbolic DebuggerThe Microsoft Console Debugger (CDB) and Microsoft NT Symbolic Debugger (NTSD) are both console-based and are meant for user-mode debugging. NTSD, shown in Figure 10-4, is virtually identical to CDB. The only difference is that it spawns a new window for the debugger instead of using the current console window. These debuggers are very lightweight and are very useful in debugging live applications or crashed dumps. Figure 10-4. The NT Symbolic Debugger. NTSD and CDB are not for casual debugging. Many of the commands and operations are fairly esoteric and hard to understand. I certainly would not recommend starting with these debuggers until you master the WinDbg debugger. The Windows DebuggerThe Microsoft Windows Debugger (WinDbg), shown in Figure 10-5, is a GUI-based debugger built on the foundation of the CDB and NTSD console debuggers. It is quite powerful and can be used to view source code, breakpoints, call stack, and so forth. Thanks to its GUI interface, more of the debugging features are more accessible to the casual user than with CDB or NTSD. This debugger's help system, although not always complete, makes the debugger much easier to use. Figure 10-5. The Windows Debugger in action. Although WinDbg is a GUI-based debugger, you can also use it from the command line. This is more of an advanced feature, so you should first attain a degree of comfort with the commands and options available through the WinDbg GUI.  |
| I l @ ve RuBoard |
EAN: 2147483647
Pages: 103