ASP.NET web application from Visual Studio. Visual Studio has its own ASP.NET engine, which is capable enough to run and debug your web sites inside Visual Studio. However, if your site is hosted on IIS and you want to debug that site directly, how would you debug it? When we host sites on IIS, the Worker Process (w3wp.exe) is used to run the web application. We need to attach to this particular process from Visual Studio to debug the web application. This article describes the overall idea of debugging an application using this method. It also describes the Worker Process, Application Pool and selecting a particular process if there are multiple Worker Processes running on IIS, using
iisapp.vbs. I hope you will enjoy this article and provide your valuable suggestions and feedback.
When we run the application, execution breaks when certain a breakpoint is reached. It is very simple, because when an ASP.NET application is running in Visual Studio, it is under the control of the ASP.NET Engine which is integrated with Visual Studio. If you want to check which process is running for debugging, run the web application from Visual Studio: you will get a popup notification as shown below.
Fig. 1: Taskbar popup when debugging is started from Visual StudioThis indicates a process is starting to run the ASP.NET application. Double-click on the icon and a popup window will appear to show the details.
Fig. 2: Development Server process detailsBehind the running process is WebDev.WebServer.exe. When We press F5 to run the application, this process starts to execute the it. If you want run the application from command prompt, you have to perform the following steps.
Steps to run a web application from the command prompt:
- Open The Visual Studio command prompt
- Run WebDev.WebServer
Fig. 3: WebDev.WebServer usage notificationNow back to IIS debugging. IIS comes into the picture when we deploy or host the site. After deploying the site on IIS, if we want to debug the site there, we can't do it directly as in Visual Studio. IIS has its own
Worker Process which takes care of all execution and maintenance of deployed web applications. I will describe the details of the Worker Process in a later section. So, if we have running process in IIS and we need to debug the application, first of all we have to attach to the correct process from Visual Studio. Before describing that, let's just have a look at the Worker Process and Application Pool.
ASP.NET applications within IIS. All ASP.NET functionality runs under the scope of the Worker Process. When a request comes to the server from a client, the Worker Process is responsible for generating the request and response. Its also maintains the InProc session data. If we recycle the Worker Process, we will lose its state. For more information, read this article: A Low-Level Look at the ASP.NET Architecture
Fig. 4: Relationship between Application Pool and worker process in IIS
- Start Menu → Run command →
- Expand DefaultWebSites or Other Web Sites, where you have created the virtual directory
- Right Click on the virtual directory
- Click on Properties
Fig. 5: Virtual directory properties showing Application Pool nameIf you want to check the list of all Application Pools in IIS, you have to expand the Application Pool node on IIS Server.
Fig. 6: List of Application PoolsNow, each and every Application Pool should have the minimum of one Worker Process which takes care of the operation of the site which is associated with the Application Pool. Right-click on the Application Pool → go to the Performance tab, check near the bottom of the tab, there is a web garden section, and by default, the number of Worker Processes is 1. An Application Pool containing more than one Worker Process called a Web Garden.
Fig. 7: Application Pool properties showing Web garden
- Open the IIS Console, right-click on the Application Pools folder, select New
- Give the Application Pool ID and click OK.
- Now, right-click on the virtual directory and assign the newly created Application Pool to that virtual directory.
For the demonstration, I have created a web site called SampleWebSite and hosted it on to my local IIS. Below is default page output.
Fig. 9: Sample web site
Fig. 10: Task Manager showing the running IIS processNow we are going to attach to the process. In Visual Studio, go to Debug → Attach to Process
Fig. 11: Opening the Attach to Process windowAfter clicking Attach to Process, the following screen will come up
Fig. 12: Attach to Process window, showing a single Worker Process runningNow we are able to see that the Worker Process is running, and we need to attach that process. Select the process and click on the Attach button. After that, look at the two images below:
Fig. 13-1: Process attached successfully
Fig. 13-2: Process not attachedDid you notice the breakpoint symbol? If the Worker Process attached successfully, within the code, the breakpoint symbol should be a solid circle. Otherwise it will have a warning icon as shown. For a single Worker Process, this scenario is not common. However, when we have multiple Worker Processes running on IIS, then we can have some confusion. I will discuss the same in a later section.
Now if we click the Debug button after successfully attaching to the process, execution will stop at the breakpoint.
Next, let's have a look at what to do if we have multiple Worker Processes running.
sites hosted on IIS, and those sites have their own Application Pool. Now, multiple Application Pools means multiple Worker Processes are running.
Here I have three Application Pools in my IIS. They are:
- Default Application Pool
- Generic Application Pool
- State Server Application Pool
Fig. 14: List of multiple Worker ProcessJust have a look, there are three Worker Processes currently running, and you have to attach one of them. But, you do not know which Worker Process is the default Application Pool's. What you do is, you select any one of them at random, let's say the one with process ID = 4308
,and suppose it is not the Worker Process for the default Application Pool. So what will happen if you attach to a wrong process? Check the image below:
Fig. 15: Breakpoint when the process is not attached correctly
- Start → Run command → cmd
- Change directory to \Windows\System32
- Run the command:
Fig. 16: List of running Worker Processes with PID and Application Pool name
1772, so Attach to that process.
Fig. 17: Attach the correct process for debuggingNow, enjoy debugging!
Fig. 18: Breakpoint is ready