A lot of the "attach debugger" macros I found only show you how to attach to the W3WP.exe process for debugging. Well  I run multiple sites under different app pools so I sometimes have multiple W3WP.exe's running and need to debug a specific one. In this case I wanted to attach to a specific IIS process.

First off note that I am using Windows Server 2008 R2 / IIS 7.5 and I have separate application pools for each site with different User Names for each process:

 

So I want to target the "test.testsite.com" process... Here's the Macro code:

(Code is in VB.NET)

The important line is:

If name = "w3wp.exe" AndAlso proc.UserName.Contains("test.testsite.com") Then

Just replace "test.testsite.com" with the user of the process you want to target.

Run the macro and it should attach to the correct W3WP.exe process.

If you do a lot of debugging with Fiddler you probably know it doesn't capture any data when you run your website on your loopback address (http://127.0.0.1 or http://localhost). Well there's a simple way to get around this as outlined in this blog post. Enjoy!

I've finally been making headway on my project. It's been slow and I haven't been able to devote much time to it recently but it is coming along and it looks sweet!

Anyways, I read a recent post on Mads Kristensen's blog about debugging JavaScript in Visual Studio 2005. I've been debugging JS in the method described on his blog for quite some time now and thought I would share some tips I picked up on.

Tip #1: Debugging inside an iterator
The problem is I was using Prototype 1.5.0's extensibility to work with my arrays. There are quite a few iterators that were introduced in Prototype including (to name a few) .each and .find. These two iterators allow you to iterate through each item in your array. Here is a quick example of how these functions are used:

[1,2,3,4,5].each(function(w) {  // This will show 5 alert boxes
        alert( w );
    }
);

[1,2,3,4,5].find(function(w) {  // This will return 3
        return w == 3;
    }
);

Placing a breakpoint on the alert( w ); line actually breaks on the entire function. So you can't get into the iterator to see where your issue is. Instead you'll get an error message further down the line in Prototype's method .each. So an easy way to break into the function and see what's happening every iteration is to use debugger; in your JS like so:

[1,2,3,4,5].each(function(w) {  // This will show 5 alert boxes, breaking before each alert
        debugger;
        alert( w );
    }
);

Tip #2: Quick Watch, Add Watch
Yes! You can use Visual Studio's Watch windows to see your JS values, methods, properties, etc... Just break into the debugger and highlight your variable, right-click and select either Add Watch or Quick Watch (or you can just hover over the variable for a second or two). You can then see all methods, properties, values and etc belonging to that object. This helps tremendously when that hard to find JS bug comes up.

Tip #3: AJAX and Web Services
Finally, you can debug your AJAX Web Service calls too! Just use the same methods mentioned above to debug JS and you can step into, over and through all of your JS code, including your ScriptResource.axd and Web Service scripts!