>>To be truly sure you would need to make sure that the old instance was also not using any of your framework elements (eg had also only run the same page as above). Also I assume that your global.asax is derived directly from HttpApplication and contains nothing except the logging code that was added ?
>
>I was able to simulate it twice under the same type of test, which is to have clicked on four items in my menu (four .aspx pages), which are not bound to the framework (I had removed the inheritance as well as the call in the Page_Load()). However, in order to simulate the situation, I had to recompile my DLL, but it was not used in the four clicks I did.
>
>Global.asx does not derive from HttpApplication. I only have this in it:
>
>

>@ Application Language="VB"
>
><script runat=server>
>
>    Sub Application_PreRequestHandlerExecute(ByVal sender As Object, ByVal e As EventArgs)
>        Dim loContext As Object = Context.Handler
>        Dim loType As Object = loContext.GetType()
>        Dim lcType As String = loType.ToString
>
>        ' .vb and .config not accepted
>        If lcType = "System.Web.HttpForbiddenHandler" Then
>            Response.Redirect("Default.aspx")
>        End If
>        
>    End Sub
>   
></script>
>

>
>What would be required to have it derived from HttpApplication? And, why would that be used in here?

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:

Public Class Global_asax
    Inherits System.Web.HttpApplication

>>The only thing I came across is this:
>>http://blogs.msdn.com/b/tess/archive/2009/09/22/asp-net-case-study-hang-when-loading-assemblies.aspx
>>but it appears this was fixed in ASP.NET 2.0 SP1 which I assume you are using.
>
>I have this problem on the server that the Windows Update is constantly asking for the same update to be done. So, even if I do it, it will still ask to update it after. I haven't been able to resolve that one. But, I doubt it is related. Because, I also have the same situation on my PC and all the updates are ok.
>
>>I also came across a couple of vague suggestions that leaving debugging turned on in published code can cause odd behaviour but doubt it is relevant.
>
>I have disabled "Enable the Visual Studio hosting process" in my Framework.dll. The other two related debug options were already turned off.
>
>The debug pane is not enabled in LevelExtreme.dll. So, I cannot adjust any option in there as it is not even showing up.
>
>The problem is still there. I was able to simulate the freeze.
>
>>Have you checked the Windows event log to see if anything crops up there?
>
>There is nothing in there about those situations.
>
>>Do you have logging enabled on the web site (although I'm not sure whether it could tell us anything useful about this problem)
>
>No, this is always turned OFF.
>
>>Are you sure this problem can only occur when a DLL has been replaced. It may just be that the re-cycling is the only time the web site has a 'back-log' of requests which will cause it to spawn additional application instances. Try putting a 'System.Threading.Thread.Sleep(1000)' in the Page_Load and see if the problem arises *without* changing the DLL. Add a log item in the Init() so you can check that additional HttpApplication instances are created:

Public Overrides Sub Init()
>>        LogAction("Application Init at " + DateTime.Now.ToString())
>>        MyBase.Init()
>>    End Sub

>>
>>If I get a chance I'll try this on a server here but I've a few busy days ahead so.....
>
>I had that situation over the weekend where the Web site stopped responding. It may well be that a recycle happened and it caused the same situation. So, yes, I believe both situations are related. The problem seems to cause the refresh of the DLL situation and it may happen as well when it recycles.
>
>I am not sure I understand the test with the Page_Load() because that is an event which is in the .aspx page and when it freezes, it never goes in there. We have seen that the Framework.dll PreInit() does not even kick in. So, the Page_Load() is not reached. Could you tell me more about that test?

Bit of an over-simplifiation but:

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.