A person emailed me requesting me to blog step by step instructions on how to get Asp .Net working on XP SP2, and to check the status for each step.

I thought this would be a lengthy blog, but on second thoughts realize there isn't anything very deep about Asp .Net debugging.

With SP2, you can run into two sets of problems with Asp .Net debugging - (a) Asp .Net deployment fails and (b) Debugging fails.

For the debugging, there are a number of blogs out there - my own blog lists how to get this going, and you have our Dev Lead's blog at http://weblogs.asp.net/andypennell/archive/2004/08/20/217933.aspx that also connects to Gregg's and mine blogs. The most comprehensive place I think is http://support.microsoft.com/kb/833977

For Asp .Net deployment, there aren't any issues particular to SP2 that I am aware of, but a simple search can find you common deployment errors and how to check the system to flush them out.

That leaves us with the problem of debugger errors with Asp .Net debugging on SP2.

First of all, make sure this is not an issue with deployment instead of debugger by running your project outside the debugger (Ctrl-F5 instead of F5).

Now, assuming that deployment works, debugging fails, confirm that this is asp .net specific by debugging another app (try attaching to notepad.exe, or your simple winforms app). For general debugger failure, refer to the links mentioned above.

Finally, if you have come this far, you are in a weird situation of specifically asp .net debugging failing. Open your application's web.config file and make sure the debug attribute is indeed set as described at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vxtskdebugmodeinaspnetapplications.asp

Now if you are still failing, it has to be due to failure to attach to aspnet_wp.exe or w3wp.exe or inetinfo.exe. Deploy your app, open processes window (Tools->Debug Processes), check Show System Processes and Show processes in all sessions if necessary, and then attach to the aspnet_wp.exe or w3wp.exe or inetinfo.exe as a native process.

If this fails, you have a permission problem. At this point, there is no other explanation for it. Check the access permissions of your user.

If this worked, we are having auto-attach problems. This really should not happen and should be a rare case and there is no specific solution to offer, you can read this blog from Gregg to see what is going on - http://blogs.msdn.com/greggm/archive/2004/07/15/184271.aspx . I am not sure how many people manage to get to this stage - where everything above is working, just F5'ing the project fails. Do let me know if any of you guys ran into this specific issue, and what your underlying cause or fix turned out to be. I would try restarting IIS, restarting mdm (iisreset, net stop mdm, net start mdm).

Oh boy, I wanted to fix some automation bugs today, but could not as I had to update my "commitments" for my performance review. And I need to go home and do my laundry.

Reviews at MS have changed as we officially become a "large company". Earlier we did not spend time worrying about commitments and what not - you simply listed the work you did and and got graded based on that. That was the whole review. My personal goal was as simple as "work hard(er), make money, have fun" (it was implied, I did not have to write it). Now we need to be mature corporate citizens and define goals accordingly.

Fortunately Microsoft has not reached the stage where you put in arbit goals like "I plan to proactively leverage my synergies to optimize my throughput all while valueing diversity" (I think this was Wally's [(c) Scott Adams, www.dilbert.com] goal), our goals still are precise, actionable and measurable, and I think I know that we have to evolve as a company, but part of me still feels nostalgic for the days when I could write my review in a couple of hours and there was very little MBA-speak involved.

I miss the dot-com era.

The security hardening in SP2 affects remote debugging since the firewall blocks machine to machine communication.

We have a workaround posted at http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;833977#2020 that lets you configure your machine to re-enable remote debugging.

There are a few mistakes in this KB article, however, which we are in the process of correcting.

These are the corrections :

The section "Workaround for Microsoft Visual Studio .NET 2002" that lists steps (1) to (7)  needs to be done for both VS 2002 and 2003, though it mentions only 2002. You should also do this right in the beginning.

Then you can turn on remote debugging, configure the Visual Studio .Net computer and configure the remote computer as described.

The newsgroups give us a good idea of which debugger features are causing the most problems for our users, but it is more difficult to gauge which features our users are using the most. I am guessing Breakpoints/Watch would probably be the at the top, with Modules being one of the less frequently used. I would be interested to know from some of the users here which features they use the most. This is again an ad-hoc sampling, but if you are posting here I bet you are a power user...

How frequently do you find yourself looking at the callstack? Using the command/immediate window? The processes window?