Async code without waiting for completion

Question

I'm currently having issues with IIS crashing out leaving the following messages in the event log. They're not too helpful in directing me to the actual source of the error but a bit of research suggests this is just a case of spawning tasks but not waiting for the result, when they do eventually complete if the parent process has completed it cannot be associated with the parent thread which causes a null reference exception. Is that correct?

For the most part I have removed or added awaits where this was going on but there are some areas where it is handy. One such example is on session start is memory caching a few details unique to the session, however they're not vital immediately so I spin up a task to do this work but don't await it.

I have added ConfigureAwait(false), is this sufficient to prevent the error in future? It sounds like this will remove the thread switching which I assume will prevent the error.

Task.Run(() => { // Do caching here }).ConfigureAwait(false);

ASP.NET 4.0.30319.0

Exception: System.NullReferenceException Message: Object reference not set to an instance of an object. StackTrace: at System.Web.ThreadContext.AssociateWithCurrentThread(Boolean setImpersonationContext) at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean setImpersonationContext) at System.Web.LegacyAspNetSynchronizationContext.CallCallbackPossiblyUnderLock(SendOrPostCallback callback, Object state) at System.Web.LegacyAspNetSynchronizationContext.CallCallback(SendOrPostCallback callback, Object state) at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(ContextCallback callback, Object state, Task& currentTask) --- End of stack trace from previous location where exception was thrown --- at System.Threading.Tasks.AwaitTaskContinuation.<ThrowAsyncIfNecessary>b__1(Object s) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch()

.NET Runtime

Application: w3wp.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.NullReferenceException Stack: at System.Threading.Tasks.AwaitTaskContinuation.<ThrowAsyncIfNecessary>b__1(System.Object) 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()

Application Error

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2 Faulting module name: KERNELBASE.dll, version: 6.1.7601.18015, time stamp: 0x50b8479b Exception code: 0xe0434352 Fault offset: 0x0000000000009e5d Faulting process id: 0x1d98 Faulting application start time: 0x01ceaf8ea10ece66 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: C:\Windows\system32\KERNELBASE.dll Report Id: 341b9a76-1b82-11e3-8e17-005056be0005

Would it make more sense to use ThreadPool.QueueUserWorkItem? — Hawxby
– Hawxby, Commented Sep 12, 2013 at 10:38
IIS schedules handling of requests to the .NET thread pool. Unless you are doing parallel work in the same request, using Task.Run and ThreadPool.QueueUserWorkItem will hurt the performance of every running request because it will be performing unnecessary context switching. — Paulo Morgado
– Paulo Morgado, Commented Mar 10, 2014 at 17:34

abdullahalali · Accepted Answer · 2019-11-25 06:35:38Z

6

After a morning of chasing this problem around I eventually discovered there was a path which could allow for the parent to bypass the await creating this problem. A quick refactoring to prevent this solved the problem.

In its most simple form the code causing the problem was along the lines of this:

var getDataTask = getData(); if(some_condition == true) { return some_object; } getDataTask.Wait(); return getDataTask.result;

If some_condition == true the method would return without waiting for getDataTask to complete. Refactoring to stop that fixed it.

edited Nov 25, 2019 at 6:35

abdullahalali

4062 gold badges6 silver badges18 bronze badges

answered Sep 12, 2013 at 11:06

Hawxby

2,8041 gold badge24 silver badges30 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

deerchao Over a year ago

I'm also suffering this same exception randomly. Can you provide some more details, please? What does your code messed up look like?

Todd Menier Over a year ago

I wouldn't recommend this code. You still have a fire-and-forget code path, which is dangerous is a web app, plus you have introduced a blocking call with Wait(). Is getData() really doing something so time-consuming that awaiting it is not an option? Also, is there any significant CPU or I/O intensive work that needs to be done to come up with the value of "some_condition" or is it just a simple check against some value you already have?

Hawxby Over a year ago

Sorry I should clarify, I'm not recommending it either, that was the code causing the problem

Collectives™ on Stack Overflow

Async code without waiting for completion

1 Answer 1

3 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Linked

Related