Category list

Conclusion

I l @ ve RuBoard

Conclusion

As you've seen in this chapter, Visual Basic .NET implements its security infrastructure via the key components in the .NET Framework model. However, it doesn't eliminate the need for careful design and development of an application with due attention to security. When you use Visual Basic .NET to implement custom permission objects, authorization mechanisms, or any security relevant functionality, you must be familiar with the .NET Framework's architecture. Good practices in security deployment and administration ”strong account management policies, patch management, lockdown operation, and so forth ”are still important. The most secure applications will take advantage of the best of security in Windows and .NET because they offer different perspectives. Using the STRIDE model to develop application threat models can give you further guidance about which platform to use in which situations.

A frequently heard phrase among Microsoft security developers is "security job = job security." Given that applications have evolved from simple, static data-manipulation channels into complex, dynamic, translation-oriented pillars of commerce, this statement is probably not too far from the truth.

I l @ ve RuBoard

Part III: Performance and Debugging

Essential Debugging Techniques

Common Performance Issues

The Art of Performance Tuning

I l @ ve RuBoard

Chapter 10. Essential Debugging Techniques

The techniques used to debug Microsoft Visual Basic .NET are varied and can be quite complex. In addition to the simple concept of a debugger, the .NET Framework also provides a set of tools that you can leverage to diagnose and instrument your applications. The essence of debugging is to discover the root cause of a failure. In certain situations, this can be a simple process and debuggers can be extremely helpful tools. But debuggers are not always appropriate. When they are not the answer, you need to do other things to diagnose the problems. That's what this chapter is all about.

I'll first give you an overview of the common Windows debuggers. Then we'll look at what you can do within your own applications to leverage the .NET Framework to simplify not only debugging but also diagnosing general application problems and failures. This is of critical importance when you either don't have debuggers available or the debuggers alone are not helpful in tracking down problems.

I l @ ve RuBoard

Debuggers

Debuggers 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 Debugger

The 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 .

graphics/f10pn01.jpg

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:

Remote debugging

This allows you to launch and debug a program stored on a remote machine. On the remote machine, you must install the Remote Debugging Components from Visual Studio .NET. You do not, however, need to install the complete Visual Studio .NET ”just a small subset. There are some additional requirements that you need to be aware of. First, you need to select the DCOM protocol to debug Visual Basic .NET applications. In addition, the user context the debugger is running in must be a member of the Debugger user group on the remote machine. For more information, see "Remote Debug Setup" in the Visual Studio .NET help documentation.
Native code debugging

In addition to supporting your Visual Basic .NET managed code, the Visual Studio .NET IDE can also step into native code (if you have the symbols and source code). This can be extremely helpful in debugging interop scenarios.
Multiple-process debugging

You can use the same instance of the IDE to attach to many difference processes, local or remote. (But you must have access permissions.)

You can, of course, avoid all of these features if you don't need them. But it's nice to have the flexibility.

Other Debuggers

Debuggers 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

Debugger	Type	Managed	Native
Visual Studio .NET	GUI
CorDbg	Console
DbgClr	GUI
CDB	Console
NTSD	Console
WinDbg	Console/GUI

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 Debugger

The 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.

graphics/f10pn02.jpg

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 Debugger

CorDbg 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.

graphics/f10pn03.jpg

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 Debugger

The 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.

graphics/f10pn04.jpg

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 Debugger

The 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.

graphics/f10pn05.jpg

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