Archive

Archive for the ‘IIS 7.0’ Category

How to increase debugging idle time in Visual Studio configuring IIS

March 12, 2012 1 comment

Background

When we are debugging any web application hosted in our local IIS using visual studio, we attach the worker process (w3wp.exe) and start debugging. It works fine when we are continuously doing step into (F11) and step over(F10) actions to debug the code. But i am sure that every developer has faced the situation when he/she is debugging the code for a long time and in some cases he/she is idle or not doing any step in or step over action and getting the error message from visual studio saying :

“The debugger stopped execution of code on the Web site. This caused Internet Information Services (IIS) to assume that the worker process stopped responding. Therefore, IIS terminated the worker process.” 

then we press “ok” and immediately visual studio stops debugging process. In that case, to debug the application again we need to start the debugging process from the beginning. This kills significant amount of development time and effort.

 

Why we get this error message?

IIS monitors the worker process by sending a periodic ping request. If the worker process does not respond in a timely manner, IIS terminates the process after a specific number of ping. Default timeout is 90 second and that why we get this error message.

 

Solutions

Configuring the application pool in IIS, we can easily fix this problem and can debug easily. There are two configurable way to solve this:

1. Setting the ping enable to false

Setting Ping Enabled to False stops IIS from checking whether the worker process is still running and keeps the worker process alive until you stop your debugged process.

2. Increasing the ping maximum response time

Setting Ping Maximum Response Time to a large value allows IIS to continue monitoring the worker process.

To do these follow the steps:

  1. Open IIS Manager .
  2. Click Application Pools.

3. In the Application Pools list, right-click the name of the pool your application runs in, and then click Advanced Settings.

4.In the Advanced Settings dialog box, locate the Process Model section, and perform one of the following actions:

  • Set Ping Enabled to False.
  • Set Ping Maximum Response Time to a value that is larger than 90 seconds

5. Click “Ok” to close the Advanced Settings dialog box.

6. Close IIS Manager.

 

IIS in depth

January 22, 2011 Leave a comment

Web server is used when we want to host the application on a centralized location and wanted to access from many locations. Web server is responsible for handle all the requests that are coming from clients, process them and provide the responses.

 
 

What is IIS ?

IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host your ASP.NET Web application. IIS has it’s own ASP.NET Process Engine  to handle the ASP.NET request. So, when a request comes from client to server, IIS takes that request and  process it and send response back to clients.

 
 


 
 

 
 

Worker Process:  Worker Process (w3wp.exe) runs the ASP.Net application in IIS. This process is responsible to manage all the request and response that are coming from client system.  All the ASP.Net functionality runs under the scope of worker process.  When a request comes to the server from a client worker process is responsible to generate the request and response. In a single word we can say worker process is the heart of ASP.NET Web Application which runs on IIS.

Application Pool: Application pool is the container of worker process.  Application pools is used to separate sets of IIS worker processes that share the same configuration.  Application pools enables a better security, reliability, and availability for any web application.  The worker process serves as the process boundary that separates each application pool so that when one worker process or application is having an issue or recycles, other applications or worker processes are not affected. This makes sure that a particular web application doesn’t not impact other web application as they they are configured into different application pools.

 
 

Application Pool with multiple worker process is called “Web Garden”.

 
 

Now, I have covered all the basic stuff like Web server, Application Pool, Worker process. Now let’s have look how IIS process the request when a new request comes up from client.

If we look into the IIS 6.0 Architecture, we can divided them into Two Layer

 
 

1.    Kernel Mode

2.    User Mode

 
 

Now, Kernel mode is introduced with IIS 6.0, which contains the HTTP.SYS.  So whenever a request comes from Client to Server, it will hit HTTP.SYS First.

 
 


 
 

Now, HTTP.SYS is Responsible for pass the request to particular Application pool. Now here is one question, How HTTP.SYS comes to know where to send the request?  This is not a random pickup. Whenever we creates a new Application Pool, the ID of the Application Pool is being generated and it’s registered with the HTTP.SYS. So whenever HTTP.SYS Received the request from any web application, it checks for the Application Pool and based on the application pool it send the request.

 
 


So, this was the first steps of IIS Request Processing.

Till now, Client Requested for some information and request came to the Kernel level of IIS means at HTTP.SYS. HTTP.SYS has been identified the name of the application pool where to send. Now, let’s see how this request moves from HTTP.SYS to Application Pool.

In User Level of IIS, we have Web Admin Services (WAS) which takes the request from HTTP.SYS and pass it to the respective application pool.

 
 


When Application pool receive the request, it simply pass the request to worker process (w3wp.exe) . The worker process “w3wp.exe” looks up the URL of the request in order to load the correct ISAPI extension. ISAPI extensions are the IIS way to handle requests for different resources. Once ASP.NET is installed, it installs its own ISAPI extension (aspnet_isapi.dll) and adds the mapping into IIS.  

Note : Sometimes if we install IIS after installing asp.net, we need to register the extension with IIS using aspnet_regiis command.


When Worker process loads the aspnet_isapi.dll, it start an HTTPRuntime, which is the entry point of an application. HTTPRuntime is a class which calls the ProcessRequest method to start Processing.


When this methods called, a new instance of HTTPContext is been created.  Which is accessible using HTTPContext.Current  Properties. This object still remains alive during life time of object request.  Using HttpContext.Current we can access some other objects like Request, Response, Session etc.


After that HttpRuntime load an HttpApplication object with the help of  HttpApplicationFactory class.. Each and every request should pass through the corresponding HTTPModule to reach to HTTPHandler, this list of module are configured by the HTTPApplication.

Now, the concept comes called “HTTPPipeline“. It is called a pipeline because it contains a set of HttpModules ( For Both Web.config and Machine.config level) that intercept the request on its way to the HttpHandler. HTTPModules are classes that have access to the incoming request. We can also create our own HTTPModule if we need to handle anything during upcoming request and response.


HTTP Handlers are the endpoints in the HTTP pipeline. All request that are passing through the HTTPModule should reached to HTTPHandler.  Then  HTTP Handler  generates the output for the requested resource. So, when we requesting for any aspx web pages,   it returns the corresponding HTML output.

All the request now passes from  httpModule to  respective HTTPHandler then method and the ASP.NET Page life cycle starts.  This ends the IIS Request processing and start the ASP.NET Page Lifecycle.


Conclusion

When client request for some information from a web server, request first reaches to HTTP.SYS of IIS. HTTP.SYS then send the request to respective  Application Pool. Application Pool then forward the request to worker process to load the ISAPI Extension which will create an HTTPRuntime Object to Process the request via HTTPModule and HTTPHanlder. After that the ASP.NET Page LifeCycle events starts.

This was just overview of IIS Request Processing to let Beginner’s know how the request get processed in backend.  If you want to learn in details please check the link for Reference and further Study section.

 
 

Categories: IIS 7.0

The web server process that was being debugged has been terminated by Internet Information Services (IIS)

January 22, 2011 Leave a comment

By default, debugging a website or web project within Visual Studio bring up the built-in server of Visual Studio. But, we do have a problem to change the server to an IIS instance. I recently switched to debugging on IIS on my Windows 7. Debugging works fine. The only problem is that if your code hit some breakpoint and if you leave the program in ‘break’ mode for more than 90 seconds, Visual Studio shows the following message:

 


 

 

After a bit tweaking around in the new IIS interface, I got the solution:

  • Open Internet Information Services (IIS) Manager.
  • From the server tree (the item with the name as the server name), choose Application Pools.
  • Choose the Application Pool corresponding to your testing IIS website (usually it has the same name as your IIS website)
  • Right-click and choose Advanced Settings.
  • From the Process Model node, change the Ping Maximum Response Time (seconds) to a comfortably higher value (I have set the value to 900 seconds which is 15 minutes).

     

Alternatively, you can also set the Ping Enabled property to False.

Apparently what happens is that the server keeps pinging the worker process and waits for a response. When in debugging mode, the worker process is affectively suspended, which results in the ping not being responded.

 

 

Making URL rewriting on IIS 7 works like IIS 6

December 25, 2009 Leave a comment

what is URL rewriting ?

URL rewriting is the process of intercepting an incoming Web request and redirecting the request to a different resource. When performing URL rewriting, typically the URL being requested is checked and, based on its value, the request is redirected to a different URL.

Making URL rewriting  on IIS7?

Upgrading to IIS 7 should be rather transparent, unfortunately that is not the case when it comes to URL rewriting as we knew it from IIS 6. In IIS 6 all we had to do was to add a wildcard mapping making sure that all requests went through the ASPNET ISAPI process. After this was done, one could create a global.asax file that would either pass requests directly through or rewrite the URL based on an internal algorithm.

1) Start by opening the IIS Manager and selecting your website.

2) Now enter the “Handler Mappings” section

3) Notice the “StaticFile” handler. Currently it’s set to match * and catch both File and Directory requests. If you look back at the first image, you’ll notice that the error message details that the handler causing the 404 error is the StaticFile handler. As I know that all my static files will have a file extension (also I don’t care for directory browsing), I’ll simply change my StaticFile handler so it only matches *.* – and only files.

What needs to be done now is that we need to map any and all requests to the aspnet_isapi.dll isapi file – just like we would usually do in IIS 6.

Add a new Script Map to the list of Handler Mappings and set it up like this:

The aspnet_isapi.dll file cannot be used as a Handler for websites running in the new IIS 7 Integrated Mode, thus we will need to make our website run in classic .NET mode. Right click your website node in the IIS Manager and select Advanced Settings. Select the “Classic .NET AppPool” and close the dialog boxes:

“Failed to Execute URL”, what a great descriptive error. Fortunately you won’t have to spend hours ripping out hair… As I have already done that – at least I’ll save a trip or two to the barber.

The problem is that the static files are being processed by the aspnet_isapi.dll file instead of simply sending the request along to the StaticFile handler. If you click the “View Ordered List…” link in the IIS Manager from the Handler Mappings view, you’ll see the order in which the handlers are being executed for each request:

When you add a new Script Map it’ll automatically get placed at the very top of the line taking precedence over any other handlers, including the StaticFile one.

What we have to do is to move our Wildcard handler to the very bottom, below the StaticFile handler. By letting the StaticFile handler have precedence over our Wildcard handler we ensure that any static files (matching *.*) gets processed correctly while any other URL’s gets passed along to our own Wildcard handler that’ll do the URL rewriting and make business work as usual:

URL Rewriting in the IIS 7.0

follow the below mention steps for URL Rewriting in the IIS 7.0.

  1. Open Properties of the Virtual Directory “website1” from IIS.
  2. Click on “Configuration”, from Virtual Directory Tab.
  3. Click on “Insert” from Mappings Tab.
  4. Add the following path,

a. “X:\WINDOWS\Microsoft.NET\Framework\v2.0.507\aspnet_isapi.dll” in Executable. (X is the Windows Drive. i.e. where the framework is installed”)
b. Uncheck the Option “Check that file Exist”.

URL Rewriting in the IIS 6

Follow the below mention steps for URL Rewriting in the IIS.

1) Open Properties of the Virtual Directory  from IIS.

2) Click on “Configuration”, from Virtual Directory Tab.

3) Click on “Add” from Mapping Tab.

4) Add the following path,

a. “X:WINDOWSMicrosoft.NETFrameworkv2.0.50727aspnet_isapi.dll”  in Executable.  (X is the Windows Drive. i.e. where the framework is installed”)

b. Type “.*” in Extension.

c. Uncheck the Option “Check that file Exist”.

Add the following code in Global.asax file

string[] arrPath;
string strPath = string.Empty;
string strUrl = string.Empty;
string strQS = string.Empty;
string strQrystr = string.Empty;

string strLocal = ConfigurationManager.AppSettings[“Local”];

protected void Application_BeginRequest(object sender, EventArgs e)
{
string str1 = “UrlRequest”;
string str2 = str1;

strQrystr = string.Empty;
strUrl = string.Empty;
setPath();

if (strPath.IndexOf(“.”) > 0)
{
return;
}
try
{
// ### Start – If main page(like http://localhost/websiteName/) then exit sub
if (strPath == “” || strPath == “/”)
{
HttpContext.Current.RewritePath(strLocal + “/Default.aspx”, “”, “”);
return;
}

strQS = Request.QueryString.ToString();

if (System.IO.File.Exists(Server.MapPath(“~/” + arrPath[1] + “.aspx”)))
{
strUrl = ConfigurationManager.AppSettings[“Local”] + “/” + arrPath[1] + “.aspx”;

if (arrPath.Length > 0)
{
for (int i = 0; i < arrPath.Length; i++)
{
if (arrPath[i] != null && arrPath[i] != “”)
{
strQrystr = strQrystr + “q” + i + “=” + arrPath[i] + “&”;
}
}
}
if (strQrystr.Length > 0)
{
strQrystr = strQrystr.Substring(0, strQrystr.Length – 1);
}
}
else
{
Response.Redirect(strLocal + “/Default.aspx”);
}

//### Start – Actual Url Rewrite

if (strQS == “”)
HttpContext.Current.RewritePath(strUrl, “”, strQrystr + strQS);
else
{
if (strQrystr != “”)
{
HttpContext.Current.RewritePath(strUrl, “”, strQrystr + “&” + strQS);
}
else
{
HttpContext.Current.RewritePath(strUrl, “”, strQS);
}
}
}
catch (IndexOutOfRangeException ex)
{
ex.Message.ToString();

}
catch (Exception ex)
{
ex.Message.ToString();
}
}
private void setPath()
{
strPath = HttpContext.Current.Request.Path.ToString().ToLower();

if (HttpContext.Current.Request.Url.AbsoluteUri.ToLower().IndexOf(“localhost”) != -1 || strLocal != “”)
{
strPath = strPath.Replace(strLocal.ToLower() + “/”, “”);
}
else
{
strPath = strPath.Substring(1);
}
arrPath = strPath.Split(‘/’);
}

Add following lines in web.config

<add key=”Local” value=”/VirtualdirectoryName”/>