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

Question

I have an ASP.NET website and when I press F5 it automatically attaches to the ASP.NET Development Server, how do I attach to IIS worker process instead when I press F5?

Willywilly

For anyone getting here looking for the process to attach to in order to debug ASP.NET applications, it's iisexpress.exe – Skilling

Answer 1

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.

Gorman

This only works for local IIS servers, right? Can't deploy/run/attach to worker process on a remote IIS server that way? (I ask this, because I'd like to be able to do that, but haven't found a reasonable method for doing so). – Authorize

Yes, local only. I think that to do what you are looking for would require you to publish the site, then attach to process on the remote machine. that requires remote debugger installed and probably some security headaches. Not fun.... – Gorman

Attach to process lies under "Tools" menu – Pasta

@nvrtheless - if you use "general development settings" when setting up the IDE, its also under Debug. I imagine it only shows under Tools if you choose a language specific IDE setup. – Gorman

There is very handy VS2013 extension called ReAttach: visualstudiogallery.msdn.microsoft.com/… It remembers all the processes you attached before, so you don't have to select them via "Attach to process". – Dialyse

Answer 2

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).

Lesko

my preferred way as this avoid opening of a new window - and also keeps any session state that I already have in an open browser. – Commendation

w3wp.exe also for IIS 6 (in Server 2003) – Skiba

What does it mean if the w3wp process isn't in the list? it was just there. then i did an iisrest and it's gone. – Bonnice

@towpse: make sure you've checked the box for all users and for all sessions since IIS runs in session 0 (for services) and isn't running as you. – Denominative

Also, the w3wp process spins up on demand, so after an iisreset there is no process running. When you make the first request to your site IIS spins up the worker process to handle the request. It's a PITA if your trying to debug something in Global.asax though. – Lesko

If you do not see w3wp.exe, make sure to tick "Show processes from all users" – Coker

Answer 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.

Righthander

Answer 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).

Upswell

Answer 5

go to the properties of the web application. Select the "Start Options" section, and change from "USe default web server" to "use custom server". Enter "http://localhost" in the base url.

(assumes VS 2008)

W