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.

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.

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.

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.

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.

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