Geeks With Blogs

News My Blog has been MOVED to
Michael Freidgeim's OLD Blog My Blog has been MOVED to
We have an ASP.NET application in production(running IIS6 on Windows 2003 server) that sometimes has ".NET Runtime 2.0 Error Reporting" due to exceptions in background threads. We wanted to ignore the errors(while we will fix the cause) and specified


     <legacyUnhandledExceptionPolicy enabled="true" />


in application web.config(as it is suggested in MSDN). Unfortunately it didn't help- ASP.NET application still keep restarting, which causes "session expired" behavior.

I am able to reproduce this on a sample page.
On load the page saves time to Session, then started background thread, that should will exception in 5 sec.
There is also a button to read the Session value, and user can click the button.
During the first 5 sec clicking the button retrieves Session Value correctly, after 5 sec the click causes some delay.
If teh user keep clicking the button, it still continue to work (probably for a minute), then it reports that

Object reference not set to an instance of an object. - which means that session information is lost.
As I understand, after the unhandled exception is thrown, IIS starts a new working application domaiin,but keep old for a minute, than replace with the new, killing session state.

By the was, if legacyUnhandledExceptionPolicy set to "false", click after 5 sec causes a long delay and then the same error, indicating that
session state is lost, is shown.

Can we do something to ignore exceptions in background threads, as legacyUnhandledExceptionPolicy enabled="true" suppose to do?

The sample page, that I was using for testing is the following:

<%@ Page Language="C#" AutoEventWireup="true"  %>

<%@ Import namespace="System.Threading"  %>

<%@ Import namespace="System.Diagnostics"  %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

<script runat=server >

    protected void Page_Load(object sender, EventArgs e)


        if (!IsPostBack)


            Session["TestKey"] = DateTime.Now.ToLongTimeString();

            Thread myThread = new Thread(new ThreadStart(DoWork));


            lblTime.Text = "Page Loaded at " + Session["TestKey"].ToString();



    public void DoWork()


       System.Diagnostics.Trace.WriteLine("Working thread...");

       Thread.Sleep(5000);//5 sec

       throw new ApplicationException("ThrowException =true");



    protected void btnGetSession_Click(object sender, EventArgs e)


        lblFromSession.Text = "From Session Page Loaded at " + Session["TestKey"].ToString();





<html xmlns="" >

<head runat="server">

    <title>Untitled Page</title>



    <form id="form1" runat="server">


      Throw     Exception test&nbsp;

        <asp:Label ID="lblTime" runat="server" Text="Label"></asp:Label>

        <br />

        <asp:Label ID="lblFromSession" runat="server" Text=""></asp:Label>

        <br />

        <asp:Button ID="btnGetSession" runat="server" OnClick="btnGetSession_Click" Text="Get Session" /></div>




I've posted the question to ASP.NET forums and reported to MS feedback site.

Related threads can be found  here and here.

UPDATE: Microsoft replied  at MS feedback site:

Some of these configuration settings are not very well documented. The setting that you would like to change is only valid in the aspnet.config file. The file is passed to CorBindToRuntimeHost when ASP.NET loads the CLR. If you make a change similar to the one below and restart the worker process, everything should work as expected.

C:\>type %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet.config
<?xml version="1.0" encoding="UTF-8" ?>
        <legacyUnhandledExceptionPolicy enabled="true" />
        <legacyImpersonationPolicy enabled="true"/>
        <alwaysFlowImpersonationPolicy enabled="false"/>
        <SymbolReadingPolicy enabled="1" />


Posted on Friday, March 9, 2007 9:12 AM ASP.NET | Back to top

Comments on this post: legacyUnhandledExceptionPolicy enabled="true" doesn't prevent ASP.NET application restarting

# re: legacyUnhandledExceptionPolicy enabled="true" doesn't prevent ASP.NET application restarting
Requesting Gravatar...
Only exceptions on main ASP.NET threads are caught by Application_Error in Global.aspx.
If you start new threads from your pages, and have unhandled exceptions in them, they can stop your web application(default behaviour in .Net 2.0) or be ignored(if you set legacyUnhandledExceptionPolicy enabled="true" as well as other settings according to MS quote).
The recommended way is to catch exceptions in each function,that you start as separate thread.
To get Better Information on Unhandled Exceptions see article that extends MS KB article

Left by Michael Freidgeim on Jan 03, 2008 9:21 AM

# re: legacyUnhandledExceptionPolicy enabled="true" doesn't prevent ASP.NET application restarting
Requesting Gravatar...
1. If you don't have new thread spawns, then legacyUnhandledExceptionPolicy is not applicable for you
2.MS quote- see the bottom of my post- includes
legacyUnhandledExceptionPolicy , legacyImpersonationPolicy
alwaysFlowImpersonationPolicy ,
SymbolReadingPolicy .
3.Is Application_Error invoked at all? Do you call Server.ClearError();in it to specify that error is handled?
Left by Michael Freidgeim on Jan 04, 2008 5:16 AM

# re: legacyUnhandledExceptionPolicy enabled="true" doesn't prevent ASP.NET application restarting
Requesting Gravatar...
Its interesting thread for me as we are facing similar issue.
Michael , to avoid Session data (In-Process Model) loss, if we set legacyUnhandledExceptionPolicy=true then thread which caused this exception remains alive, unless we restart the process. This may cause leak objects, threads, connections.
Guys please confirm.
Left by Mandar on Mar 19, 2008 4:30 PM

# re: legacyUnhandledExceptionPolicy enabled="true" doesn't prevent ASP.NET application restarting
Requesting Gravatar...
if you set legacyUnhandledExceptionPolicy=true(and other parameters as suggested by MS) , background thread (which caused this exception) will be stopped, but ASP.NET application should continue to run. For our scenario it was a better choice than killing the wholl application.
Anyway good code should catch those unhandled exceptions and release all resources, that not required any more.
Left by Michael Freidgeim on Mar 20, 2008 10:32 PM

Your comment:
 (will show your gravatar)

Copyright © Michael Freidgeim | Powered by: