Bug 41133 - System.MethodAccessException: Method `System.Net.WebHeaderCollection:AddValue (string,string)' is inaccessible from method `System.Net.Http.HttpClientHandler
Summary: System.MethodAccessException: Method `System.Net.WebHeaderCollection:AddValue...
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Windows
: Normal normal
Target Milestone: 15.1
Assignee: Bernhard Urban
: 44134 46176 ()
Depends on:
Reported: 2016-05-17 15:12 UTC by David Petrík
Modified: 2017-06-13 16:13 UTC (History)
33 users (show)

Tags: ExPT, xamexttriage
Is this bug a regression?: ---
Last known good build:

Test (529.95 KB, application/zip)
2016-08-22 12:03 UTC, Marek Safar

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description David Petrík 2016-05-17 15:12:13 UTC
System.MethodAccessExceptionMethod `System.Net.WebHeaderCollection: AddValue (string, string) 'is inaccessible method from` System.Net.Http.HttpClientHandler / <SendAsync> c__async0: MoveNext ()'
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start <TStateMachine> (ref TStateMachine Statemachine)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder <TResult> .start <TStateMachine> (ref TStateMachine Statemachine)
System.Net.Http.HttpClientHandler.SendAsync (HttpRequestMessage request, CancellationToken cancellationToken)
System.Net.Http.HttpMessageInvoker.SendAsync (HttpRequestMessage request, CancellationToken cancellationToken)
System.Net.Http.HttpClient. <SendAsync> __ BaseCallProxy0 (HttpRequestMessage request, CancellationToken cancellationToken)
System.Net.Http.HttpClient.SendAsyncWorker ()

There is no known method how to reproduce this problem yet. You must analysis your source code. HttpClient is unusable after this exception (including new instances)

More information is inside this thread

Comment 1 Tobias Schulz 2016-05-19 13:45:10 UTC
This is a major problem for us too. It happens with apps that were during the last few weeks.
Comment 2 Marek Safar 2016-05-24 09:39:01 UTC
Could you provide more details?

Are you running desktop httpclient, or android, or ios something else?

Does this happen with linker disabled?

There should not be anything random in this failure so I am not sure how to reproduce it yet. The method is called only when web request content headers are filled which is usually done by user code based on some conditions.
Comment 3 Tobias Schulz 2016-05-24 09:47:34 UTC
I don't beliebe that it has anything to do with the WebHeaderCollection class or the AddValue method at all.

I get the following error related to ServicePointManager:CloseConnectionGroup.

When I check the dll file in the .apl with ILSpy, the CloseConnectionGroup method is most certainly there. So it can't be a linker issue, can it?

Maybe something in the Mono runtime is getting corrupted and it doesn't find the method, even if it's there.

This error is URGENT because it affects ~ 15% of our customers and we cannot possibly do anything to work around it!

System.MethodAccessException: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `System.Net.Http.HttpClientHandler:Dispose (bool)'

at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in <filename unknown>:0
at System.Net.Http.HttpMessageInvoker.Dispose (Boolean disposing) [0x0001c] in <filename unknown>:0 
at System.Net.Http.HttpClient.Dispose (Boolean disposing) [0x00023] in <filename unknown>:0
at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in <filename unknown>:0
at Digitalkraft.Framework.TimeHelper+<getCurrentTimestamp>d__0.MoveNext () [0x001aa] in <filename unknown>:0
Comment 4 Tobias Schulz 2016-05-24 09:52:14 UTC
There androiud api versions of the user's phones are all over the place. 18, 19, 22, 23.

It also doesn't matter whether the app is compiled with the stable or beta version of Xamarin.Android.

It does seem to happend only if the app is running for at least a couple of hours. Which is why I think it's a bug deep in the mono runtime which prevents it from finding the method although it must have been executed before.

There are multiple classes in the System.Net.Http namespace which are affected. As far as I can tell, it has never been anything unrelated to HTTP.

The HttpClient's MessageHandler does NOT matter. It happens with and without ModernHttpClient.
Comment 5 David Petrík 2016-05-24 10:11:33 UTC
Hi Marek,
we are using latest Xamarin Android (stable channel). We have no error reported on Xamarin iOS yet (only android version).

we use HttpClient which is defined inside portable library. This portable library is referenced from android application (no Xamarin Forms)

I could add additional info when our code sending exception to Xamarin Insights. But what information? 

I could send you our portable library source to email if you want ..... Or anythning else...

Thank you
Comment 6 Marek Safar 2016-05-24 10:36:36 UTC
This code is used quite commonly so I am still not sure what's exactly the trigger. It could be the PCL setup though.

Could you try to add e.g "Warning" header to your request and see if it fails.

e.g. headers.Warning.Add (new WarningHeaderValue (5, "agent", "\"txt\""));

It should fail with same exception but at different place.
Comment 7 David Petrík 2016-05-25 11:57:12 UTC
Hi Marek,
in my case everything works without problem (no exception at different place)

client = new HttpClient(new HttpClientHandler() { AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip });
client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));

client.DefaultRequestHeaders.Warning.Add(new System.Net.Http.Headers.WarningHeaderValue(5, "agent", "\"txt\"")); // Added Line
Comment 8 Marek Safar 2016-05-25 15:42:21 UTC
I tend to agree this is probably a race somewhere in JIT.

MethodAccessException happens only during JIT-ing. Which is usually once, here we are inside generic value-type which could play a part.

Second thing to consider is that the MethodAccessException would be correct in this case as both methods where this happens are internal but there is InternalsVisibleTo in System.dll which should cover that but could be related to the problem.
Comment 9 Travis Whidden 2016-05-27 15:07:51 UTC
Same issue for us.

Mono service running on a RP2 (ARM)

Mono JIT compiler version 4.2.1 (Stable Thu Nov 12 10:06:49 UTC 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.

The process is polling a bunch of devices with HTTP

Sample Code:

using (var client = new HttpClient())
                if (!string.IsNullOrEmpty(Username))
                    client.DefaultRequestHeaders.Authorization = CreateBasicHeader(Username, Password);

                // very low timeout - it should not take 3 second to process this request. If it does, the device must be offline.
                client.Timeout = TimeSpan.FromSeconds(3);

                var response = await client.GetAsync(_theUriHere);

                var responseContent = await response.Content.ReadAsStringAsync();

This call is being made about once a second to 6 different devices. Takes about 6-12 hours before this error occurs.. and at that point the process must be restarted for the HTTPClient to work again.

160527 02:10:59,150 -System.String[]. Error: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from m
ethod `System.Net.Http.HttpClientHandler:Dispose (bool)'

160527 02:11:00,110 -System.String[]. Error: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from m
ethod `System.Net.Http.HttpClientHandler:Dispose (bool)'

160527 02:11:00,119 -System.String[]. Error: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from m
ethod `System.Net.Http.HttpClientHandler:Dispose (bool)'

160527 02:11:00,127 -System.String[]. Error: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from m
ethod `System.Net.Http.HttpClientHandler:Dispose (bool)'
Comment 10 Tobias Schulz 2016-05-27 15:26:26 UTC
That's exactly what I experienced, it happens if the app is running for at least a couple of hours, and it happens in that code that had been executed before. (so if the project is JIT-related, why is it JIT'ed again?)

The problem is that apps "run" often for many days, but are suspended by Android.
Comment 11 Travis Whidden 2016-05-27 15:29:08 UTC
It must be something more part of the framework. I am running on an always-on Raspberry Pi 2, just polling json off 6 devices every second for data collection.
Comment 12 David Barrett 2016-06-01 16:02:03 UTC
For what it's worth, we've seen this on Xamarin.Android for a couple of years to varying degrees.  Seems like way back when it was fairly rare.  Now it's happening with more frequency.

We define a descendant interface/class that inherits from HttpClient in our Android code and inject that into a *PCL* service class implementation that accepts an interface.  So our shared REST code is where this exception is thrown.

System.MethodAccessException: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `System.Net.Http.HttpClientHandler:Dispose (bool)'
Comment 13 Travis Whidden 2016-06-01 17:28:16 UTC
I hope this can help someone. We do not seem to be having that same problem with this alternative code. It does not seem to use those same classes (have not checked the source). It would be nice if the source problem was fixed. I have not tested this under PCL, but it does work under Mono / Ubuntu without that error coming up anymore.

            var r = WebRequest.Create(uri);
            if (!string.IsNullOrWhiteSpace(Username))
                r.Credentials = new NetworkCredential(Username, Password);
            r.Timeout = 3000;

            using (var response = await r.GetResponseAsync())
                using (var stream = response.GetResponseStream())
                    if (stream == null) return null;
                    using (var reader = new StreamReader(stream))
                        var data = await reader.ReadToEndAsync();
Comment 14 David Petrík 2016-06-22 11:50:41 UTC
Hi Rodrigo, any news about our problem?

It is clear to me that you have a lot of work, but it often seems that your team rather preparing new things for Evolve 2017 etc.

Do you need some more info? How we can change priority of this problem (reports from our customers come every day)?
Comment 15 David Petrík 2016-07-04 09:37:35 UTC
Hi everybody,
meanwhile we use following a little less painful solution

#if __ANDROID__
if ((ex is MethodAccessException) && (ex.Message.Contains("System.Net.WebHeaderCollection:AddValue")))
    Logger.Instance.SendReport(ex, "Application must be killed. Thank you Xamarin, thank you Rodrigo :-)");

    await Xamarin.Insights.Save();

Comment 16 Albilaga Linggra Pradana 2016-07-19 05:34:24 UTC
This is still happening to me. Any other way except restarting app?
Comment 17 Albilaga Linggra Pradana 2016-07-19 05:35:56 UTC
This is still happening to me. Any other way except restarting app?
Comment 18 Travis Whidden 2016-07-19 15:01:09 UTC
My workaround above seems to have solved it for me. It should be fixed though :(
Comment 19 Rodrigo Kumpera 2016-07-20 00:51:06 UTC
Without any sort of code to reproduce this we can't realistically fix the issue.

I did multiple reviews of the code related to how we initialize visibility related fields and consume the InternalsVisibleTo attribute but nothing glaring shows up.

The test program doesn't need to be small or show the issue straight away.
Comment 20 Tobias Schulz 2016-07-20 01:00:40 UTC
Is there any kind of data we could provide you if this happens in our apps? If I give you an app of ours that has this problem, you will probably not be able to reproduce it because it is so random.

But I could integrate any kind of error handling you need, which would be executed when it happens on one of our customer's devices.

Is there a way to programmatically create a memory dump in a catch block? Or what exactly would you do if you could reproduce the issue?
Comment 21 Rodrigo Kumpera 2016-07-20 16:58:48 UTC
Hey guys,

We got one theory we'd like to validate. We want to know whether we're compiling the problematic method multiple times.

Travis, you mentioned you can repro this on you RP2, right? Can you run the RP2 service with -v and share the end of the log output when it crashes?

The initial output will be gigantic and you can ignore it, I'm interested at what happens close to the point where it crashes.
Comment 22 Travis Whidden 2016-07-20 17:24:34 UTC
Let me see if I can make a sample app to run under the raspberry pi -- I have already coded out a solution for our commercial application, but would love for this to be fixed. Where would you like the verbose output sent?  Might be to large for this chat.
Comment 23 Rodrigo Kumpera 2016-07-20 17:27:26 UTC
Travis, if you can comes with an app, we'll run it on our arm hardware to reproduce it.

The log output is probably going to be 1-2 Meg larger in total. You can compress and attach it to this bug report itself. If it contains private information, I'll create a private bug for you.
Comment 24 Albilaga Linggra Pradana 2016-07-20 17:28:42 UTC
yes this error is very random. I just know this error from xamarin insight and happen when my mobile app try to send something to my server. In my test device is work ok but from Xamarin Insight it happened in Android M only for now
Comment 25 Andreas B 2016-08-12 09:35:51 UTC
This is happening to me to. We're not using it from a PCL or anything, but simply a shared code project.
Android, latest stable.

For me, when it happens it happens pretty much directly, I do not have to run the app for hours to trigger it.

I can seem to trigger it sometimes (about 1 time per 30 tries or so), in the following scenario:
1. An activity is started, which starts up tasks with HttpClient requests.
2. Before any task has managed to finish run, or maybe even initialize and start(?), I immediately push a button to start another activity, which also starts tasks with HttpClient requests.

The error I'm getting is the System.Net.WebHeaderCollection: AddValue MethodAccessExceptionMethod. I haven't seen the System.Net.ServicePointManager:CloseConnectionGroup one yet.
Comment 26 Travis Whidden 2016-08-19 18:18:40 UTC
I did the best I could to reproduce on the RP2. Attached is the test code, the logs and executable.  Sorry for the delay on this.

This test just hits 4 different websites pulling data, until it fails.


It does actually fail, but not always the same issue. Looks like some other bugs happen which cause the application to exit.  the output logs are in here. little big.

Tested on:

Mono JIT compiler version 4.2.1 (Stable Thu Nov 12 10:06:49 UTC 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notifications: epoll
        Architecture:  armel,vfp+hard
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 27 Marek Safar 2016-08-22 12:03:43 UTC
Created attachment 17154 [details]
Comment 28 Marek Safar 2016-08-22 12:04:46 UTC
Test attached
Comment 29 Rodrigo Kumpera 2016-08-23 22:48:39 UTC
Hey Marek,

What's the expected output? 

How do I run it?

I ran the monotest.exe from your zip file with 4.6.0 and got a lot of the following:

Error, but not the error we are looking for: One or more errors occurred.
Got data 12
Got data 10
Got data 10

Is that good or bad?
Comment 30 Travis Whidden 2016-08-23 22:53:02 UTC
Your output is normal. That one error is just because sites it was pulling from must not be up anymore. but you can leave it running for a day or so, and see it fail eventually. The above reports show that it takes a long time for this to fail.  Feel free to modify the URLs and have it pull in more data. I just didn't want to DDoS some legit website.

The "Got Data x" shows how many bytes were received from the site.

Check out the very simple source file. Its only a few lines of code to attempt to repeat this problem.
Comment 31 Rodrigo Kumpera 2016-08-24 16:11:03 UTC
I let it run for a few hours and got nothing.
Comment 32 Marek Safar 2016-09-12 13:18:55 UTC
*** Bug 44134 has been marked as a duplicate of this bug. ***
Comment 33 Travis Whidden 2016-09-12 15:43:44 UTC
Hi Rodrigo,

You will see this happen over a longer period of time. If you have a spare raspberry pi 2 nearby -- let it run up to a week. Errors will trigger. 

I think that's why this takes so long to reproduce. People with long running processes seem to get hit by different exceptions.  

Appreciate you looking into it.

Comment 34 Anthony Rouneau 2016-09-13 06:59:11 UTC

I'm the writer of the Bug 44134 that was marked as duplicate of this one.

My problem happened inside a PCL, used inside a Xamarin Droid app.
I tested the PCL multiple times in a console app, and (as far as I can remember), the bug never triggered. The only occurrences of the bug were in the Xamarin.Droid app, using the PCL in an async Task.

I hope this helps...

Comment 35 David Petrík 2016-09-13 09:36:50 UTC
we have same architecture as Anthony. Xamarin Android project calls HttpClient defined inside PCL project. We use async tasks around HttpClient calls.

Our apllication crash many times per day (about 5% of users) on different phones with different OS versions (Android 4.1 - Android M)

Do you have acess to Raspberry pi? Coul'd you verify Travis code? We coul'd try to write something similar as Travis.

Thanks for more information

Comment 36 MelOS 2016-09-25 19:00:06 UTC
Guys, I recently installed the latest version of xamarin for VS(stable channel) AND uninstalled BitDefender completely as I was experiencing other problems deploying apps when BitDefender was installed. 

I am excited to report that it's been couple of days that I haven't received this message anymore. I am not sure which one fixed it but I have a feeling it was BitDefender uninstallation. Important: Disabling it wont cut it!! I realized this the hard way.

Comment 37 David Petrík 2016-10-06 12:20:32 UTC
we start using AndroidClientHandler after months of waiting. We coul'd confirm that problem dissaper.

But we have another problems, because there is missing implementaion of Timeout and CancellationToken.

More info is there


Hopefully it will help others

Comment 38 Marek Safar 2016-10-31 14:34:25 UTC
*** Bug 46176 has been marked as a duplicate of this bug. ***
Comment 39 Jeremy Kolb 2016-11-16 16:22:46 UTC
I'm suddenly seeing this with Xamarin
Comment 40 Justin Toth 2016-11-28 16:21:02 UTC
Is there any update on this? Rodrigo was given an app to repro the issue, and told it would take many days (or even 1-2 weeks), and yet said he couldn't repro after only a few hours. That was in August, I would've expected a more serious attempt at repro'ing (letting it run for 7-14 days) by now.

This is our number one crash report in our current release (2,000 crashes so far), and has been the highest occurring for many releases. The issue was reported a year and a half ago, it's disappointing to see so little attention paid to such a serious bug.
Comment 41 joeperkins 2016-12-08 22:27:00 UTC
Removing the HttpClient (Managed HttpClientHandler) and using HttpWebRequest, HttpWebResponse instead fixed all the following issues.

Note: AndroidClientHander was not tested.

1. Threading race conditions, source of the many types of System.MethodAccessException
2. DNS issues
3. unexpended connection loss or inability to connect to any endpoint after process has started.
4. Slow and hanging downloads

async HttpWebRequest example:

var request = (HttpWebRequest) WebRequest.Create(uri);  


using (WebResponse response = await request.GetResponseAsync())
    using (var stream = response.GetResponseStream())
        using (Stream fileStream = new FileStream(filePath, FileMode.Create))
Comment 42 Erwin 2017-01-06 21:03:06 UTC
I've put a delay between 2 processes that were highly likely to start at the same time doing the same thing with the Microsoft.Azure.Devices.Client.Transport.HttpClientHelper originating from the Microsoft.Azure.Devices.Client.PCL NuGet package. This 'solved' it... for now.
Comment 43 Miguel de Icaza [MSFT] 2017-01-17 16:54:40 UTC
Hard to reproduce, but it does exist.

Comment 44 joeperkins 2017-01-17 19:26:07 UTC
I feel that this bug and the bug below are possibly related and lost of network connection in a thread during IO or just before IO is the best way to reproduce. In my previous post about removing the HttpClient, I also added a mechanism to prevent IO when a network connection is not available before stating the IO thread. This little change may have played a role.

Comment 45 Bernhard Urban 2017-01-19 16:17:20 UTC
Zoltan came up with a repro with that I get a MethodAccessException crash instantly (not always, but pretty reliable):


Only on arm32/linux so far, no luck on amd64/darwin or amd64/linux, so it might be arm specific. reproduced on mono-4.8.0-branch/f11214c.
Comment 46 Bernhard Urban 2017-01-20 15:37:28 UTC
fix for master: https://github.com/mono/mono/pull/4277
fix for 4.8 (c9): https://github.com/mono/mono/pull/4278
Comment 47 Rodrigo Kumpera 2017-02-21 17:56:45 UTC
The fix landed for 15.1 / mono 4.8.1.
Comment 48 Luigi Saggese 2017-02-21 23:55:15 UTC
Bernhard I have released android app with mono fix reported into your pull request 4278-4277. But issue is not solved. My crash report tool (Firebase) report (mostly for API 23) This is stacktrace 

Caused by android.runtime.JavaProxyThrowable: 
System.MethodAccessException: Method `System.Net.Http.HttpClientHandler:Dispose (bool)' is inaccessible from method `System.Net.ServicePointManager:CloseConnectionGroup (string)' at (wrapper managed-to-native) 
System.Object:__icall_wrapper_mono_throw_method_access (intptr,intptr) at System.Net.Http.HttpClientHandler.Dispose (System.Boolean disposing) [0x0001d] in <7508248e311245cb89d277b254c5e98a>:0 at Xamarin.Android.Net.AndroidClientHandler.Dispose (System.Boolean disposing) [0x00007] in <9f9b58e53f054b4a8ff2361fe40bc1c8>:0 
at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in <7508248e311245cb89d277b254c5e98a>:0 
at System.Net.Http.HttpMessageInvoker.Dispose (System.Boolean disposing) [0x0001c] in <7508248e311245cb89d277b254c5e98a>:0 
at System.Net.Http.HttpClient.Dispose (System.Boolean disposing) [0x00023] in <7508248e311245cb89d277b254c5e98a>:0 
at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in <7508248e311245cb89d277b254c5e98a>:0 
at JR.SL.Services.JRBaseRestClient+<MakeRequestAsync>c__async2.MoveNext () [0x004cc] in <22ef47fadf794260ad9c35e9a6447864>:0 
--- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <c7b255bd809f47538071732ebf2fd5d2>:0 
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0004e] in <c7b255bd809f47538071732ebf2fd5d2>:0 
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x0002e] in <c7b255bd809f47538071732ebf2fd5d2>:0 
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x0000b] in <c7b255bd809f47538071732ebf2fd5d2>:0 
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1+ConfiguredTaskAwaiter[TResult].GetResult () [0x00000] in
Comment 49 Bernhard Urban 2017-02-22 15:37:56 UTC
Hello Luigi,

afaik this fix didn't make into a stable release yet.  What Xamarin Android version/revision do you use?
Comment 50 Luigi Saggese 2017-02-22 15:41:04 UTC
Mono 4.8.0 (mono-4.8.0-branch/9ac5bf2) (64-bit)
=== Xamarin.Android ===
Comment 51 Rodrigo Kumpera 2017-02-22 15:45:06 UTC
You need a release of Android with the fix, not of mono desktop.

Bernhard, maybe we can provide a link to an internal build of the next Xamarin.Android.

Luigi, are you on Mac or Windows?
Comment 52 Luigi Saggese 2017-02-22 15:45:49 UTC
Comment 53 Bernhard Urban 2017-02-22 16:09:06 UTC
Internal build for Xamarin Android on Mac OS that contains the fix:



I highly recommend to wait for the next official stable release (C9), which is about to happen in the next days.
Comment 54 Luigi Saggese 2017-02-22 16:16:32 UTC
I will let you know if bug happens again.
Comment 55 klark 2017-03-02 04:56:45 UTC
Same project,
Xamarin.VisualStudio_4.3.0.784 throw exception:  System.MethodAccessExceptionMethod ... is inaccessible method from...
Xamarin.VisualStudio_4.2.2.11 is Ok.
Comment 56 Bernhard Urban 2017-03-02 13:22:50 UTC
Klark, can you provide more information?  What project? Full stacktrace?
Comment 57 David Petrík 2017-03-02 13:38:18 UTC
we switch back from AndroidClientHandler (which is future incomplete and full of bugs) back to default handler and we could confirm that problem disappear in C9 (after week of internal testing). 

We going to release our application to production environment next week. I will inform you if problem occurs again.

Thank you for fix. 
Comment 58 Bernhard Urban 2017-03-20 16:30:58 UTC
Hi David,

what's the situation with your application regarding this issue?

Comment 59 David Petrík 2017-03-20 16:45:05 UTC
Hi Bernhard,
our application is more than two weeks in production. Everything works like a charm.

We had received many exceptions in Xamarin Insights per day in dark times :-) (Before this fix)

We don't have similar exception in Insights again. 

From my point of view is this problem fixed and coul'd be closed.
Comment 60 Luigi Saggese 2017-03-20 16:47:46 UTC
Also from my side. It's only 5 days but there are no crash on Firebase console of this kind of issue.
Comment 61 Bernhard Urban 2017-03-20 16:50:48 UTC
Awesome news, thanks David and Luigi!

I mark it as resolved, feel free to reopen if there are issues.
Comment 62 Swati Gangrade 2017-03-21 12:30:35 UTC
As discussed on slack with Kyle White- This issue looks hard to reproduce based on comments 59 and 60 mark this bug as verified