Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
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.
On certain rare Windows environments it is possible for activation to fail due to "GetAdaptersAddresses returned: 5"
I am filing this bug to record the results of an investigation into a rare activation problem that has only been seen on 1 user's computer so far.
## Steps for any other user who might hit this bug
If any other user hits this bug and finds that it is not solved by a simple reboot, please send an email to `email@example.com` and mention this bug number. That will help Xamarin keep a tally of the number of reports of this problem, and the Xamarin team will be able to send you the candidate workaround mentioned below.
## Error message from the `%LOCALAPPDATA%\Xamarin\Logs\[11.0|12.0|14.0]\*Ide.log` IDE log file
> System.Exception: Could not load machine data: error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
> System.InvalidOperationException: Wat; GetAdaptersAddresses returned: 5
> at Xamarin.Licensing.Interop.WinNetworkInterfaces.GetNetworkInterfaces () [0x00000] in <filename unknown>:0
> at Xamarin.Licensing.Interop.WinNetworkInterfaces.A () [0x00000] in <filename unknown>:0
> at Xamarin.Licensing.PlatformActivation.GetRegistrationXml (Mono.Touch.Activation.Common.License license) [0x00000] in <filename unknown>:0
> at Xamarin.Licensing.PlatformActivation.ShowDataFile () [0x00000] in <filename unknown>:0
> at Xamarin.Licensing.PlatformActivation.ProcessOptions () [0x00000] in <filename unknown>:0
> at MTouch.Main2 (System.String args) [0x00000] in <filename unknown>:0
> at MTouch.Main (System.String args) [0x00000] in <filename unknown>:0
> at Xamarin.Components.Ide.Activation.ActivationHandler.<>c__DisplayClass41_0.<LoadMachineData>b__0(Task`1 t)
> at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
> at System.Threading.Tasks.Task.Execute()
## Minimal steps to see the problem on the customer's computer
This problem seems to be caused an upstream issue in the Windows environment itself. It has only been observed on exactly 1 user's computer so far. And on that computer it was possible to obtain the same "bad" output from `GetAdaptersAddresses()` with the following minimal steps:
1. Create a new Windows32 console C++ program that does nothing more than call the `GetAdaptersAddresses()`  method.
2. Build the C++ program.
3. Rename the C++ binary to `mtouch.exe` and place it in `C:\Program Files (x86)\MSBuild\Xamarin\iOS`.
4. Create a console C# application that does nothing except (a) run `C:\Program Files (x86)\MSBuild\Xamarin\iOS\mtouch.exe --datafile` via `Process.Start()`, (b) capture the standard output and standard error, and (c) write the captured output to the console.
5. Run the C# console application.
Result: the call to `GetAdaptersAddresses()` still returns the "bad" value of 5.
(Note in particular that no Xamarin code is involved in this minimized test case. All the code involved is written and built from scratch in Visual Studio on Windows.)
Interestingly, moving the `mtouch.exe` binary to a different location (such as `C:\Xamarin\mtouch.exe`) was sufficient to stop the problem.
I provided the customer with a small "wrapper" C# program to use as a replacement for `C:\Program Files (x86)\MSBuild\Xamarin\iOS\mtouch.exe`. The replacement program used `Process.Start()` to call the real `mtouch.exe` (as shipped in the XamarinVS installer, but moved to a different location) and then redirected the output from the real `mtouch.exe` to its own output. That approach successfully worked around the problem.
(Adding a symlink from `C:\Xamarin\mtouch.exe` to `C:\Program Files (x86)\MSBuild\Xamarin\iOS\mtouch.exe` was not sufficient: `GetAdaptersAddresses()` still failed in that case.)
## Additional notes
- The `GetAdaptersAddresses()` error code of "5" supposedly means "Access is denied" .
- Android activation always succeeded without error. As expected given that result, calling `MSBuild\Xamarin\Android\mandroid.exe --datafile` never hit the `GetAdaptersAddresses()` error code in any of the tests. But it was possible to force `mandroid.exe` to hit the problem by copying it into `C:\Program Files (x86)\MSBuild\Xamarin\iOS\mtouch.exe` and repeating step 5 of the "Minimal steps to see the problem". So the problem seems to be entirely due to the location of the executable.
- I had the customer test whether the Access Control List (ACL) permissions might be different between `MSBuild\Xamarin\iOS` and `MSBuild\Xamarin\Android`. They were identical, so it seems those permissions don't account for the problem.
- To offer one possible explanation, there might have been some path-based system protection mechanism on the customer's computer that was preventing the `GetAdaptersAddresses()` method from being run by any executable located in the `MSBuild\Xamarin\iOS` folder. Off-hand I am not familiar with any protection mechanism like that on Windows, but I could believe that a feature like that could exist.
## The original customer's environment info
Windows 7, 64-bit in VMWare Fusion 8
I will mark this issue as "Resolved Upstream" for now because it seems to be a rare problem with Windows itself.
That said, as mentioned in Comment 0, if any other users hit this precise same "GetAdaptersAddresses returned: 5" error message and find that it is not solved by a simple reboot, please send an email to firstname.lastname@example.org and mention this bug number (Bug 39027). Thanks!