Thomas Marquardt's Blog

ASP.NET v4.0 Security Update and ISAPI Filters on IIS 6.0

2010-10-08T17:54:00Z

A security patch for ASP.NET v4.0 was released recently. The details of the patch can be found at http://www.microsoft.com/technet/security/bulletin/ms10-070.mspx.

I really only have one thing to say in this blog post: If you use an ISAPI Rewrite Filter on IIS 6.0 and you're application pool is using ASP.NET v4.0, then you should disable the ASP.NET extensionless URL feature. The security patch unfortunately deletes that registry setting, so you will have to reset it after you install the patch. The security patch deletes all registry values beneath HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0, and restores them to their default values. The rest of this blog post provides more detail.

The security patch also has an unfortunate side-effect on IIS 6.0 of moving the ASP.NET v4.0 ISAPI Filter (aspnet_filter.dll) to the bottom of the global (effects all web sites) ISAPI Filter list in IIS configuration. This could break applications if they have an ISAPI Filter that needs to come after aspnet_filter.dll. If you installed the patch and suddenly started seeing failures with "/eurl.axd/{GUID}" (where {GUID} is a hexadecimal number) in the URL, then this is the most likely cause. You can try re-ordering your ISAPI Filters list, but if you're not using the ASP.NET extensionless URL feature on IIS 6.0 then you should disable it as described at http://blogs.msdn.com/b/tmarq/archive/2010/06/18/how-to-disable-the-asp-net-v4-0-extensionless-url-feature-on-iis-6-0.aspx. That blog post also explains how the ASP.NET v4.0 Extensionless URL feature works on IIS 6.0.

To change the order of the ISAPI Filters on IIS 6.0, open IIS Manager, find the "Web Sites" folder in the navigation tree, right click that folder and select "Properties", and finally select the "ISAPI Filters" tab. From here, you can select an ISAPI Filter in the list and click the "Move up" button to change the order. The ASP.NET v4.0 filter is the one that appends "/eurl.axd/{GUID}" to URLs, and in the IIS Manager user interface it appears under the name "ASP.NET_4.0.30319.0". For more details on ISAPI Filters, see http://msdn.microsoft.com/en-us/library/ms524610(VS.90).aspx. Note that ISAPI Filters can also be installed at the web site level, so you might need to move your custom ISAPI Filter from the web site level (local) to the web sites level (global) in order to re-order it relative to the ASP.NET v4.0 Filter.

The ASP.NET ISAPI Filter (aspnet_filter.dll) appends "/eurl.axd/{GUID}" to extensionless URLs in order to direct URLs to the ASP.NET ISAPI Extension (aspnet_isapi.dll). The ASP.NET ISAPI Extension then removes "/eurl.axd/{GUID}" from the URL. The problems with "/eurl.axd/{GUID}" appearing in URLs occur when an ISAPI Rewrite Filter gets between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension, and does something (modifies the URL) that makes it impossible for ASP.NET ISAPI Extension to restore the URL, and so "/eurl.axd/{GUID}" remains in the URL.

The ASP.NET v4.0 Extensionless URL (EURL) feature does its work during the SF_NOTIFY_PREPROC_HEADERS notification on IIS 6.0. For those of you having problems with the Ionic’s ISAPI Rewrite Filter, I looked at the Ionic's source code and understand why ASP.NET's EURL feature breaks. Ionic's ISAPI Rewriter Filter used to do rewrite and redirect during SF_NOTIFY_PREPROC_HEADERS, but the latest sources do it during SF_NOTIFY_AUTH_COMPLETE, which happens later. So an older version of the Ionic’s ISAPI Rewrite Filter would be compatible with the ASP.NET EURL feature as long as it's ISAPI Filter comes first in the ISAPI Filter list (so it can't get between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension), and the new version of Ionic’s ISAPI Rewrite Filter is not compatible at all with the ASP.NET EURL feature, no matter how the ISAPI Filters are ordered, because Ionic's does work in SF_NOTIFY_AUTH_COMPLETE which always comes in between the ASP.NET ISAPI Filter and the ASP.NET ISAPI Extension. Note that the ASP.NET ISAPI Filter (aspnet_filter.dll) does more than implement ASP.NET EURL, and by no means should you uninstall the ASP.NET ISAPI Filter. All you should do is disable the ASP.NET extensionless URL feature.

How to Disable the ASP.NET v4.0 Extensionless URL feature on IIS 6.0

2010-06-18T17:44:00Z

You can disable the v4.0 ASP.NET extensionless URL feature on IIS6 by setting a DWORD at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\EnableExtensionlessUrls = 0. After changing the value, you will need to restart IIS in order for us to pick up the change, because it is only read once when IIS starts. Note that for Wow64 (i.e., 32-bit worker process running on 64-bit OS), this registry key must be set at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExtensionlessUrls.

Here’s how the v4.0 ASP.NET extensionless URL features works on IIS 6. We have an ISAPI Filter named aspnet_filter.dll that appends “/eurl.axd/GUID” to extensionless URLs. This happens early on in the request processing. We also have a script mapping so that “*.axd” requests are handled by our ISAPI, aspnet_isapi.dll. When we append “/eurl.axd/GUID” to extensionless URLs, it causes them to be mapped to our aspnet_isapi.dll, as long as the script map exists as expected. These requests then enter ASP.NET where we remove “/eurl.axd/GUID” from the URL, that is, we restore the original URL. The restoration of the original URL happens very early. Now the URL is extensionless again, and if no further changes are made and you’re using the default <httpHandlers> section in web.config, this will be assigned to the DefaultHttpHandler, since it has path=”*” and is the first handler to match the extensionless URL. The DefaultHttpHandler will then redirect this request back to IIS, but this time our filter will not append “/eurl.axd/GUID” and the request will be handled as it would be normally. To do anything interesting with the v4.0 ASP.NET extensionless URL feature, you must change the handler from DefaultHttpHandler to something else, before the MapRequestHandler event fires.

Note that v4.0 aspnet_filter.dll will only enable the extensionless URL feature (by appending eurl.axd to the URL) if the following are true:

EnableExtensionlessUrls is not defined or has a value of 1.
v4.0 aspnet_filter.dll is registered as an ISAPI Filter.
v4.0 aspnet_isapi.dll is script mapped to ".axd" at the web site level (e.g. "/LM/W3SVC/N/ROOT", where N is the siteID).
v4.0 aspnet_isapi.dll is marked as "Allowed" in the ISAPI Restriction list.
The web site has read and script permission enabled.

I've heard that it is not compatible with Ionics ISAPI Rewrite Filter, and it may not be compatible with other URL rewriting components. Fortunately the ASP.NET feature is easy to disable. By the way, the most common way for the ASP.NET extensionless URL feature to fail is for it to leave "/eurl.axd/GUID" on the URL. This happens when our aspnet_filter appends “/eurl.axd/GUID”, but we fail to find the “*.axd” script map, and so the request is not mapped to aspnet_isapi.dll, and therefore never enters ASP.NET and we never restore the original URL. As a result, you will receive a 404 response and the URL will have "/eurl.axd/GUID" appended.

Thanks,
Thomas

How Extensionless URLs Are Handled By ASP.NET v4

2010-05-26T18:48:00Z

ASP.NET v4.0 has a new feature, when hosted on IIS 7, that enables the execution of extensionless URLs. This feature has a dependency on a QFE from IIS that enables extensionless handler mappings. See KB 980368 for more information and a link to download the fix.

ASP.NET v4.0 adds extensionless handler mappings to IIS's configuration file (applicationHost.config). There are handler mappings for classic mode and integrated mode. The classic mode handler mappings map to aspnet_isapi.dll. The integrated mode handler mappings map to a new type named System.Web.Handlers.TransferRequestHandler. An example of the handler mappings is below:

<add
  name="ExtensionlessUrl-ISAPI-4.0_32bit"
  path="*."
  verb="GET,HEAD,POST,DEBUG"
  modules="IsapiModule"
  scriptProcessor="%WINDIR%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll"
  preCondition="classicMode,runtimeVersionv4.0,bitness32" 
  responseBufferLimit="0" />

<add
  name="ExtensionlessUrl-ISAPI-4.0_64bit"
  path="*." 
  verb="GET,HEAD,POST,DEBUG"
  modules="IsapiModule"   
  scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll"
  preCondition="classicMode,runtimeVersionv4.0,bitness64"
  responseBufferLimit="0" />

<add 
  name="ExtensionlessUrl-Integrated-4.0" 
  path="*." verb="GET,HEAD,POST,DEBUG" 
  type="System.Web.Handlers.TransferRequestHandler" 
  preCondition="integratedMode,runtimeVersionv4.0" />

These handler mappings are installed when v4.0 is installed, but without the IIS 7 QFE, they are ignored for extensionless URLs. As soon as you install the QFE, extensionless URLs will enter ASP.NET. The QFE will eventually be included in a service pack.

In classic mode, extensionless URLs are first mapped to aspnet_isapi.dll by IIS, and then using the <httpHandlers> configuration section, ASP.NET maps them to the System.Web.DefaultHttpHandler. By default, the root web.config file contains a path="*" mapping to DefaultHttpHandler. In integrated mode they are mapped to TransferRequestHandler. DefaultHttpHandler and TransferRequestHandler are similar in what they do. If you do not remap the handler, they will both issue a "child request" to the original URL, but ask IIS to ignore their handler mappings for this second request. By default, the IIS StaticFile handler is what will be mapped to these URLs during the second request, and that will typically result in a 404 or 403, assuming that no such file or directory exists.

In order to do something interesting with extensionless URLs, you must remap the handler before the MapRequestHandler event. To do this, you can call HttpContext.RemapHandler and pass in an instance of IHttpHandler. At the lowest level, this is how you programmatically remap the handler. Alternatively use can a feature like URL Routing to remap the handler. URL Routing allows you to define routes that send a URL to a specific handler. It simply calls RemapHandler for you.

Performing Asynchronous Work, or Tasks, in ASP.NET Applications

2010-04-14T14:27:00Z

In this post I hope to clear up some misconceptions about the use of threads in ASP.NET applications so that you know the best way to perform asynchronous work in your ASP.NET applications. If you’re in a hurry and don’t want to read the rest of this, then I suggest that you use PageAsyncTask to execute work asynchronously, and enjoy the rest of your day.

I explained how ASP.NET and IIS use threads in an earlier post titled “ASP.NET Thread Usage on IIS 7.0 and 6.0”. If you haven't read that, please do, but just so you're not left wondering, I will summarize the "flow" of an ASP.NET request again here: New requests are received by HTTP.sys, a kernel driver. HTTP.sys posts the request to an I/O completion port on which IIS listens. IIS picks up the request on one of its thread pool threads and calls into ASP.NET where ASP.NET immediately posts the request to the CLR ThreadPool and returns a pending status to IIS. Next the request is typically executed, although it can be placed in a queue until there are enough resources to execute it. To execute it, we raise all of the pipeline events and the modules and handlers in the pipeline work on the request, typically while remaining on the same thread, but they can alternatively handle these events asynchronously. When the last pipeline event completes, the response bytes are sent to the client asynchronously during our final send, and then the request is done and all the context for that request is released.

In case you're curious, the IIS thread pool has a maximum thread count of 256. This thread pool is designed in such a way that it does not handle long running tasks well. The recommendation from the IIS team is to switch to another thread if you’re going to do substantial work, such as done by the ASP.NET ISAPI and/or ASP.NET when running in integrated mode on IIS 7. Otherwise you will tie up IIS threads and prevent IIS from picking up completions from HTTP.sys. So for this reason, ASP.NET always returns a pending status to IIS, and calls QueueUserWorkItem to post the request to the CLR ThreadPool. In v2.0, 3.5, and 4.0, ASP.NET initializes the CLR ThreadPool with 100 threads per processor (that’s the default, this is configurable). So on a dual-core server, there will be a maximum of 200 threads in the pool. When a CLR ThreadPool thread becomes available (typically happens immediately), the request is picked up by ASP.NET. Normally the request is executed at this point, but it is possible for it to be inserted into one of the ASP.NET queues (described in earlier post). If all the modules and handlers in the pipeline are synchronous, the request will execute on a single CLR ThreadPool thread. If one or more modules or the handler are asynchronous, the request will not execute on a single thread. This is where your code comes into play, but first I have a little more information for you.

If you read the paragraphs above, you probably noticed that a lot of thread switches take place in order to execute an ASP.NET request. There are always at least 3 thread switches. The first is primarily a transition from kernel mode (HTTP.sys) to user mode (IIS). It also frees up HTTP.sys to pick up more incoming requests and hand them off to their respective listeners—not always IIS. If we tried to execute the entire request on that thread, HTTP.sys wouldn’t be resilient to poorly performing listeners—in fact, a single process could shutdown HTTP on the entire server if that process were to deadlock and hold the existing request threads as well as any new incoming request threads. At the same time, there is a penalty paid for any thread switch. It’s called a context switch, and they’re expensive. However, in this case, the benefit from performing the thread switch (reliability of a kernel mode driver) out weights the cost of the context switch. The second thread switch is the one from IIS to ASP.NET, where ASP.NET calls QueueUserWorkItem for the CLR ThreadPool. This one is not as critical. As mentioned in an earlier blog post, this is done primarily as a performance improvement for large corporate workloads that have a mixture of static and dynamic requests. The thread switch for dynamic requests helps improve CPU cache locality for static requests (served by the IIS static file handler) which don't peform a thread switch and instead just execute until completion on the IIS thread. Your specific workload may be quite different—the context switch may be more expensive than any performance benefit from performing the thread switch. I think the performance benefit is very subtle regardless, and a more important reason to perform the thread switch is to free IIS threads so IIS can pick up more completions and hand requests off to other applications—not always ASP.NET. This is similar to what we described in the Http.sys case. We decided it was better to perform the thread switch than not, and so that's what we do. The third thread switch is the one that occurs when we perform the final send, when we switch from a CLR ThreadPool thread to the thread that send the bytes to the client. This switch is definitely worth the cost of the context switch, because clients with low bandwidth are slow and we don't want our CLR ThreadPool thread to be blocked while the bytes are sent, we want it to return to the pool and execute incoming work items. Ok, back to your code..., lets discuss your code now.

So, in your ASP.NET application, when should you perform work asynchronously instead of synchronously? Well, only 1 thread per CPU can execute at a time. Did you catch that? A lot of people seem to miss this point...only one thread executes at a time on a CPU. When you have more than this, you pay an expensive penalty--a context switch. However, if a thread is blocked waiting on work...then it makes sense to switch to another thread, one that can execute now. It also makes sense to switch threads if you want work to be done in parallel as opposed to in series, but up until a certain point it actually makes much more sense to execute work in series, again, because of the expensive context switch. Pop quiz: If you have a thread that is doing a lot of computational work and using the CPU heavily, and this takes a while, should you switch to another thread? No! The current thread is efficiently using the CPU, so switching will only incur the cost of a context switch. Ok, well, what if you have a thread that makes an HTTP or SOAP request to another server and takes a long time, should you switch threads? Yes! You can perform the HTTP or SOAP request asynchronously, so that once the "send" has occurred, you can unwind the current thread and not use any threads until there is an I/O completion for the "receive". Between the "send" and the "receive", the remote server is busy, so locally you don't need to be blocking on a thread, but instead make use of the asynchronous APIs provided in .NET Framework so that you can unwind and be notified upon completion. Again, it only makes sense to switch threads if the benefit from doing so out weights the cost of the switch.

Ok, so you have a good reason to perform some work asynchronously, how should you do it? First of all, all of the code that you are able to run during the execution of a request must run within a module or handler. There is no other option. If you want work to be performed asynchronously—truly asynchronously, as in the current thread unwinds and execution of the request resumes only if and when your work completes—then you must run inside a module or handler that is asynchronous. If you don’t want to implement your own asynchronous module or handler, you’re in luck, because ASP.NET 2.0 introduced async pages , a feature which builds upon IHttpAsyncHandler and makes it easy to run asynchronous tasks known as PageAsyncTasks. There is a nice introduction to asynchronous pages in Dmitry’s TechEd presentation. I would think most ASP.NET developers would prefer to use async pages with one or more PageAsyncTasks in order to perform work asynchronously. So I encourage you to read Dmitry’s TechEd presentation, and focus on slides 31 and 32.

If instead you would prefer to write your own asynchronous module or handler, I’ve included sample code for an asynchronous IHttpModule below along with the same code for a synchronous version of that IHttpModule. Implementing an IHttpAsyncHandler is very similar, so I didn't bother to provide an example.

"AsyncModule.cs":

using System;
using System.Web;
using System.Threading;

public class AsyncModule: IHttpModule {

    // IHttpModule implementation
    void IHttpModule.Dispose() {}

    void IHttpModule.Init( HttpApplication app ) {
        app.AddOnPreRequestHandlerExecuteAsync(new BeginEventHandler(OnBegin),
                                               new EndEventHandler(OnEnd)); 
    }

    // Post a work item to the CLR ThreadPool and return an async result 
    // with IAsyncResult.CompletedSynchronously set to false so that the 
    // calling thread thread can unwind.
    private IAsyncResult OnBegin(Object sender, 
                                 EventArgs e, 
                                 AsyncCallback cb,
                                 Object state) {
        IAsyncResult ar = new MyAsyncResult(cb, 
                                            ((HttpApplication)sender).Context);
        ThreadPool.QueueUserWorkItem(DoAsyncWork, ar);
        return ar;
    }

    // Invoked after completion of the event.  This is frequently a no-op, but
    // if you need to perform any cleanup you could do it here.
    private void OnEnd(IAsyncResult asyncResult) {
    }

    // Called by CLR ThreadPool when a thread becomes available.  We must call
    // Complete on the async result when we are done.  When this happens, the
    //  callback passed to OnEnter is invoked to notify ASP.NET that we are done 
    // handling the event. ASP.NET will then resume execution of the request.
    private void DoAsyncWork(Object state) {
        MyAsyncResult ar = state as MyAsyncResult;
        try {
            throw new NotImplementedException(
                "REMOVE THIS AND ADD YOUR CODE HERE");
        }
        catch(Exception e) {
            ar.Context.AddError(e);
        }
        finally {
            // we must notify ASP.NET upon completion
            ar.Complete(false);
        }
    }

    public class MyAsyncResult: IAsyncResult {
        private AsyncCallback  _callback;
        private HttpContext    _context;
        private bool           _completed;
        private bool           _completedSynchronously;

        // IAsyncResult implementation
        bool IAsyncResult.IsCompleted { get { return _completed;} }
        bool IAsyncResult.CompletedSynchronously { 
            get { return _completedSynchronously; } 
        }
        Object IAsyncResult.AsyncState { get { return null;} }
        //wait not supported
        WaitHandle IAsyncResult.AsyncWaitHandle { get { return null;} }

        // store HttpContext so we can access ASP.NET intrinsics 
        // from our DoAsyncWork thread
        public HttpContext  Context { 
            get { 
                if (_completed || _context == null) {
                    // HttpContext must not be accessed after we 
                    // invoke the completion callback
                    throw new InvalidOperationException();
                }
                return _context; 
            }
        }

        public MyAsyncResult(AsyncCallback cb, HttpContext context) {
            _callback = cb;
            _context = context;
        }

        public void Complete(bool synchronous) {
            _completed = true;
            _completedSynchronously = synchronous;
            // HttpContext must not be accessed after we invoke the 
            // completion callback
            _context = null;
            // let ASP.NET know we've completed the event
            if (_callback != null) {
                _callback(this);
            }
        }
    }
}

"SyncModule.cs":

using System;
using System.Web;

public class SyncModule: IHttpModule {

    // IHttpModule implementation
    void IHttpModule.Dispose() {}

    void IHttpModule.Init( HttpApplication app ) {
        // There are many events, but here we're using 
        // PreRequestHandlerExecute
        app.PreRequestHandlerExecute += new EventHandler( 
                                            OnPreRequestHandlerExecute );
    }

    private void OnPreRequestHandlerExecute(object sender, EventArgs e) {
        HttpApplication app = sender as HttpApplication;
        throw new NotImplementedException(
                     "REMOVE THIS AND ADD YOUR CODE HERE");
    }
}

FAQ

Q1) How many thread pools are there?

A1) There is only one managed thread pool: the CLR ThreadPool. This is the thread pool that is used by the .NET Framework. However, using Win32 APIs you are free to implement as many thread pools as you like. Almost nobody does this because it is very difficult to get it right.

Q2) When should I perform work asynchronously?

A2) When the benefit of switching threads out weights the cost of the context switch. In an attempt to simplify this decision, you should only switch if you would otherwise block the ASP.NET request thread while you do nothing. This is an oversimplification, but I'm trying to make the decision simple. For example, if you make an asynchronous web service request to a remote server then it would be better to let the ASP.NET request thread unwind, and when the "receive" for the web service request fires your callback, you would call into ASP.NET allowing it to resume exection of the pipeline. That way the ASP.NET request thread is not blocked doing nothing while you wait for the web service request to complete.

Q3) If my ASP.NET Application uses CLR ThreadPool threads, won’t I starve ASP.NET, which also uses the CLR ThreadPool to execute requests?

A3) Think about it this way: if you stay on the same thread, you’re using one of ASP.NET’s threads. If you switch to another ThreadPool thread and let ASP.NET’s thread unwind, you’re still only using one thread. While it is true that ASP.NET in classic mode will queue requests if there are more than 12 threads per CPU currently in-use (by default, see KB 821268), for most scenarios you don’t want more than 12 threads to be executing at any given time. When you’re doing asynchronous work, you’re not always using a thread. For example, if you made an async web service request, your client will not be using any threads between the “send” and “receive”. You unwind after the “send”, and the “receive” occurs on an I/O completion port, at which time your callback is invoked and you will then be using a thread again. (Note that for this scenario your callback is executed on an i/o thread—ASP.NET only uses worker threads, and only includes worker threads when it counts the threads in-use.) This is a juggling game, and you will see that when the requests are asynchronous, there can be more requests "executing" at any given time then the number of threads currently in-use. IIS 7 integrated mode is different, in that ASP.NET does not limit the number of threads in-use by default—but you do need to set MaxConcurrentRequestsPerCPU = 5000 in v2.0/3.5, as I mentioned in another post. So to summarize, don’t worry about starving ASP.NET of threads, and if you think there’s a problem here let me know and we’ll take care of it.

Q4) Should I create my own threads (new Thread)? Won’t this be better for ASP.NET, since it uses the CLR ThreadPool.

A4) Please don’t. Or to put it a different way, no!!! If you’re really smart—much smarter than me—then you can create your own threads; otherwise, don’t even think about it. Here are some reasons why you should not frequently create new threads:

1) It is very expensive, compared to QueueUserWorkItem.

2) Before you allow your thread to exit, you must check for pending I/O because your new thread might call into a .NET Framework API that initiates an asynchronous operation, and there’s really no way for you to know whether or not this happened unless you don’t call into framework APIs.

3) The performance of the system hinges on the fact that only a reasonable number of threads are executing at any given time, and if you start creating your own threads it will then become your responsibility to maintain performance of the system. By the way, if you can write a better ThreadPool than the CLR’s, I encourage you to apply for a job at Microsoft, because we’re definitely looking for people like you!

Q5) What if I want to perform work in the background, independent of any requests?

A5) Do you really need it to be independent of a request? It really doesn’t matter how long it runs, it can still be run in the context of a request. The problem with performing work independent of a request is that the AppDomain can be unloaded, and any threads executing at that time will be rudely aborted, which could cause you quite a bit of grief depending on what you’re doing. In v4.0 ASP.NET, we won’t unload the AppDomain until all requests have completed. In v2.0/3.5 ASP.NET in IIS 7 integrated mode, we also won’t unload the AppDomain until all the requests have completed. In v2.0/3.5 classic mode, we will only wait until httpRuntime/shutdownTimeout has been exceeded before unloading the AppDomain, so long running async requests are vulnerable to being rudely aborted. To work around this, you’d want the shutdownTimeout to be sufficiently long.

If you really want this asynchronous work to be independent of any requests, then I recommend that you register for a notification that will tell you when the domain is about to shutdown so that you can safely complete/timeout the work. There are three ways to do this:

1) Use the ApplicationEnd event.

2) There is an AppDomain.DomainUnload event which is fired immediately before the AppDomain is unloaded.

3) You can create an object that implements the IRegisteredObject interface and call HostingEnvironment.RegisterObject to “register” it with ASP.NET. When the AppDomain is about to be unloaded, we will call your implementation of IRegisteredObject.Stop(bool immediate). The Stop method is called twice by ASP.NET, once with the immediate parameter set to false and once again with that argument set to true. You are supposed to call HostingEnvironment.UnregisterObject as soon as your registered object has stopped, so ASP.NET knows it doesn’t need to call your Stop method. You can call it at anytime, but you definitely should call it before returning from Stop when it is called with immediate set to true, because that’s your final chance and if you’re still running after that you will be rudely aborted. This functionality was not implemented specifically for the ability to execute long running tasks independent of any requests, but it will enable you to do this and safely shutdown/complete your work. Note that the point of calling Stop twice is to allow you to asynchronously kick off a job to stop your long running task when Stop is called the first time, giving you a bit more time before it is called the second time and you have to shutdown. If you need to, you can hold up the unload as long as you like, because we won’t unload until your Stop method returns the second time. However, you should be well behaved, and return in a reasonable amount of time, and preferably immediately the first time Stop is called.

Q6) You didn't answer my question.

A6) To be fair, I don't know what your question is. I don't have anonymous comments enabled (too much spam), but if you take a few seconds to register you can leave comments below and I will answer them.

Thank you,
Thomas

How ASP.NET MVC Routing Works and its Impact on the Performance of Static Requests

2010-04-01T17:12:00Z

Recently a number of people have asked how MVC and ASP.NET routing impacts the performance of static requests (HTML, JPG, GIF, CSS, JS, etc). I'll answer that question below while explaining how routing is implemented in the ASP.NET pipeline on IIS 6 and IIS 7. This applies to both ASP.NET 3.5 and 4.0, unless otherwise stated. I'll also talk about the new extensionless URL routing feature in ASP.NET 4.0.

How ASP.NET Routing Works

URLs are mapped to handlers by IIS when the request is initially received. I'll refer to the ASP.NET handlers as managed handlers, and everything else as unmanaged handlers. A request with a managed handler will enter ASP.NET and be processed by the various managed modules in the pipeline. On IIS 6, a request with an unmanaged handler won't be processed by managed code. On IIS 7, a request with an unmanaged handler, also, won't be processed by managed code, at least not by default.

The first step to make routing work for requests with unmanaged handlers is to direct these requests into managed code. On IIS 6 this is done with a wildcard mapping to aspnet_isapi.dll. On IIS 7 this is done either by setting runAllManagedModulesForAllRequests=”true” or removing the "managedHandler" preCondition for the UrlRoutingModule. Ok, so now the requests are coming into managed code, what happens next? Well, the UrlRoutingModule inspects the requests and will change the handler mapping according to the route table. If it doesn't change the handler mapping, then the original handler mapping will be used--the one set by IIS. It's actually a bit more complicated on IIS 6 because of the wildcard mapping. On IIS 6, if the UrlRoutingModule doesn't change the handler, ASP.NET will issue a child request that allows the request to execute with the handler mapping that would have been applied originally if the wildcard mapping didn't exist. Make sense?

Impact on Performance of Static Requests

Okay, so what about the performance of static requests (HTML, JPG, GIF, CSS, JS, etc)? If a request enters managed code, the throughput for that request will be reduced to *approximately* 1/3 of what it would have been, assuming that no caching is involved. Note that I said *approximately*, because the actual result will depend upon hardware, software, the size of the file, etc. Fortunately kernel caching comes to the rescue on IIS 7. If you have an application that uses routing in such a way that *all* requests enter managed code, as long as you don’t change the handler for static requests, they will be kernel cached on IIS 7 (if they’re hot, and meet kernel cache requirements). What about kernel caching on IIS 6? Unfortunately kernel caching is disabled for child requests on IIS 6, which means enabling ASP.NET routing on IIS 6 effectively disables kernel caching of static requests.

So does that mean I should put my static content in an application that isn’t using routing, if I'm concerned about the performance of static requests? On IIS 6, the kernel cache is effectively disabled for static content when ASP.NET routing is enabled; so yes, you proably should partition your site. On IIS 7 it's only the first couple requests to the static file that miss the kernel cache, assuming the request meets kernel caching requirements. However, there is a better way to enable ASP.NET routing on IIS 7, and ASP.NET 4.0 makes use of it by default. Keep reading and I'll also tell you how to enable this on ASP.NET 3.5.

ASP.NET 4.0 Enables Routing of Extensionless URLs

In ASP.NET v4.0, there is a better way to enable routing. Normally you're only interested in routing extensionless URLs, and have no need to route static requests (HTML, JPG, GIF, CSS, JS, etc). In v4.0 there is a new feature that allows extensionless URLs to be directed into managed code, without impacting static requests (HTML, JPG, GIF, CSS, JS, etc). Because of this feature, on IIS 6 you no longer need a wildcard mapping and on IIS 7 you no longer need to set runAllManagedModulesForAllRequests=”true” or remove the "managedHandler" precondition for the UrlRoutingModule. It works by default on both IIS 6 and IIS 7, except that you need a QFE from the IIS team to make this work on Windows Vista SP2, Windows Server 2008 SP2, Windows Server 2008 R2, and Windows 7. Once you obtain the IIS 7 QFE and install v4.0 ASP.NET, you’ll be able to route extensionless URLs without impacting static requests. The QFE enables a new “*.” handler mapping—the notation may seem weird, but all you care about is the fact that this maps to URLs without an extension. ASP.NET registers a “*.” handler mapping when v4.0 is installed. If you don’t have the IIS 7 QFE, that handler mapping does nothing. If you have the IIS 7 QFE, extensionless URLs are mapped to our handler, which enables them to be routed by the UrlRoutingModule. Information about the IIS 7 QFE and steps to download it can be found at http://support.microsoft.com/kb/980368. For the record, the implementation of this feature on IIS 6 is done quite differently, and I won't go into that here.

Just in case you need to disable the feature, I'll tell you how. On IIS 6, you can disable the feature by setting a DWORD registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319\EnableExtensionlessUrls = 0 (the default is 1, even when the key does not exist). On IIS 7, you can disable the feature by removing the "*." handler mappings. There are three of them (1 for 32-bit classic mode, 1 for 64-bit classic mode, and 1 for integrated mode) and the names of these handler mappings in applicationHost.config are: "ExtensionlessUrl-ISAPI-4.0_32bit", "ExtensionlessUrl-ISAPI-4.0_64bit", and "ExtensionlessUrl-Integrated-4.0".

How to Enable Extensionless URL Routing on ASP.NET 3.5 for MVC

Similarly to the way it is done in ASP.NET 4.0, you can enable routing of extensionless URLs on ASP.NET 3.5 (and even ASP.NET 2.0) without setting runAllManagedModulesForAllRequests="true" or configuring a wildcard script handler. To do this, you need one of the following operating systems: Windows Vista SP2, Windows Server 2008 SP2, Windows Server 2008 R2, or Windows 7. And you need to patch it with the hotfix available at http://support.microsoft.com/kb/980368 (this hotfix will eventually be rolled into a future service pack, of course). Once you have the hotfix installed, simply add the following web.config to your application and take the source code for MyTransferRequestHandler (also below) and put it in a CS file located in the App_Code folder of your application. Alternatively you can compile MyTransferRequestHandler into a DLL and place it in the bin, or better yet, give it a strong name, install it in the GAC, and NGEN it. After doing this, extensionless URLs will be directed into managed code, and you can then route them to a different handler. If you choose not to route them to a different handler, they will be directed back to IIS so that they can be executed by the handler that would have served them if our extensionless URL handler was not installed.

"web.config":

<configuration>
  <system.webServer>
    <handlers>
      <!-- THESE HANDLER MAPPINGS SHOULD GO BEFORE 
           ANY OTHER HANDLER MAPPINGS -->
      <add name="EURL-ISAPI-2.0_32bit" 
        path="*." 
        verb="GET,HEAD,POST,DEBUG" 
        modules="IsapiModule"
        scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" 
        preCondition="classicMode,runtimeVersionv2.0,bitness32" 
        responseBufferLimit="0"/>
      <add name="EURL-ISAPI-2.0_64bit" 
        path="*." verb="GET,HEAD,POST,DEBUG"
        modules="IsapiModule" 
        scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" 
        preCondition="classicMode,runtimeVersionv2.0,bitness64" 
        responseBufferLimit="0"/>
      <add name="EURL-integrated-2.0" 
        path="*." 
        verb="GET,HEAD,POST,DEBUG" 
        type="MySample.MyTransferRequestHandler" 
        preCondition="integratedMode,runtimeVersionv2.0"/>
      <!-- PLACE ADDITIONAL HANDLER MAPPINGS BELOW HERE -->
    </handlers>
    <modules runAllManagedModulesForAllRequests="false">
      <!-- BE CERTAIN TO SET runAllManagedModulesForAllRequests="false" -->
      <!-- AND IF YOU ADDED A WILDCARD SCRIPT MAPPING, REMOVE THAT TOO -->
    </modules>
  </system.webServer>
</configuration>

"App_Code/MyTransferRequestHandler":

namespace MySample {
    using System;
    using System.Web;
    // This handler only works on IIS 7 in integrated mode and is
    // designed to be used as a "*." handler mapping.  We will refer
    // to "*." as the extensionless handler mapping.  There is a bug
    // in Windows Vista, Windows Server 2008, and Windows Server 2008 R2
    // that prevents the IIS 7 extensionless handler mapping from working
    // correctly, and if you have not already patched your machine you 
    // will need to install this hotfix: http://support.microsoft.com/kb/980368.
    // 
    // WARNING: You may be wondering how this handler works, since it passes
    // the original URL to the TransferRequest method.  Why doesn't it do the
    // same thing the second time the URL is requested?  Well, TransferRequest
    // invokes the IIS 7 API IHttpContext::ExecuteRequest, and includes the
    // EXECUTE_FLAG_IGNORE_CURRENT_INTERCEPTOR flag in the third argument to
    // ExecuteRequest.  This causes the "*.", or extensionless, handler mapping
    // to be skipped, and allows the handler that would have executed originally
    // to serve this request. If you attempt to use this handler without an
    // extensionless handler mapping, it will probably result in recursion.
    // This recurssion will eventually be stopped by IIS once the loop iterates
    // about 12 times, and then IIS will respond with a 500 status, a message 
    // that says "HTTP Error 500.0 - Internal Server Error", and an HRESULT  
    // value of 0x800703e9.  The system error message for this HRESULT is
    // "Recursion too deep; the stack overflowed.".
    public class MyTransferRequestHandler : IHttpHandler {        
        public void ProcessRequest(HttpContext context) {
            context.Server.TransferRequest(context.Request.RawUrl, 
                                           true /*preserveForm*/);
        }       
        public bool IsReusable {
            get {
                return true;
            }
        }
    }
}

Wondering how the extensionless URL handler mappings work? Wondering why it works for both classic and integrated mode? In classic mode, the "*." handler mapping is to our aspnet_isapi.dll. Extensionless URLs will be mapped to the DefaultHttpHandler in classic mode. The DefaultHttpHandler is listed in the <httpHandlers> section in the root web.config file with path="*", so it catches everything that is not caught by something else. If you don't change the handler before the MapRequestHandler event, the DefaultHttpHandler will issue a child request to the original URL with the HSE_EXEC_URL_IGNORE_CURRENT_INTERCEPTOR flag. This tells IIS to skip our extensionless URL handler and map the request to the handler that would normally serve this type of request. If on the hand you want ASP.NET to handle it, you can change the handler by calling HttpContext.RemapHandler before the MapRequestHandler event. This is what ASP.NET routing does in v4.0--in v3.5, routing essentially does the same, but in a much more round about manner. So that's how the extensionless URL handler works in classic mode. In integrated mode, it's essentially the same, but instead of going through the ISAPI path we're able to call the IIS API IHttpContext::ExecuteRequest directly, and similarly we pass a flag to ignore the current interceptor, but the flag is called EXECUTE_FLAG_IGNORE_CURRENT_INTERCEPTOR. The ISAPI code path actually uses these same APIs, but not directly.

Troubleshooting

Having trouble with the MyTransferRequestHandler shown above? That code only directs extensionless URLs into managed code. You need to use routing or something else in order to handle them. If you just want to see if extensionless requests are entering managed code, you can add the following to your web.config and put the MyInterceptorModule source code in a file named MyInterceptorModule.cs within your App_Code directory. The MyInterceptorModule intercepts all requests that enter managed code and displays information about the URL and the values of several server variables.

"web.config additions":

<system.web>
    <httpModules>
      <add 
        name="MyInterceptorModule" 
        type="MySample.MyInterceptorModule"/>
    </httpModules>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules runAllManagedModulesForAllRequests="false">
      <add name="MyInterceptorModule" 
        type="MySample.MyInterceptorModule" 
        preCondition="managedHandler"/>

  </modules>
  </system.webServer>

"App_Code/MyInterceptor":

namespace MySample {
    using System;
    using System.Web;
    public class MyInterceptorModule : IHttpModule {
        public void Dispose() {}
        public void Init( HttpApplication app ) {
            app.BeginRequest += new EventHandler( OnBeginRequest );
        }
        private void OnBeginRequest(object sender, EventArgs e) {
            HttpApplication app = sender as HttpApplication;
            HttpResponse response = app.Context.Response;
            HttpRequest request = app.Context.Request;
            response.Output.WriteLine("<html><head><title>intercepted</title></head><body><pre>");
            response.Output.WriteLine("Path={0}", request.Path);
            response.Output.WriteLine("PathInfo={0}", request.PathInfo);
            response.Output.WriteLine("QueryString={0}", request.QueryString);
            response.Output.WriteLine("RawUrl={0}", request.RawUrl);
            foreach(string key in request.ServerVariables.AllKeys) {
                response.Output.WriteLine(
                       "{0} = {1}", key, request.ServerVariables[key]);
            }
            response.Output.WriteLine("</pre></body></html>");
            app.CompleteRequest();
        } 
    }
}

Note that if you're experimenting and want to see what is kernel cached, there are a number of things that prevent a resource from being kernel cached. Be sure to include an Accept-Encoding header, for example most browsers include "Accept-Encoding: gzip,deflate". Also don't issue a conditional GET, for example, make sure your browser is not using "If-Modified-Since". Request the page a couple times in order to kernel cache it. To see if it is served from the kernel cache, start Performance Monitor (Start|Run|type perfmon.msc) and add the following performance counters: "Web Service Cache\Kernel: URI Cache Hits", "Web Service Cache\Kernel: URI Cache Misses", and "Web Service Cache\Kernel: Current URIs Cached".

Regards,
Thomas

Correct use of System.Web.HttpResponse.Redirect

2009-06-25T20:10:00Z

Try very, very hard to avoid using Response.Redirect(url), instead, use Response.Redirect(url, false). Response.Redirect(url), after writing a 302 redirect response to the response buffers, calls Response.End. This is very expensive. The alternative, Response.Redirect(url, false) is fast, but unlike Response.Redirect(url), the lines of code which follow the call to Response.Redirect(url, false) will be executed. More on this later, but first, let me tell you about the horrors of Response.End.

Response.End is a terrible method. It was added in ASP.NET 1.0 for compatibility with classic ASP. In classic ASP, this method terminated script processing, so that the lines of script that followed this call never executed. How do you simulate that in managed code? The only way is to abort the thread, which raises a ThreadAbortException and is outrageously expensive. Normally, that's exactly what Response.End does in ASP.NET, however, if it is called from within an asynchronous handler/module (a.k.a. an asynchronous pipeline event), it will instead perform a synchronous flush of the response buffers (can you say expensive?) and then complete the request by calling Context.ApplicationInstance.CompleteRequest(). Either way, whether you're calling it from a synchronous handler/module or an asynchronous handler/module, Response.End is horribly expensive, and you should avoid it.

Ok, so what if you don't want the lines of code to execute after you redirect? Well, one way to accomplish this is to call HttpApplication.CompleteRequest(), which is accessible from the HttpContext. e.g., call calling Context.ApplicationInstance.CompleteRequest(). It's not the same as aborting the thread, which truly does prevent all subsequent lines of code form running. The lines of code that follow the call to CompleteRequest() will execute, but as soon as the current page or module that calls this completes, the pipeline will jump ahead to the EndRequest event, thereby short circuiting the pipeline. This is usually all you need.

So to summarize...

BAD:

Response.Redirect(url);

GOOD:

Response.Redirect(url, false);

Context.ApplicationInstance.CompleteRequest();

But before I put my pen away, there's one more common practice I've seen that people should be aware of . In classic mode, calling Response.Redirect(url) from Application_Error without calling Server.ClearError is doubly expensive. It causes three exceptions to be thrown, and then either raises a ThreadAbortException or does a synchronous flush and completes the response. And in integrated mode, calling Response.Redirect(url) from Application_Error without calling Server.ClearError does not even work. Instead, you should use the following code, which performs well in both classic mode and integrated mode. If you’re going to redirect from Application_Error, you should do it the following way:

GOOD:

void Application_Error(object sender, EventArgs e)

{

Server.ClearError();

Response.Redirect(url, false);

Context.ApplicationInstance.CompleteRequest();

}

The behavior difference between classic and integrated mode with respect to calling Redirect from Application_Error without calling Server.ClearError is just due to the different environments. You might notice that with a default 3.5 install, if you remove the ASP.NET ScriptModule from the IIS <modules> section, you're suddenly able to call Redirect from Application_Error without calling Server.ClearError. ScriptModule registers a PreSendRequestHeaders handler. In integrated mode, the PreSendRequestHeaders event is implemented differently. As a result, in integrated mode, the exception will be rendered if you try to redirect without clearing the error from Application_Error. I’ve attached a sample that demonstrates the difference between the two pipelines. This sample will demonstrate the difference regardless of whether or not ScriptModule is installed. Just request default.aspx. Then change the value of demonstratePipelineDifference in global.asax, and request default.aspx again. Do this in both classic mode and integrated mode, and observe the behavior.

Thanks,

Thomas

Obtaining more information from an HttpException

2009-03-10T23:44:00Z

ASP.NET throws HttpException for numerous types of errors, making it difficult to determine exactly what went wrong programmatically. You can parse the error message, but the message can be localized, and therefore parsing it can be non-trivial. There is, however, a way that you can identify a few specific types of errors.

In v2.0 there is an internal property on HttpException named WebEventCode that returns an int. This value contains additional information which you can use to determine the type of error. Because it is internal you will have to use private reflection to get the value, but the property has been made public in v4.0. Below I've listed the meaning of several of the possible values of this property:

If the HttpException is because the request timed out ("Request timed out."), the value will be System.Web.Management.WebEventCodes.RuntimeErrorRequestAbort.
If it's because the client posted too much data ("Maximum request length exceeded."), the value will be WebEventCodes.RuntimeErrorPostTooLarge.
If it's caused by a ViewState error, the value will be WebEventCodes.RuntimeErrorViewStateFailure.

Again, this property has been made public in v4.0, but for v2.0, you'll have to use private reflection to access it.

-Thomas

Using IIS 7.0 Dynamic Compression with ASP.NET Output Cache

2008-08-27T22:31:00Z

This post discusses an efficient way to compress content served by the ASP.NET output cache. In .NET Framework v2.0 SP1, included with Windows Server 2008, the ASP.NET Output Cache includes a new feature that allows cached responses to vary by the response's Content-Encoding header. And IIS 7.0 has efficient compression algorithms for gzip and deflate. Put the two together, and you can efficiently compress responses once, and serve them from the cache many times.

Here's how you can do this on Windows Server 2008:

1. If you haven't already, install the Dynamic Content Compression role for IIS 7.0 using the Server Manager.

2. Step 1 will add the <httpCompression> configuration section to applicationHost.config. Note that only gzip compression is supported by default. However, deflate is also implemented in gzip.dll, so if you add the following to the <httpCompression> configuration section, you'll also have deflate enabled:

<scheme name="deflate" dll="%Windir%\system32\inetsrv\gzip.dll" />

3. Create an application with an ASPX page like the one below. This example page will cache at most 3 responses, one that is gzip compressed, one deflate compressed, and one that is a normal (uncompressed) response.

<%@ Page language="C#" %>
<%@ OutputCache duration="600" varyByParam="None" varyByContentEncoding="gzip;deflate" %>

<script runat="server">
    void Page_Load() {
        Request.ServerVariables["IIS_EnableDynamicCompression"] = "1";
        Response.Write(DateTime.Now);
    }
</script>

4. You must enable the IIS 7.0 "dynamic compression before cache" feature. You can do this by adding the following to your application's web.config file.

<system.webServer>
<urlCompression doDynamicCompression="false" dynamicCompressionBeforeCache="true" />
</system.webServer>

Note that in Step 4, doDynamicCompression="false". If you set this to "true", all responses will be compressed. That is, pages that are not using the output cache, as well as pages that are using the output cache (but may not be using varyByContentEncoding) will be compressed. Our example sets doDynamicCompression to "false" in configuration, but then uses the server variable "IIS_EnableDynamicCompression" to enable it for a specific page. Alternatively, you could use configuration and <location path=""> to limit the scope of compression.

So how does this work? When a request is sent to the server, it may or may not include an Accept-Encoding header, indicating one or more acceptable encodings. For example, Internet Explorer sends "Accept-Encoding: gzip, deflate". When the ASP.NET Output Cache receives the request, if the page is using the VaryByContentEncoding feature, ASP.NET will check if any of the encodings specified by VaryByContentEncoding match the request's Accept-Encoding header. If there is a match, ASP.NET will see if that response is in the cache and serve it. If it's not cached, ASP.NET will render the response and the IIS 7.0 DynamicCompressionModule, which runs during RQ_RELEASE_REQUEST_STATE, will encode the response according to the request's Accept-Encoding header, and it will set the response's Content-Encoding header. For the example request, the response header will be set to "Content-Encoding: gzip". When the ASP.NET OutputCacheModule runs during RQ_UPDATE_REQUEST_CACHE, it will check to see if the Content-Encoding header has been set, and if specified in VaryByContentEncoding, it will cache the response according to that encoding. If the Content-Encoding is not set, the response can be cached as the identity.

This ASP.NET Output Cache feature can be used via the <%@ OutputCache varyByContentEncoding= %> page directive, programmatically via HttpCachePolicy.VaryByContentEncodings, or via configuration outputCacheProfiles><add varyByContentEncoding=””></outputCacheProfiles>.

Here are a few of the implementation details:

The value of the VaryByContentEncoding property is the name of an encoding, or a semi-colon separated list of encodings (e.g. "gzip", "gzip; deflate; compress").
The identity, or plain text, is a special case. You can consider it to be implicitly included in the value of VaryByContentEncoding. E.g., if you specify varyByContentEncoding="gzip", ASP.NET will cache at most two responses, gzip and the identity.
A response can be cached only if the value of its Content-Encoding header is included in VaryByContentEncoding; except for the identity, which is a special case. If the response does not have a Content-Encoding header, it can be cached as the identity.
A response will be served from the cache if it has an acceptable encoding according to RFC 2616, Section 14.3 (qvalues are supported). However, even if the identity is available in the cache, if an acceptable encoding is found in VaryByContentEncoding, but that encoding has not yet been cached, ASP.NET will allow the page to render so that a response for that encoding may be cached.
If the value of the Content-Encoding response header is not in the list, the response is not cacheable. If the Content-Encoding response header is in the list, the response is cacheable (assuming nothing else in its cache policy prevents it from being cached).
If the Content-Encoding response header is not set, the response may be cached as the identity (again, assuming nothing else in its cache policy prevents it from being cached).
If the request's Accept-Encoding doesn't match any cached responses, and is not listed in VaryByContentEncoding, and the identity is available in the cache, then the response served will be the identity.

Regards,
Thomas

ASP.NET Cache can notify you before an entry is removed

2008-07-22T19:32:00Z

.NET Framework v2.0 SP2, which will be included with .NET Framework v3.5 SP1, is scheduled to release this summer. This release contains a long awaited ASP.NET Cache feature, which will notify you when an entry becomes invalid and leave the stale entry in the cache while you generate a replacement in the background. Therefore, requests are not blocked attempting to access the cache entry while it is being updated, and the update is done by a single thread. Here's the specification:

A new Cache.Insert overload:

void Cache.Insert( String key,

Object expensiveObject,

CacheDependency dependencies,

DateTime absoluteExpiration,

TimeSpan slidingExpiration,

CacheItemUpdateCallback onUpdateCallback

);

This method inserts an object into the cache, with optional dependencies and expiration policy, and a callback that is invoked before the entry is removed. Objects inserted into the cache with this method should be expensive to generate. You should not use this method for objects that are inexpensive to generate, because there is overhead in the implementation. When the callback is invoked, the application developer should generate a new object, with new dependencies and expiration policy, and return it via the callback’s out parameters. The stale cache entry will be accessible while the callback is executing and the replacement object is generated.

Cache entries inserted by this method are not subject to eviction by the cache memory manager. These objects only become invalid when they expire or a dependency changes, and therefore these objects MUST have some form of invalidation (i.e., it is not possible to insert the entry with a null dependency, NoAbsoluteExpiration, and NoSlidingExpriation).

A new update callback:

void CacheItemUpdateCallback( String key,

CacheItemUpdateReason reason,
out Object expensiveObject,

out CacheDependency dependencies,

out DateTime absoluteExpiration,

out TimeSpan slidingExpiration

);

When the cache entry becomes invalid, ASP.NET invokes this callback, allowing the application developer to generate a replacement cache entry. The developer is passed only two pieces of information: the key for the cache entry, and an enum value indicating why the entry is invalid. The rest of the arguments to the callback are output-only parameters, allowing references to the newly generated object, dependencies, and expiration policy to be passed back and subsequently inserted into the cache by ASP.NET.

Do not modify the existing cache entry. The stale cache entry is still alive and potentially being used by other threads. It is not included in the callback arguments in order to minimize the likelihood of a developer accidentally updating portions of the cache entry. Although this pitfall exists today in the cache API (e.g. a cache entry could be modified in a non-thread-safe manner by an ASP.NET developer), we think leaving the cached value out of the callback arguments will reduce the likelihood of a developer stumbling into this.

To remove the cache entry, simply set the argument expensiveObject to null. Otherwise, set it to the newly generated replacement object. The developer MUST also specify expiration and/or dependency information using the other out parameters. As stated above, the cache entry is not subject to eviction by the cache memory manager, and therefore must have some form of invalidation. It is an error to pass back a non-null value for expensiveObject while setting dependencies to null, absoluteExpiration to NoAbsolteExpiration, and slidingExpriation to NoSlidingExpiration. The cache entry will be removed if this occurs.

If the developer’s callback throws an exception, ASP.NET will suppress the exception and remove the cache entry. The exception needs to be suppressed because cache item updates occur in the background where there is no call path for routing the exception back to user code. The cache entry is removed because without a new cache value, ASP.NET has no way of knowing what the correct behavior is for updating the cached item.

The update callback will not be called if the cached item was explicitly removed via a call to Cache.Remove, or a call to Cache.Insert (Insert removes a pre-existing entry). These operations indicate the developer’s intent to remove the item, so the update callback will not be triggered.

A new update reason enumeration:

public enum CacheItemUpdateReason {

// The item was removed from the cache because either

// the absolute or sliding expiration interval expired.

Expired = 1,

// The item was removed from the cache because an

// associated cache dependency was changed.

DependencyChanged = 2

}

Unlike the CacheItemRemovedReason enumeration, the update reason enumeration does not include values for Removed (see explanation above) or Underused (as mentioned above, the cache entry is not subject to eviction by the cache memory manager).

Regards,

Thomas

If you allocate from the Large Object Heap each time an ASPX page is requested, your performance will be dismal.

2008-04-29T20:12:00Z

I've been giving this advice for years internally, and the problem pops up way too often. I'm sure it will be addressed eventually, in a future version of the CLR, but for now, every released version of the CLR has this problem. If you allocate objects larger than 85000 bytes, they will be allocated in the Large Object Heap (LOH). The LOH is not compacted and collection only occurs after a full collection (so gen 2 must be collected in order to collect an object in the LOH). Short-lived and frequent LOH allocations will kill the performance of your application. As an example, if you allocate from the LOH each time an ASPX page is requested, your performance will be dismal.

There are a few ways to determine if you're allocating from the Large Object Heap (LOH). The easiest is via the performance counter ".NET CLR Memory\Large Object Heap size". You can more or less determine if your allocating from the LOH on a per-request basis by checking to see if the value of this performance counter fluctuates while you make requests.

You can also deterimine if you're allocating from the LOH by profiling a request with the CLR Profiler, which is discussed in an earlier blog post. The Histogram view shows you a histogram of the allocations broken down by size, and you can quickly check to see if there's anything larger than 85000 bytes. If you right click on columns in the histogram, you can select "Show who Allocated" to see a stack trace for the allocation(s).

Another way to determine if you’re allocating from the Large Object Heap (LOH) is by setting break points. For example, you can use this break point on v2.0 on a multi-proc box, where the server GC is enabled by default:

bp mscorwks!SVR::gc_heap::allocate_large_object ".echo size=; ? poi(@esp+4); k12; gc"

If you want to get fancy, the following will attach ntsd to w3wp.exe, disable break on first chance exceptions, and trace the calls to allocate_large_object to %SYSTEMDRIVE%\NTSD.log

ntsd.exe -y %WINDIR%\symbols;srv*%WINDIR%\Symbols*http://msdl.microsoft.com/download/symbols -xd * -c "bp mscorwks!SVR::gc_heap::allocate_large_object \".echo size=; ? poi(@esp+4); k12; gc\"; g" -G -logo %SYSTEMDRIVE%\NTSD.log -pn w3wp.exe

Aside from short-lived LOH allocations, the most common cause of memory related issues in ASP.NET apps is pinning managed memory during long async I/O operations. ASP.NET itself does not do this, but perhaps your application does?

Thanks,

Thomas

ASP.NET File Change Notifications, exactly which files and directories are monitored?

2007-11-02T06:15:00Z

Perhaps one of the most loved and hated features of ASP.NET is the ability to detect file changes and automatically recompile or reconfigure the application. In development scenarios it’s very nice because you can access the application in a browser at the same time you’re modifying ASPX, ASAX, DLL, CONFIG, and other application files, and you don’t have to stop the web server process in order to update DLLs or configuration. The changes are picked up immediately, but in order to make this possible we have to recycle the AppDomain. In deployment scenarios, this feature can be a problem. There are many files and folders (e.g. global.asax, web.config, BIN, App_Code, etc) that trigger an AppDomain unload when changed. A subsequent request to the application will cause the AppDomain to be loaded again and the new files will be compiled, if necessary. Restarting the application is expensive due to the disk access and recompilation of files. Many applications also have expensive initialization steps that occur when the AppDomain is loaded, such as accessing SQL to populate local stores with frequently accessed data. So what exactly does ASP.NET monitor and how?

ASP.NET uses the Win32 function ReadDirectoryChangesW to monitor directories and files. Given a directory handle, this function will let you know lots of information about changes to the directory or the files and directories contained within it. By passing different flags, you tell it exactly what information you’re interested in and it informs you when there are changes. ASP.NET monitors directories with the following flags (they are fairly self-explanatory, but you can refer to ReadDirectoryChangesW documentation for details):

FILE_NOTIFY_CHANGE_FILE_NAME
FILE_NOTIFY_CHANGE_DIR_NAME
FILE_NOTIFY_CHANGE_CREATION
FILE_NOTIFY_CHANGE_SIZE
FILE_NOTIFY_CHANGE_LAST_WRITE
FILE_NOTIFY_CHANGE_SECURITY

The above flags are the ones that ASP.NET uses, but not all of them are used for each directory handle that is monitored. So which directories are monitored? By default in ASP.NET 2.0, there are six directory monitors for each application path, and two additional directory monitors for each virtual subdirectory path. This is best explained with an example. Suppose that we have an application with a virtual path of "/vpath" and a physical path of "c:\ppath". If you make a request to a file located at "/vpath/f.aspx", the following directory monitors will be created:

#1) The application physical root path and all of its subdirectories are monitored for subdirectory name changes or deletions. To be more precise, if FILE_NOTIFY_INFORMATION.Action is FILE_ACTION_RENAMED_OLD_NAME or FILE_ACTION_REMOVED, the AppDomain is unloaded. This means that if you rename or delete a subdirectory beneath the application physical root, the application will be restarted. This is discussed in Todd Carter's blog post.