Bug 38378 - VS2015 Debugger sometimes fails to create System.Runtime.Serialization.dll in bin\Debug
Summary: VS2015 Debugger sometimes fails to create System.Runtime.Serialization.dll in...
Status: NEEDINFO
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger ()
Version: 6.0.1 (C6SR1)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-02-03 16:39 UTC by adrianknight89
Modified: 2016-05-13 18:03 UTC (History)
12 users (show)

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

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 for Bug 38378 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEEDINFO

Description adrianknight89 2016-02-03 16:39:08 UTC
This issue happens randomly. I'm using VS2015 on Win10 with an S6 device. The issue can also be observed in emulators. VS fails to start debugging session because bin\Debug folder is missing System.Runtime.Serialization.dll. Somehow this file fails to be created.

Also see here: https://forums.xamarin.com/discussion/59391/vs2015-debugger-freezes-on-initial-run#latest

Here's the error info:

Thread started: <Thread Pool> #5
01-19 08:18:43.146 D/Mono    (16368): [0xee875c00] worker starting
01-19 08:18:43.146 D/Mono    (16368): Assembly Ref addref Xamarin.Forms.Core[0xf4b960a0] -> System.Dynamic.Runtime[0xf4b96b20]: 2
01-19 08:18:43.146 D/Mono    (16368): Image addref System.Runtime.Serialization[0xee8c9ca0] -> System.Runtime.Serialization.dll[0xee888e00]: 1
01-19 08:18:43.146 D/Mono    (16368): Assembly System.Runtime.Serialization[0xee8c9ca0] added to domain RootDomain, ref_count=1
01-19 08:18:43.146 D/Mono    (16368): AOT module 'System.Runtime.Serialization.dll.so' not found: dlopen failed: library "/data/app/packageName-1/lib/arm/libaot-System.Runtime.Serialization.dll.so" not found
01-19 08:18:43.146 D/Mono    (16368): AOT module '/Users/builder/data/lanes/2512/d3008455/source/monodroid/builds/install/mono-armv7/lib/mono/aot-cache/arm/System.Runtime.Serialization.dll.so' not found: dlopen failed: library "/data/app/packageName-1/lib/arm/libaot-System.Runtime.Serialization.dll.so" not found
01-19 08:18:43.146 D/Mono    (16368): Unloading image data-0xee96a000 [0xee889300].
Comment 1 BOOM 2016-03-03 19:42:08 UTC
Confirm
The solution - multiple restart the project.
Pls fix
Comment 2 BOOM 2016-03-03 19:45:30 UTC
Xamarin Forms 2.1.0.6524
Visual Studio 14.0.24720.00 Update 1
Xamarin 4.0.1.96
Xamarin Android 6.0.1.10

(The bug was observed in the earlier versions.)
Comment 3 Ellen 2016-03-30 06:14:42 UTC
I'm facing the same issue
Comment 4 Marco 2016-03-30 10:01:29 UTC
same problem here.

The only thing i can do is restart until the project start but it's really annoying!

On 10 times, it happens 4.

Please, fix this bug!
Comment 5 BOOM 2016-03-30 10:03:14 UTC
Without breakpoints project launched successfully.
Comment 6 christine.blanda 2016-03-30 12:19:16 UTC
I get this issue even without breakpoints.  The first few times I can usually do a rebuild all and then it will run.  If that doesn't work I have to shut down VS and XAP and restart everything.
Comment 7 Korayem 2016-04-11 18:43:26 UTC
This happens with me in RELEASE mode
Comment 8 Mike 2016-04-17 12:14:48 UTC
This happens very often.  Please fix.  Very frustrating.
Comment 9 Dima 2016-04-17 12:24:09 UTC
Xamarin Forms 2.0.1.6505
Visual Studio 2013 12.0.31101.00 Update4

I experience this issue in DEBUG mode, no matter with or without breakpoints. It may happen up to 5 times in row. Restart everything always solve this but takes many time.
Comment 10 realspkr 2016-05-07 17:17:46 UTC
This defect has forced development to only be done with real hardware which is a significant difficulty. 

/data/app/packageName-1/lib/arm/libaot-System.Runtime.Serialization.dll.so is indeed missing on the emulator, and the apk being built does not contain it.
Comment 11 Brendan Zagaeski (Xamarin Team, assistant) 2016-05-09 21:29:20 UTC
Hi all,

Unfortunately, the reported message about System.Runtime.Serialization.dll.so from Comment 0 is not a sign of any problem. Nor is the message about "Unloading image...". These are normal ignorable informational messages from the Mono runtime.

If I had to guess, the real issue you all are seeing might be a variation on Bug 39433 (which has the same root cause as Bug 36078). As mentioned in Bug 39433, Comment 17, the candidate fix for that bug is currently available on the Beta channel [1] (and will hopefully be in the Stable channel soon).

[1] https://developer.xamarin.com/recipes/cross-platform/ide/change_updates_channel/




## Example GOOD launch that shows all of the same messages from Comment 0

For comparison, here's an excerpt from my adb logcat on a simple template app that just instantiates a DataContractSerializer. The app starts debugging successfully. As you can see, this log includes the same messages about AOT modules. Those messages are _ignorable_ unless you have explicitly enabled the experimental AOT feature [2].

[2] https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/part_1_-_preparing_an_application_for_release/#AOT_Compilation


> 05-09 16:50:25.099 D/Mono    ( 1009): Assembly Ref addref AndroidApp2[0x5a4e95f0] -> mscorlib[0x5a583b90]: 4
> 05-09 16:50:25.123 D/Mono    ( 1009): Image addref System.Runtime.Serialization[0x5c47b718] -> System.Runtime.Serialization.dll[0x5c4c02c8]: 1
> 05-09 16:50:25.123 D/Mono    ( 1009): Assembly System.Runtime.Serialization[0x5c47b718] added to domain RootDomain, ref_count=1
> 05-09 16:50:25.123 D/Mono    ( 1009): AOT module 'System.Runtime.Serialization.dll.so' not found: Cannot load library: load_library[1095]: Library '/data/data/AndroidApp2.AndroidApp2/lib/libaot-System.Runtime.Serialization.dll.so' not found
> 05-09 16:50:25.123 D/Mono    ( 1009): AOT module '/Users/builder/data/lanes/3053/a94a03b5/source/monodroid/builds/install/mono-armv7/lib/mono/aot-cache/arm/System.Runtime.Serialization.dll.so' not found: Cannot load library: load_library[1095]: Library '/data/data/AndroidApp2.AndroidApp2/lib/libaot-System.Runtime.Serialization.dll.so' not found
> 05-09 16:50:25.130 D/Mono    ( 1009): Unloading image data-0x5c3fc008 [0x5c464010].
> 05-09 16:50:25.130 D/Mono    ( 1009): Assembly Ref addref AndroidApp2[0x5a4e95f0] -> System.Runtime.Serialization[0x5c47b718]: 2
> 05-09 16:50:25.130 D/Mono    ( 1009): Assembly Ref addref System.Runtime.Serialization[0x5c47b718] -> mscorlib[0x5a583b90]: 5
> 05-09 16:50:25.154 D/Mono    ( 1009): Image addref System.Xml[0x5c46e5d0] -> System.Xml.dll[0x5c46d870]: 1
> 05-09 16:50:25.154 D/Mono    ( 1009): Assembly System.Xml[0x5c46e5d0] added to domain RootDomain, ref_count=1
> 05-09 16:50:25.154 D/Mono    ( 1009): AOT module 'System.Xml.dll.so' not found: Cannot load library: load_library[1095]: Library '/data/data/AndroidApp2.AndroidApp2/lib/libaot-System.Xml.dll.so' not found
> 05-09 16:50:25.154 D/Mono    ( 1009): AOT module '/Users/builder/data/lanes/3053/a94a03b5/source/monodroid/builds/install/mono-armv7/lib/mono/aot-cache/arm/System.Xml.dll.so' not found: Cannot load library: load_library[1095]: Library '/data/data/AndroidApp2.AndroidApp2/lib/libaot-System.Xml.dll.so' not found
> 05-09 16:50:25.177 D/Mono    ( 1009): Unloading image data-0x63000008 [0x5c46e778].
> 05-09 16:50:25.185 D/Mono    ( 1009): Assembly Ref addref System.Runtime.Serialization[0x5c47b718] -> System.Xml[0x5c46e5d0]: 2
> 05-09 16:50:25.193 D/Mono    ( 1009): Assembly Ref addref System.Xml[0x5c46e5d0] -> mscorlib[0x5a583b90]: 6
> Loaded assembly: System.Runtime.Serialization.dll
> Loaded assembly: System.Xml.dll



## Next steps

If the Beta channel build does _not_ help with the problem, then the engineering team will need additional diagnostic information to be able to troubleshoot the issue.

Typical verbose information for a problem like this would include:


1. Attach the IDE log files ("Help > Xamarin > Zip Logs").


2. Does the problem affects all projects or only certain projects? If it affects only certain projects, then attaching a minimized test case that consistent demonstrates the problem is _highly_ recommended if possible.


3. Does Visual Studio pause? Does the app pause? Is Visual Studio stuck in debug mode even though it never attaches to the app? A screen capture can often help address these kinds of questions. Please feel free to take a screen capture and attach it on the bug report to help illustrate the problem.


4. Attach the full adb logcat log from the failed debugging attempt. For example, run the following command after the failed attempt, and then attach back the `adblogcat.txt` file from your Desktop:

adb logcat -vtime -d > "%USERPROFILE%\Desktop\adblogcat.txt"



### See also

https://kb.xamarin.com/customer/portal/articles/1675684-where-can-i-find-my-version-information-and-logs-
https://kb.xamarin.com/customer/en/portal/articles/1910343-when-and-how-should-i-file-a-bug-report-
http://stackoverflow.com/help/mcve



Thanks in advance,
Brendan
Xamarin Customer Support
Comment 12 Jon Goldberger [MSFT] 2016-05-12 23:07:46 UTC
The customer in desk case #348315 has reported that not using the shared mono runtime has mitigated this issue, so perhaps it could be an outdated shared mono runtime that is causing the issue? I am going to suggest they remove the existing shared mono runtime form the device(s) so it will be re-installed and see if that helps.

I will post back with the findings.
Comment 13 Jon Goldberger [MSFT] 2016-05-13 18:03:38 UTC
The customer noted in the above comment 12 indicates that deleting the existing shared mono runtime from his device(s) seems to have resolved the issue. At least so far.