This appears bogus as both methods are internal and are being accessed legitimately by classes from within their library. My suspicion is that there is some flaw in the logic in AsyncMethodBuilderCore, but it is an area of Mono with which I am unfamiliar.

It doesn't happen all the time (order of 1% chance) and often goes away if the app is restarted. If it is going to happen, it happens straight away and keeps happening. I get it in Release (standalone) and Debug (shared library) modes equally. It is more likely to happen after an installation, which suggests some sort of library / timing issue.

I can occasionally trap it in the IDE, but I'm at a loss as how to proceed to debug it. Here is a full stack trace when one of the exceptions was thrown:

System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Net.Http.HttpClientHandler.<SendAsync>c__async0> (stateMachine={System.Net.Http.HttpClientHandler}) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Net.Http.HttpResponseMessage>.Start<System.Net.Http.HttpClientHandler.<SendAsync>c__async0> (stateMachine={System.Net.Http.HttpClientHandler}) in
System.Net.Http.HttpClientHandler.SendAsync (request=, cancellationToken=) in
System.Net.Http.HttpMessageInvoker.SendAsync (Parameters=) in
System.Net.Http.HttpClient.SendAsyncWorker (Parameters=) in
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Net.Http.HttpClient.<SendAsyncWorker>c__async0> (Parameters=) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Net.Http.HttpResponseMessage>.Start<System.Net.Http.HttpClient.<SendAsyncWorker>c__async0> (Parameters=) in
System.Net.Http.HttpClient.SendAsyncWorker (Parameters=) in
System.Net.Http.HttpClient.SendAsync (Parameters=) in
System.Net.Http.HttpClient.SendAsync (Parameters=) in
System.Net.Http.HttpClient.PostAsync (Parameters=) in
Log.ReportAsync (Parameters=) in
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Log.<ReportAsync>c__async0> (Parameters=) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Log.<ReportAsync>c__async0> (Parameters=) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Log.<ReportAsync>c__async0> (Parameters=) in
Log.ReportAsync (Parameters=) in
LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.OnOptionsItemSelected () in /Users/rupertrawnsley/LearnPad/Source/Mono/LearnPad.Android.Client/View/LearnPadActionBarActivity.cs:260
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in
LearnPad.Droid.Client.LearnPadActionBarActivity.OnOptionsItemSelected.AnonymousMethod__2 (Parameters=) in /Users/rupertrawnsley/LearnPad/Source/Mono/LearnPad.Android.Client/View/LearnPadActionBarActivity.cs:258
System.Threading.Tasks.Task<System.Threading.Tasks.Task>.InnerInvoke (Parameters=) in
System.Threading.Tasks.Task.Execute (Parameters=) in
System.Threading.Tasks.Task.ExecutionContextCallback (Parameters=) in
System.Threading.ExecutionContext.Run (Parameters=) in
System.Threading.ExecutionContext.Run (Parameters=) in
System.Threading.Tasks.Task.ExecuteWithThreadLocal (Parameters=) in
System.Threading.Tasks.Task.ExecuteEntry (Parameters=) in
System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem (Parameters=) in
System.Threading.ThreadPool.AnonymousMethod__0 (Parameters=) in

I am also starting an investigation on a very similar problem. I get the exception
System.MethodAccessException: Method System.Net.WebHeaderCollection:AddValue (string,string)' is inaccessible from method System.Net.Http.HttpClientHandler/c__async0:MoveNext ()'
Once I start getting the exception there is no way to work around it, I have to restart my app. I would be very interested in any progress anyone has done on that.

We have always created a new HttpClient because until recently there was a threading bug in Mono that stopped you reusing the same client. I've actually switched to a shared instance of HttpClient now for most requests in case it gets around this bug somehow.

So where would this code go usually? In an event handler? Maybe something else?

I can't say that I've ever seen these issues in my apps. I usually invoke that kind of code from ICommand implementations in my ViewModel, which in turn calls a Service, which is basically a singleton helper class, which does all the heavy lifting.

Yes, typically some sort of event handler would initiate the call (onRefresh for instance), often on the UI thread, but obviously context will have switched to a background thread (using async/await) by the time the HTTP code executes.

I don't use a particular view model component, but the structure is similar to what you describe: almost all HTTP requests are channeled through a small number of singleton functions that abstract away the complexities of the request and merely return the requested resource.

In case it's relevant: I forgot to mention in my example that I always set the Timeout property of the HttpClient to avoid an indefinite hang when making the request.

I don't think I'm doing anything particularly unusual, although my app does can download tens of resources at once over a short space of time. The fact that this problem is not experienced by many other users is surprising and probably relevant.

It smells like a threading problem deep in the async/await marshalling code. It must cause some sort of stateful corruption because once it happens, it continues to happen with every request.

I'd agree that you're probably not doing something unusual, as we're seeing the same issue still and are using ModernHttpClient as well. I double-checked and everywhere we instantiate a HttpClient we're passing in a ModernHttpClient handler.

Do either of you have a method of reproducing this? As mentioned by Rupert, this issue seems to happen very seldom and goes away after a fresh instance.

Ideally we'd be interested in a way to replicate this(Even if it's rare) with a sample project so that we can officially get this reported in our Bugzilla tracking tool. That way one of our platform engineers can investigate this further.

If either of you have a method of reproducing this in a sample repository, please feel free to reply to this forum post or start a bug report. I will personally move forward with a bug report once I can find a means of reproducing this.

Thanks for looking at this one. I'm afraid I haven't found a reliable reproduce for it yet, but I will certainly share it if I do.

There is a slim possibility it is related to this other rare bug for which I think I have found a reproduce. They are both deep in the heart of the HTTP code and manage to corrupt the stack irrevocably. Perhaps they are different presentations of a problem with a common cause?

I am having the same issue.
With android, I do something like: call a webservice -> timeout (in 30s) -> kill app -> launch again -> and i meet this issue
When i get this issue, i can't call any webservice, must re-install app to do that.

When I look at the date of forum posts, it is quite sad that there is such a serious problem in one of most important part of today's applications which is the communication with the web. The worst part of it all is, that there is no way to make it functioning again, except of restarting the application. It is even worse, because even creating new HttpClient does not help there. So how we tell user, that he must restart an application/phone to let it function again? Many users even do not know, how to restart an app (they only know how to switch/minimize it).

If it was an issue in our code, I would definitely reserve maximum possible number of people for solving it. Unfortunately, we do not see another way to solve the problem except of code analysis. However, we are not much of help for searching through your code, with our team size of 3 programmers. As well as others, we do not have much chance to find out when the problem starts to occure.

I could not help, but the situation comes to me so, that Xamarin company is waiting until someone brings a problem on a silver platter and sends a test project. There is so much possitive energy during presenting new features everywhere and you are not able able to fix the problem in such an important part as HttpClient?

We are using your products for a long time and appreciate a work you do. However, I apologize for criticism, but in this case you simply deserve it.

@Jurij said:
We never had this problem before, but now it started occuring (at low rate).

Out of my head, only related thing changed was adding second server connection service that 'could' potentially be called during, or right after first service is complete with server api calls.

Could someone confirm similar scenario possibility?

This is my observation as well. I can reproduce it sometimes by starting a task with a HttpClient request, and immediately starting another task with another HttpClient request (different HttpClient objects).
There could be other problems as well, but this seems to be one of them at least.

The problem is within the Http client initialization. Bug may occur only within initial requests.

Multiple requests can potentially build up till Http Client is ready to process them upon internal initialization (then executed at same moment, sometimes causing it to bug internal Http Client state).

Our current workaround is to let only one request to be sent at start. Once sent, all rest awating requests can be released to run.
So far, problem is solved.

We've gotten 2,000 of these so far in our current release build, and for many releases this has been our highest frequency crash. It's sad that a year and a half later Xamarin still isn't paying attention to this egregious bug.

@JustinToth said:
We've gotten 2,000 of these so far in our current release build, and for many releases this has been our highest frequency crash. It's sad that a year and a half later Xamarin still isn't paying attention to this egregious bug.

You can use workaround from my earlier post above, we haven't had any problems since.
And I agree. We have to find bugs in their own source code and find workarounds, meanwhile they leave bugs untouched.

We aren't even allowed to update our Xamarin version for last few months, just because they still haven't decided to fix newly introduced bugs with newer versions. For example, the SQLite datetime bug which literally corrupts all our collected database data, luckily we found bug before we let it out in wild. Served for them on silverplatter, and yet ignored.