>Global.asax is *always* derived (even if indirectly) from HttpApplication - it would not make sense otherwise. Look at your Global.asax.vb file. If you're deriving directly from HttpApplication it will be:

There is no .vb file associated with the global.asax. I removed that since a very long time.

>ASP.NET maintains a pool of HttpApplication objects. When the first request comes in it will create an instance, use it to handle the request, and then leave it in the pool so the next request can use it.
>If a second request arrives whilst the first is still being processed then another HttpApplication instance is created because the first one is still busy.
>If a website is not very heavily used it may never need a second instance. However if you deliberately hit the site repeatedly whilst the DLLs are being reloaded then it's likely that multiple HttpApplications *will* be needed.
>If you add the Thread.Sleep to the Page_Load as I suggested then it is very easy to force ASP.NET to create additional instances of HttpApplication because the time taken to handle the request is articificially extended. If you add the log to the HttpApplication.Init() override you will be able to see when additional instances of HttpApplication are spawned. Without the Sleep() just manually creating hits in the browser is unlikely to be quick enough to cause this to happen....
>
>My main point here is that it is *possible* that the re-cycling is a red-herring - just having 'over-lapping' creation may be enough to cause the problem.

Ok, so it makes sense that a recycle might also fall into the same situation. That would explain why, sometimes, I see that the Web site stops responding, and in the log, there was nothing in it that could have caused it, but some very little hit with just a few SQL Server accesses. So, it seems that the initial problem is replicated at the recycling as well.

I just need to find what is causing this.