How do I attach the debugger to IIS instead of ASP.NET Development Server?

Solution 1:

Debug->Attach To Process...

Select the aspnet_wp.exe process from the list.

If you're running IIS > version 5 the process will be w3wp.exe, and there will be one for every app pool (so if you don't know which app pool you're hitting, you'll need to attach to all of them).

Solution 2:

open project properties, go to the web tab and choose the option for IIS.

That actually starts an instance of the app in IIS and attaches the debugger. If you only wanted to attach to an existing IIS instance, choose attach to process from the debug menu.

Solution 3:

Debug -> Attach to Process from the VS menu.

In order to know to which w3wp.exe process to attach you can use the following command on a 2008 server

c:\%systemroot%\system32\inetsrv\appcmd list wp

While on windows 2003 it is

c:\%systemroot%\system32\cscript iisapp.vbs

For more info see IIS Application pool PID.

However if you have access to the task manager (taskmgr.exe) you can see there directly the name of the process along with the process ID, and in most cases the "user name" column of the process will be the same as the application pool name, (of course you have to set these columns to be visible in task manager in order to view the information).

But note that all of the methods will display only the processes that are currently running, which means that if your particular process has shut down due to idle time you have first to use the site in order to bring the process up in the list.

Also if the application is a "Web Garden" (which has more than one w3wp.exe) then even after attaching to the correct process there is still no guarantee that the breakpoints will be hit, since traffic to the site might be directed to another process.

Also note that if you attach to an application that runs in release mode, it will now instead run in debug mode, which means for example that there will be no timeout limitations (which might be a bit of a problem if you are actually trying to troubleshoot a timeout error).

If you want to attach to a remote process here is the best practice:

1. Make sure that the firewall is not blocking by opening the relevant ports or completely disabling it (just remember to turn it on again when done).
   
2. You should have a windows domain account with administrative privileges on the remote machine or have an account - with the same username and password as the local machine which is running VS - on the remote machine.
   
3. On the machine that has VS installed navigate to (Visual Studio Install path)\Microsoft Visual Studio (current version number)\Common7\IDE\Remote Debugger(Remote Machine Version), and copy and paste this folder to the remote machine or share this folder so that it is accessible from the remote machine.
   
4. On the remote machine log in as the same user as the local machine (see step 2) from there navigate to the copied or shared folder of step 3, and right click on "msvsmon.exe" and from the context menu select "Run As Administrator".
   
5. The Remote Monitor should start up and claim that it started a server usually by the name of (user)@(remote machine) or any other name.
   
6. In VS select Debug -> Attach To Process from the menu, leave the transport on "Default" and for the "Qualifier Name" enter the name from step 5.
   If everything goes correctly this will bring up the list of processes on the remote machine.
   

Of course there is a lot more in this subject, and for debugging native code the process might be even simpler, but the steps I have listed here should work in every case.

For farther information you can take a look on http://www.codeproject.com/KB/aspnet/IISRemoteDebugging.aspx or on the MSDN, as well as many posts on this site.

Hope this will help.

Solution 4:

Or you can use one of the Attach to IIS plugins to Visual Studio.

My preferred extension is VSCommands (for VS 2010 - 2012 or 2013, but not 2015 yet) or ReAttach (works in 2017).