You can perform minor car repairs with only a wrench and a screwdriver. However, that is wholly inadequate for fixing a major problem. Try replacing a transmission with only a wrench and screwdriver. It would be simpler to buy a new car. When debugging an application, you are the mechanic. Lightweight debug first. If a car is overheating, confirm the radiator has water before replacing the engine. Lightweight debugging a software application means using Visual Studio. Have a plan. Do not simply start by "kicking the tires." Debugging tools, especially the advanced debugging tools, can generate vast amounts of information. "Kicking the tires" would be akin to searching for a needle in a haystack. Start with a hypothesis. Validate that hypothesis, which narrows the cause of the potential problem and moves a step toward a solution. Based on what you have learned, refine the hypothesis. That should narrow the problem further. Continue on this path until the problem is resolved.
Let us review common debuggers, beginning with Visual Studio.
Visual Studio has a feature-rich debugger. Most Windows developers are familiar with the Visual Studio integrated development environment (IDE). Microsoft has invested considerable time and resources to create a competent user interface in Visual Studio. Ease of use is an important feature of Visual Studio. This includes features such as IntelliSense, refactoring, the object browser, class diagram, and more. One of the major advantages of using the Visual Studio debugger is the polished user interface. Plus, it is a user interface that most developers are familiar with. Despite being the preferred debugger for lightweight debugging, Visual Studio is a complete debugger. You can set breakpoints, view the call stack, watch variables, inspect code, and more. Advanced features, such as trace points, visualizers, and debug methods or classes, means Visual Studio can also be used for more than lightweight debugging.
Visual Studio is a great tool for debugging Web applications. This includes debugging server-side and client-side code. You can even debug stored procedures. Open the Web site in Visual Studio to begin debugging. From the Debug menu, select Start Debugging. In the web.config file, a Web application must have the <compilation debug="true"/> element and attribute to facilitate debugging. If this is not present, Visual Studio will alert the user with a dialog box explaining the problem when debugging is started. One option in the dialog box is Modify The Web.config File To Enable Debugging. Choose this option to automatically update the web.config file and continue debugging. Alternatively, you can open and update the web.config file manually.
You might also want to debug the client-side scripts of the Web application, such as being able to set breakpoints. Script debugging must first be allowed in Internet Explorer. From the Tools menu, select Internet Options. Click on the Advanced tab. In the Browsing group, clear the Disable Script Debugging (Internet Explorer) check box. If this option is selected, client-side debugging is disabled. When debugging, users will be notified with an alert message if the Disable Script Debugging option is selected. The dialog box will describe the problem and steps to follow to enable client-side debugging in Internet Explorer.
A debug version of an application can run differently than a release version. The debug version of a Web site has <compilation debug="true"> in the web. config file. This is mostly because of optimizations. Debug versions of applications are not optimized, while the release versions are optimized. Other than optimization, here are three major differences between a release and debug version of a Web application.
ASP.NET requests do not time out in debug versions of a Web application. When debugging, this provides an opportunity to debug an errant request. In a production environment, this could stall an application indefinitely. Requests on released versions of a Web application automatically time out at 110 seconds.
There is no batch compilation for debug versions of a Web application. Batch compilation means that, when the first page is requested, the entire application is compiled into a handful of assemblies. For example, .aspx, .ascx, and .asmx pages would be batch compiled into separate assemblies. Each page is compiled into a separate assembly with the debug version of a Web application. The code behind is also compiled into a separate DLL. Batch compilation is more efficient than compiling each page into a separate assembly. This will result in many more assemblies, which can fragment virtual memory and apply memory stress on the application.
For a debug version of a Web application, client-side code libraries and static images found in webresources.axd are not cached. They are downloaded with each page request. Developers avoid having to repeatedly flush the cache when debugging. For a release version of a Web site, these files are cached, which is more efficient.
For the aforementioned reasons, debug versions of a Web application will not perform or scale similar to a release version. This is a critical reason that debug versions of a Web site should not be installed on a production server. This is a common error and problem. You can disable this option on a production server by adding the <deployment retail="true"/> element to the machine.config file. This reverses <compilation debug="true"> on all Web sites on the production server. Here is an example of the tag:
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>Several debugging tools are installed with the .NET Framework. This includes DbgClr, Intermediate Language Disassembler (ILDASM), Son of Strike, mscorcfg, caspol, peverify, and more. The most useful of these tools for debugging are ILDASM and Son of Strike.
ILDASM is a popular managed debugging tool. ILDASM is the Microsoft Intermediate Language (MSIL) disassembler. You can also browse the internal structures of an assembly (.exe, .dll, .obj, and .lib) with ILDASM. This includes browsing IL code, metadata, and the manifest. Metadata includes namespaces, classes, methods, fields, attributes, and so on. ILDASM is both a graphical user interface (GUI) application and a command-line tool.
From the command line, you can perform round tripping with ILDASM. Round tripping is disassembling an assembly, making a change to the disassembled code, and then reassembling into a new assembly. When disassembling an application using ILDASM, you have the option to save the results to a text file. This text file represents a fully functional managed application. It is written in MSIL code. You can compile the text file and create a new assembly using the Intermediate Language Assembler (ILASM) tool. This is particularly useful for making minor changes when you do not have the original source code.
Reflector is a free tool and similar to ILDASM. However, Reflector has some additional features not available in ILDASM. For example, you can still disassemble an assembly to MSIL code. But you can also reverse engineer the MSIL of the source code, such as C# or Visual Basic .NET. Reflector also supports third-party add-ons, such as AutoDiagrammer, CodeMetrics, and Diff. This makes the product extensible. ILDASM does not support addons. Reflector was created by Lutz Roeder, who has recently sold the product to Redgate Software. Reflector is now available at www.red-gate.com.
Son of Strike (SOS) is the debugging extension for managed debugging, which is installed as part of the .NET Framework so it is on every machine. Debugging extensions are DLLs that expose debugging commands that can extend the behavior of a host debugger. The debugging extension for SOS is sos.dll. You simply load the debugging extension into a debugger. You can then access additional commands. Debugging extensions are standardized and must adhere to guidelines published by Microsoft. Both Windbg and Visual Studio support debugging extensions and consequently SOS. SOS exposes commands for advanced debugging of managed applications. This is accomplished through reading internal structures of the managed applications. The following is a list of some of the information available with SOS.
Detailed information on each generation and the large object heap.
A list of syncblk indexes, which is helpful in resolving deadlocks.
A list of objects on the finalization queue. These are the objects waiting for the destructors to be called.
Information on whether a method has been jitted.
A list of all the objects currently on the managed heap.
In Windbg, the following command will load SOS. It is loaded from the same directory as the current mscorwks.dll module. Mscorwks.dll contains the CLR. This means you are loading SOS for the current version of the .NET Framework.
.loadby sos mscorworks
You can also load SOS from a specific directory regardless of the .NET Framework version. Here is the command:
.load drive:directorysos.dll
Debugging Tools for Windows has already been mentioned several times in this chapter. Many of the debugging tools introduced in this chapter are part of that package. The link to download the Debugging Tools for Windows is as follows: http://www.microsoft.com/whdc/devtools/debugging/default.mspx.
Because the tools are updated regularly, download and install the Debugging Tools for Windows package periodically. These are some of the tools included with the Debugging Tools for Windows:
Windbg. Windbg is an advanced kernel and user-mode debugger. In Windbg, load the SOS debugging extension to perform managed debugging. Windbg has graphical user interface.
Console debugger (CDB) and NT Symbolic Debugger (NTSD). Both CDB and NTSD are console applications and user-mode debuggers. For user-mode debugging, they have similar functionality to Windbg. There is one primary difference between CDB and NTSD. CDB runs in the current console window. NSTD starts a new console window.
Autodump + (ADPlus). ADPlus is a vbscript that automates CDB to create dumps. ADPlus has two modes: crash and hang mode. ADPlus is discussed in further detail later in the chapter.
Global Flags (GFlags). Use GFlags to enable and disable advanced debugging features. GFlags is especially useful for debugging memory problems, application startup, and module load issues. The tool primarily uses the registry to configure debugging features.
Srcsrv.dll. Srcsrv.dll is the source server engine.
Symsrv.dll. Symsrv.dll is the symbol server engine.
The CLR Profiler, formerly known as the Allocation Profiler, plots managed memory in easy-to-understand graphs. Using SOS, you can obtain a myriad of information on Generations 0, 1, and 2 as well as the Large Object heap. However, interpreting the data presented can be challenging. This is an occasion where a picture is probably worth a thousand words. CLR Profiler can provide that view and is most useful for debugging memory leaks. You can download the CLR Profiler at the "CLR Profiler for the .NET Framework 2.0" page, which is part of the Microsoft Web site.
Windows Sysinternals is a Web site that hosts debugging, diagnostics, and other complimentary tools: http://technet.microsoft.com/sysinternals. Some of these tools are quite sophisticated. Other tools, such as BlueScreen, are just fun. Of course, you may have a practical usage for the BlueScreen screensaver that does not include scaring peers, friends, and family. Other tools, such as DebugView, ProcessMonitor, and the PSTools suite of tools, are helpful in debugging a variety of problems.
Sysinternals was created in 1996 by Mark Russinovich and Bryce Cogswell as part of Winternals LP. Mark is the coauthor, with David Solomon, of the book Microsoft Windows Internals, 4th Edition (Microsoft Press, 2004). Sysinternals is now a unit of Microsoft (see above link).
The following is a list of some of the more important tools available at the Windows Sysinternals Web site. Visit the Web site for the complete list.
DebugView. DebugView supports the viewing of debug output outside of a conventional debugger.
Strings. The Strings tool can scan a binary file for a string or sequence of characters.
Handles. The handles utility lists all the active file and directory handles. This includes listing the process that owns each handle.
Process Monitor. Process Monitor is a tool for monitoring system, registry, process, thread, and DLL activity.
TCPView. TCPView shows TCP and User Datagram Protocol (UDP) endpoints and which process owns each endpoint.
Process Explorer. Process Explorer displays a variety of information on active processes, such as DLLs that are loaded into the process, the process identifier, and memory requirements. The tool will also track which processes have a handle to a file or directory.
Now that the toolbox is complete with the correct tools, you are ready to begin debugging. In addition to tools, tracing can provide extra or complementary information.