%3CLINGO-SUB%20id%3D%22lingo-sub-1536553%22%20slang%3D%22en-US%22%3ECrash%20at%20System.Web.LegacyAspNetSynchronizationContext.CallCallback%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1536553%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20you%20see%20crash%20at%20the%20following%20call%20stack%2C%26nbsp%3Bthat%20mostly%20probably%20is%20because%20web%20application%20is%20currently%20configured%20to%20use%20Legacy%20ASP.NET%20Synchronization%20Context%2C%20but%20the%20code%20is%20using%20some%20new%20features%2C%20such%20as%20Tasks%20(from%20Task%20Parallel%20Library)%20that%20require%20usage%20of%20what%20we%20call%20%E2%80%9CTask-friendly%20ASP.NET%20Synchronization%20Context.%E2%80%9D%20The%20old%20(Legacy)%20context%20cannot%20handle%20some%20asynchronous%20calls%20properly%20and%20this%20leads%20to%20the%20crash%20as%20observed%20in%20the%20above.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWeb%20App%20Crashes%20frequently.%20Below%20are%20found%20in%20application%20event%20log%20each%20time%20of%20crash%3A%3C%2FP%3E%0A%3CP%3EApplication%3A%20w3wp.exe%3C%2FP%3E%0A%3CP%3EFramework%20Version%3A%20v4.0.30319%3C%2FP%3E%0A%3CP%3EDescription%3A%20The%20process%20was%20terminated%20due%20to%20an%20unhandled%20exception.%3C%2FP%3E%0A%3CP%3EException%20Info%3A%20System.NullReferenceException%3C%2FP%3E%0A%3CP%3Eat%20System.Web.ThreadContext.AssociateWithCurrentThread(Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.HttpApplication.OnThreadEnterPrivate(Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock(System.Threading.SendOrPostCallback%2C%20System.Object)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.LegacyAspNetSynchronizationContext.CallCallback(System.Threading.SendOrPostCallback%2C%20System.Object)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.Tasks.AwaitTaskContinuation.RunCallback(System.Threading.ContextCallback%2C%20System.Object%2C%20System.Threading.Tasks.Task%20ByRef)%3C%2FP%3E%0A%3CP%3Eat%20System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext%2C%20System.Threading.ContextCallback%2C%20System.Object%2C%20Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext%2C%20System.Threading.ContextCallback%2C%20System.Object%2C%20Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ThreadPoolWorkQueue.Dispatch()%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ETo%20Resolve%20the%20issue%20add%20the%20following%20in%20web.config%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CAPPSETTINGS%3E%3CBR%20%2F%3E%3CADD%20key%3D%22%26quot%3Baspnet%3AUseTaskFriendlySynchronizationContext%26quot%3B%22%20value%3D%22%26quot%3Btrue%26quot%3B%22%3E%3C%2FADD%3E%3CBR%20%2F%3E%3C%2FAPPSETTINGS%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1536553%22%20slang%3D%22en-US%22%3E%3CP%3EIf%20you%20see%20crash%20at%20the%20following%20call%20stack%2C%26nbsp%3Bthat%20mostly%20probably%20is%20because%20web%20application%20is%20currently%20configured%20to%20use%20Legacy%20ASP.NET%20Synchronization%20Context%2C%20but%20the%20code%20is%20using%20some%20new%20features%2C%20such%20as%20Tasks%20(from%20Task%20Parallel%20Library)%20that%20require%20usage%20of%20what%20we%20call%20%E2%80%9CTask-friendly%20ASP.NET%20Synchronization%20Context.%E2%80%9D%20The%20old%20(Legacy)%20context%20cannot%20handle%20some%20asynchronous%20calls%20properly%20and%20this%20leads%20to%20the%20crash%20as%20observed%20in%20the%20above.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWeb%20App%20Crashes%20frequently.%20Below%20are%20found%20in%20application%20event%20log%20each%20time%20of%20crash%3A%3C%2FP%3E%0A%3CP%3EApplication%3A%20w3wp.exe%3C%2FP%3E%0A%3CP%3EFramework%20Version%3A%20v4.0.30319%3C%2FP%3E%0A%3CP%3EDescription%3A%20The%20process%20was%20terminated%20due%20to%20an%20unhandled%20exception.%3C%2FP%3E%0A%3CP%3EException%20Info%3A%20System.NullReferenceException%3C%2FP%3E%0A%3CP%3Eat%20System.Web.ThreadContext.AssociateWithCurrentThread(Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.HttpApplication.OnThreadEnterPrivate(Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock(System.Threading.SendOrPostCallback%2C%20System.Object)%3C%2FP%3E%0A%3CP%3Eat%20System.Web.LegacyAspNetSynchronizationContext.CallCallback(System.Threading.SendOrPostCallback%2C%20System.Object)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.Tasks.AwaitTaskContinuation.RunCallback(System.Threading.ContextCallback%2C%20System.Object%2C%20System.Threading.Tasks.Task%20ByRef)%3C%2FP%3E%0A%3CP%3Eat%20System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext%2C%20System.Threading.ContextCallback%2C%20System.Object%2C%20Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext%2C%20System.Threading.ContextCallback%2C%20System.Object%2C%20Boolean)%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()%3C%2FP%3E%0A%3CP%3Eat%20System.Threading.ThreadPoolWorkQueue.Dispatch()%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ETo%20Resolve%20the%20issue%20add%20the%20following%20in%20web.config%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CAPPSETTINGS%3E%3CBR%20%2F%3E%3CADD%20key%3D%22%26quot%3Baspnet%3AUseTaskFriendlySynchronizationContext%26quot%3B%22%20value%3D%22%26quot%3Btrue%26quot%3B%22%3E%3C%2FADD%3E%3CBR%20%2F%3E%3C%2FAPPSETTINGS%3E%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1536553%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EWeb%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Microsoft

If you see crash at the following call stack, that mostly probably is because web application is currently configured to use Legacy ASP.NET Synchronization Context, but the code is using some new features, such as Tasks (from Task Parallel Library) that require usage of what we call “Task-friendly ASP.NET Synchronization Context.” The old (Legacy) context cannot handle some asynchronous calls properly and this leads to the crash as observed in the above.

 

Web App Crashes frequently. Below are found in application event log each time of crash:

Application: w3wp.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.NullReferenceException

at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean)

at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean)

at System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock(System.Threading.SendOrPostCallback, System.Object)

at System.Web.LegacyAspNetSynchronizationContext.CallCallback(System.Threading.SendOrPostCallback, System.Object)

at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(System.Threading.ContextCallback, System.Object, System.Threading.Tasks.Task ByRef)

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

at System.Threading.ThreadPoolWorkQueue.Dispatch()

 

 

To Resolve the issue add the following in web.config:

 

<appSettings>
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
</appSettings>