Asynchronous code without waiting for completion

Question

I am currently having problems with IIS failure, leaving the following messages in the event log. They are not very useful for directing me to the actual source of the error, but few studies show that this is just a case of spawning tasks, but does not wait for the result when they eventually end, if the parent process completed it, be connected with the parent a thread that raises a null reference exception. It is right?

For the most part, I deleted or added where this happens, but there are some areas where it is convenient. One such example is starting a session — caching memory with several details that are unique to the session, however they are not vital immediately, so I run a task to do this work, but I do not expect it.

I added ConfigureAwait (false) , is this enough to prevent an error in the future? It seems like this will disable thread switching, which I suppose 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 

Answer 1

After a morning study of this problem, I eventually found that there was a way that could allow parents to get around expectations by creating this problem. Quick refactoring to prevent this problem.

In its simplest form, the code causing the problem was in 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 will return without waiting for getDataTask to complete. Refactoring to Stop This Fix