Visual Studio Hacks [Electronic resources] نسخه متنی

Hack 41. Debug a Running Process

Avoid having to re-create bugs by attaching
directly to a process that you started outside of the
IDE's control.

Have you ever found yourself 20
minutes into a test session when you find that you have
finally reproduced that bug that people have
been complaining about for months? But you're not
running in the debugger, so you'll never figure out
how you got the application in this state. By attaching to the
process directly without running your project, you can examine
memory, look at the call stack, and work out the bugall
without losing the state of your application.

5.7.1. Attaching to a Process

In
order to attach to a running process,
you first need to load the project you want to debug. For a Windows
Forms application or a service, simply select the Debug
Process menu item (for ASP.NET applications, see the next section).
Then select the process you wish to debug from the Processes dialog
shown in Figure 5-26. After selecting the process,
click Attach.

Figure 5-26. Process dialog

You are then prompted to determine which types of code you wish to
debug in the Attach to Process dialog, which is shown in Figure 5-27.

Figure 5-27. Attach to process dialog

You will almost always want to select Common Language
Runtime in the list of process types to debug. If you are debugging
client-side script and attaching to Internet Explorer, select Script
as well. Next, select OK and close the Processes dialog. Your IDE is
now connected to the process you selected. You can set breakpoints,
watch variables, and participate in any normal debugging task. If the
code is in a loop, the Debug Break All option will stop
the application wherever the current execution point is. You can then
examine the call stack and variables and determine what may be
broken.

5.7.2. Debug ASP.NET Applications Quickly

For

those writing ASP.NET
applications, the world is even simpler. You will always be attaching
to the same process, the ASP.NET worker process. Simply open
the Debug Processes dialog and find the
aspnet_wp.exe (or w3wp.exe
on Windows Server 2003) process as shown in Figure 5-28.

Figure 5-28. Select aspnet_wp.exe for debugging

It's always the same for all ASP.NET applications,
since all ASP.NET applications run inside the ASP.NET worker process
as opposed to individual processes.

In Windows Server 2003, you can have multiple application pools; each of these application pools has its own worker process or worker processes. All of these processes will be named w3wp.exe. This makes attaching to the right process somewhat difficult. Once you have identified the correct process based on trial and error, you can recognize it based on its ID.

Connecting to ASP.NET in this way gives you several advantages. You
can start debugging without reinitializing the application and thus
losing any in-process session or cache information.
It's also fasterby attaching to the process,
you don't have to wait for the browser to start or
navigate back to where you were in the application. When a bug is
discovered, you can simply attach to the process, place your
breakpoints, and refresh the browser window to start the debugging
session.

5.7.3. Special Considerations for Services

If

you
find yourself writing Windows services the only way to debug your
service is by attaching. Simply ensure that the Show System Processes
checkbox is checked, and attach to your service.

However, you will find it to be practically impossible to debug the
Start event of the service. The only
way to really debug this event is to put a call to
System.Threading.Thread.Sleep(1000) in the
beginning of the Start event to give you time to attach the debugger.
This should be done inside of a #debug block or
removed before you move the service to production. You could also add
a call to System.Diagnostics.Debugger.Launch(),
which would launch an instance of the debugger. Use whichever of
these solutions works best in your situation.

5.7.4. Detaching from a Process

Another
option the Debug Processes
dialog gives you is a choice of what to do when you are done
debugging your processthis is shown in Figure 5-29. Normally, ending debugging will kill a
Windows Forms application (assuming you started it from the debugger
rather than attaching to it as before), but that may not always be
desirable.

Figure 5-29. Options for detaching from a process

Simply select the process that you are working with and click either
the Detach (peacefully release it) or Terminate (stop debugging and
kill the application) button to disconnect the debugger in the
desired fashion.

5.7.5. Hacking the Hack

Remember
how

attaching to an ASP.NET
application is so easy because it's always the same
process? In fact, it's so easy that even a machine
can do itand you can write a macro to do it for you. Go to
Tools Macros and select Macros IDE. This will open the
Macro IDE which is a Visual Studio look-alike specifically for
editing Macros. Right-click on My Macros and add a new Module. Name
the module "Debugging" or something
similar. Then add the following code into the new module:

    Public Sub AttachToIIS( )
AttachToProcess("aspnet_wp.exe")
End Sub
Private Sub AttachToProcess(ByVal ProcessName As String)
Dim Processes As EnvDTE.Processes = DTE.Debugger.LocalProcesses
Dim Process As EnvDTE.Process
For Each Process In Processes
If Process.Name.Substring(Process.Name.LastIndexOf("\") + 1) _
= ProcessName Then
Process.Attach( )
Exit Sub
End If
Next
End Sub

Modify the name of the process to w3wp.exe if
you are using Windows Server 2003. Next, save the module and close
the Macro IDE.

Now, in your Visual Studio IDE, go to Tools Macros
Macro Explorer. Browse into your new module and find the
AttachToIIS macro. Double-click to run it, and
your project should attach to IIS and go into debugging mode. You
could then create a toolbar button and a keyboard shortcut for your
macro [Hack #51] . For those of you
who are writing a Windows Forms application or a Service and who
spend a long time working on the same application, you can clone the
AttachToIIS macro to create an
AttachToMyApplication macro.
(You'll also need to change the application name to
match the one you want to debug.)

Ben Von Handorf