第 131 页

< system.web >

< compilation debug="true" / >

< /system.web >

< /configuration >

ASP.NET automatically detects any changes to web.config settings and applies them immediately.

Therefore, you don’t need to restart the computer or the IIS service for this change to take effect.

As discussed in Chapter 42, this change can have an adverse affect on performance, so you should

never leave it enabled in production.

Once you have enabled debugging you can attach to the web application. The process you’ll need to

attach to is the ASP.NET worker process, which will either be the native process within IIS (called

w3wp.exe for IIS 6.0 or higher, or aspnet_wp.exe on older versions of IIS) or the built-in Visual

Studio 2010 development server WebDev.WebServer.exe.

Because the IIS process normally runs under the ASPNET or NETWORK SERVICE

account, you will need to be running Visual Studio with Administrator rights to

attach the debugger to it.

To begin debugging, select Attach to Process from the Debug menu in Visual Studio 2010. Select

the Show Processes in All Sessions checkbox if you are attaching to ASP.NET under IIS. Locate the

ASP.NET worker process from the Available Processes list and click the Attach button. As shown in

Figure 43-6, you may be prompted to restart Visual Studio with elevated rights.

894 .

chaPter 43 AdVAnced debugging TechniQueS

fiGure 43-6

remote debugging

Remote debugging enables you to attach to an application that is executing on another machine.

This can be useful for those cases where a bug is manifesting itself only on a non-programmer’s

computer, or if you need to debug a Windows Service or ASP.NET web application that is running

on a production server.

Debugging a remote application is no different from debugging a local application. Once you have

attached to the remote application you can set breakpoints, watch variables, and step through code.

However, before you can attach to a remote process you must ensure that the Remote Debugging

Monitor is running on the machine to be debugged.

The Remote Debugging Monitor, msvsmon.exe, is a small executable that is shipped with Visual

Studio 2010. By default you will find the 32-bit version installed in the directory C:\Program

Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86.

The x64 version of msvsmon.exe is not installed by default with Visual Studio

2010 unless you are running a 64-bit version of Windows. The IA-64 version of

msvsmon.exe is available only with Visual Studio Team System.

You can simply copy this folder over to the remote machine and run it locally, or create a share

and run it from a UNC path. You can also choose to install the Remote Debugging Monitor on the

remote machine by running the setup MSI file that is on the Visual Studio installation DVD media

under the Remote Debugger directory.

Debugging running applications .

895

When you launch msvsmon.exe on a remote

computer for the first time, it attempts to

configure the Windows Firewall to open the

network ports necessary to enable remote

debugging. In some environments, such as

on a Windows Server 2003, it prompts you

to make the necessary changes as shown in

Figure 43-7. On the Developer’s machine,

Visual Studio makes the necessary changes to

the Windows Firewall to enable it to connect

to a remote machine.

Once you have started the Remote Debugging Monitor it simply listens on the network for incoming

debugging requests. By default, remote requests must be authenticated, and only users who are

Administrators have the necessary permissions to attach and debug applications. These security

settings can be changed from the Tools . Options menu, as shown in Figure 43-8.

fiGure 43-7

fiGure 43-8

If you enable the No Authentication mode, your machine will be vulnerable

to any user on the network. A remote user could launch applications on your

computer, access data, or perform untold mischievous or destructive actions by

using a debugger. You have been warned!

Once you have the Remote Debugging Monitor running on the remote machine, you can attach to

an application on that machine through the Debug . Attach to Process menu. Enter the computer

name or IP address of the remote machine in the field marked Qualifier. Visual Studio will connect

to the Remote Debugging Monitor, authenticate you, and finally display the list of processes

running on the remote machine. Simply select a process to attach to and you will be able to debug as

if you had attached to a local process.

896 .

chaPter 43 AdVAnced debugging TechniQueS

net fraMework source

One of the more interesting trends that has emerged from Microsoft in recent years is an increased

openness and even willingness to embrace open source. The ASP.NET MVC Framework, covered

in Chapter 21, is a good example of this, because the source code for this has been released as a

buildable Visual Studio project solution.

However, arguably more significant than this has been the release of the source code for a large

number of base class libraries in the .NET Framework. Available under the read-only Microsoft

Reference License, it enables you to step into and debug the .NET Framework code as part of a

debugging session. Though you could always infer the programmer’s intent by using Reflector, there

is no comparison to browsing the actual source code, including the inline documentation. The

really good news is that this documentation is quite comprehensive.

The source code is not available for every assembly that ships as part of the .NET

Framework, nor is it available for every version that has been released. For

the assemblies that are available, there has often been a delay between when the

framework was publicly released and when the source code became available. You

can find the list of currently available assemblies at http://referencesource.

microsoft.com/netframework.aspx.

The first step to enabling access to the source code is to configure some Debugger settings. Open the

Tools . Options menu item and select the Debugging category. If you are using the Visual Basic

Profile, you ’ ll need to select the Show All Settings option to see all these options. Ensure that the

Enable .NET Framework Source Stepping option is checked as shown in Figure 43 - 9 . When you check

this option you may be presented with two prompts; the first indicates that the Enable Just My Code

option has been disabled, and the second advises that a symbol cache location default has been set.

Secondly, navigate to the Symbols category in the Options dialog (see Figure 43-10) and check the

symbol cache location that was automatically added. You can modify the cache location if required,

but ensure that you have full read/write access to the target directory. If you are configuring

these options while running in Debug mode, you also have the option to download the symbols

immediately by clicking the Load all symbols button. Otherwise, if you are not running a debug

session, the symbols applicable to the current project are downloaded as soon as you click OK.

fiGure 43-9 fiGure 43-10

Multi-Threaded and Parallelized application Debugging .

897

You will now be able to step into and browse the .NET Framework base class libraries during

a debugging session. Set a breakpoint in your application code and run in Debug mode. When

the breakpoint is hit, open the Call Stack window (Debug .

Windows . Call Stack) to display the

execution path. If the symbols have been loaded, the code that is available for debugging will not be

grayed out, and you will be able to double-click the entry in the Call Stack, or step into the source

code during your debug session, as shown in Figure 43-11. If this is the first time you are viewing

the code, you are prompted to accept the Microsoft Reference Library license.

fiGure 43-11

Multi-threaded and Parallelized

aPPlication debuGGinG

Multi-threaded applications have traditionally been notoriously difficult to debug properly.

Seemingly fundamental tasks, such as keeping track of which thread you are currently inspecting

and what other threads are currently executing, are some of the reasons why this task is so hard.

Fortunately, Visual Studio 2010 has improved the support available for debugging multi-threaded

applications.

Chapter 39 discussed the Threads debug window, which lists all the active threads for a particular

application. Functionality accessed through this window includes the ability to set a friendly name

for a thread. You can also set flags on individual threads, which means that you don’t have to spend

as much time trying to keep track of thread IDs.

To further improve debugging, you can now identify each thread within the source code editor

window. This is enabled from the Threads window by right-clicking any entry and selecting Show

Threads in Source. The result of this is shown in Figure 43-12, where a cloth thread icon (consisting

of a red and blue wavy line) is displayed in the gutter. The thread icon indicates that a thread,

or several threads, is stopped at this location. When you hover over the thread icon, a tooltip is

displayed that identifies which threads are stopped here. The thread names listed are the friendly

names that have been entered in the Threads window.

898 .

chaPter 43 AdVAnced debugging TechniQueS

fiGure 43-12

Within the Debug Location toolbar, shown in Figure 43-13, you can navigate between threads.

When you select a different thread from the Thread drop-down list, the Call Stack is updated with

the selected thread’s execution path, and the execution point is moved to the current location in the

source code. The call graph in the Parallel Stacks window will also be updated to reflect the newly

selected current thread.

fiGure 43-13

You can also flag both threads and tasks from the Threads and Parallel Tasks windows. Flagging

enables you to keep track of a thread or task within a debugging session, and filter out some of the

tasks or threads you are not interested in. In Figure 43-14, we have flagged the first two tasks in

the Parallel Tasks window. By selecting the Show Only Flagged option on the toolbar of the Parallel

Stacks window, we have filtered the call graph to hide the tasks that we are not interested in.

fiGure 43-14

Mixed-Mode Debugging .

899

Though debugging multi-threaded and parallelized applications is still not a trivial task, these

features do make it much easier to drill down on specific threads and tasks, and filter out the

unimportant information from the Visual Studio debugger windows.

debuGGinG sql serVer stored Procedures

Another very useful feature of the debugging

model found in Visual Studio 2010 is the

capability to debug stored procedures in SQL

Server databases. You’ll need to first check

the Enable SQL Server Debugging setting

in the Debug property page of your project,

as shown in Figure 43-15. Once activated,

whenever your code encounters a stored

procedure, you can debug the procedure code

inline with your own code.

You can even include breakpoints within a

stored procedure so you can trace through

the SQL Server code without halting the

application code execution.

Your Windows account must be a member of the sysadmin group on SQL Server in order to debug

stored procedures.

Mixed-Mode debuGGinG

A mixed-mode application is any application that combines managed code (Visual Basic, C#,

Managed C++, and so on) with native code (typically C++). Debugging a mixed-mode application

is not all that different from debugging a pure managed-code application; however, you must first

configure the application to support native code debugging. Figure 43-15, in the previous section,

shows the unmanaged code debugger enabled, along with the SQL Server debugger.

Mixed-mode debugging has a couple of limitations that you should be aware of. First, it is only

available on Windows 2000 or higher operating systems. Also, when debugging a mixed-mode

application, you may find that some operations, such as stepping through code, run very slowly.

This can be improved by unchecking the option to Enable Property Evaluation and Other Implicit

Function Calls in the Debugger option page.

fiGure 43-15

Because native call stacks and managed call stacks are different, the debugger

cannot always provide a single complete call stack for mixed code. Though rare,

it is possible that there will be some discrepancies in the call stack. You can find

more information on this in the MSDN library.

900 .

chaPter 43 AdVAnced debugging TechniQueS

Post-MorteM debuGGinG

Even with the most well tested of applications, it is inevitable that there will be latent bugs within

your code that will show up after the software has been released. Fortunately, it is possible to debug

many of the errors on user computers after they have occurred.

Post-mortem debugging involves inspecting a dump of the application’s memory that was taken

when the error or unexpected behavior occurred. This could be when an unhandled exception is

thrown, or if the application enters a hung state, or simply if the application is exhibiting behavior

that indicates it may have a memory leak.

In the past you would use tools such as WinDbg with the Son of Strike (SOS) extension to debug

memory dumps of .NET applications. However, WinDbg was designed for native code debugging,

and even with the additional support provided by SOS it was still difficult to perform tasks such as

matching the MSIL back to the source code.

Visual Studio 2010 and .NET Framework 4.0 have introduced new functionality that makes it much

easier to debug memory dumps of .NET applications.

Post-mortem debugging, as described here, only works for .NET version 4.0

applications and web sites. It is also much better if your application is compiled

in a debug configuration. If not, you will not have access to a lot of very useful

information.

Generating dump files