0

Our automatic bug reporting tool has picked up a very odd exception related to Task.ContinueWith. Log history shows affected users (only 14 total in one month) are in different areas of the program when this occurs, and looking at the stack trace I'm really doubtful the issue is in our code. The stack trace is as follows:

NullReferenceException Object reference not set to an instance of an object. 
<00000000000000000000000000000000> System.Threading.Tasks.ContinuationTaskFromResultTask`1[TAntecedentResult].InnerInvoke()
<00000000000000000000000000000000> System.Threading.Tasks.Task.Execute()
<00000000000000000000000000000000> System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx)
<00000000000000000000000000000000> System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task& currentTaskSlot)
<00000000000000000000000000000000> System.Threading.Tasks.Task.ExecuteEntry(System.Boolean bPreventDoubleExecution)
<00000000000000000000000000000000> System.Threading.ThreadPoolWorkQueue.Dispatch()
unknown Rethrow as AggregateException: A Task's exception(s)
unknown System.Threading.Tasks.TaskExceptionHolder:Finalize()

Looking at the source code for the ContinuationTaskFromResultTask.InnerInvoke() method, it looks like the only way this can throw a NullReferenceException is if the local antecedent field was null. Even then, the Contract.Assert method should be throwing a different exception.

Has anyone seen this before or know how this might occur?

Thank you

Jake Perry
  • 1
  • 1
  • Skepticism is usually a helpful trait, but in this case it's unwarranted. You don't have nearly enough evidence to rule out your own code, and strong reasons to implicate it. Web searches for the `ContinuationTaskFromResultTask()` method name and `NullReferenceException` turn up no information implicating a bug in the framework. And while they do exist, bugs in the framework that affect user code are exceedingly rare, as compared to bugs in user code. See marked duplicate for hints as to where your own code might have gone wrong. ... – Peter Duniho Jan 24 '20 at 01:23
  • 1
    ... Whether you believe it's your code or not, if you would like more assistance from Stack Overflow than that, you will need to post a better question, one that includes a good [mcve] that reliably reproduces the problem, and details explaining what you've done so far to debug the problem, what you've ruled out so far, and on what basis you've done so. – Peter Duniho Jan 24 '20 at 01:23

0 Answers0