Bug 36185 - [XVS 4.0] Hang/freeze when opening or working on a solution that contains an Android project, during background Xamarin.Android "GetAdditionalResourcesFromAssemblies" Task
Summary: [XVS 4.0] Hang/freeze when opening or working on a solution that contains an ...
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: General ()
Version: 4.0.0 (C6)
Hardware: PC Windows
: High major
Target Milestone: C6SR0
Assignee: Bugzilla
: 36066 36094 36162 36301 ()
Depends on:
Blocks: 40982
  Show dependency tree
Reported: 2015-11-23 18:55 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-09-28 18:31 UTC (History)
24 users (show)

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

Experimental Xamarin.Android.Common.targets candidate fix (119.98 KB, text/html)
2015-12-02 23:23 UTC, Brendan Zagaeski (Xamarin Team, assistant)

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 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 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-23 18:55:16 UTC
[XVS 4.0] Hang/freeze when opening or working on a solution that contains an Android project, during background Xamarin.Android "GetAdditionalResourcesFromAssemblies" Task

## Regression status: regression between XamarinVS 3.11 and XamarinVS 4.0

The regression status is based on the volume of new reports of the issue from customers starting in XamarinVS 4.0 compared to the absence of reports in XamarinVS 3.11.

## Approximate steps to reproduce

1. Open a Xamarin.Forms project that contains both an iOS project as well as an Android project with many resource files.

2. Restore the NuGet packages.

3. Do some development: build, clean, rebuild the project, deploy to device, etc.

## Results

Visual Studio hangs for many minutes at one of these steps. In some cases the hang happens immediately upon opening the project, while in other cases it does not appear until later.

Note to the Xamarin team: the following call stack resembles Bug 34562, but the call stack from Bug 34562 includes a call to DownloadFile() that is _not_ present in this bug.

### Top of a sample call stack 

> ntdll.dll!_NtWaitForMultipleObjects@20()	
> KERNELBASE.dll!_WaitForMultipleObjectsEx@20()	
> user32.dll!76bec46b()	
> [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]	
> combase.dll!CCliModalLoop::MyPeekMessage(tagMSG * pMsg, HWND__ * hwnd, unsigned int min, unsigned int max, unsigned short wFlag) Line 3035	C++
> [Managed to Native Transition]	
> WindowsBase.dll!System.Windows.Threading.DispatcherSynchronizationContext.Wait(System.IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout)	
> mscorlib.dll!System.Threading.SynchronizationContext.InvokeWaitMethodHelper(System.Threading.SynchronizationContext syncContext, System.IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout)	
> [Native to Managed Transition]	
> mscorlib.ni.dll!72bc7552()	
> [Managed to Native Transition]	
> mscorlib.dll!System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[] waitHandles, int millisecondsTimeout, bool exitContext)	
> Xamarin.Android.Build.Tasks.dll!Xamarin.Android.Tasks.AsyncTask.WaitForCompletion()	
> Xamarin.Android.Build.Tasks.dll!Xamarin.Android.Tasks.AsyncTask.Execute()	
> Xamarin.Android.Build.Tasks.dll!Xamarin.Android.Tasks.GetAdditionalResourcesFromAssemblies.Execute()
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-23 18:58:14 UTC
## Possible temporary workaround

Some users have reported that deleting the hidden `.suo` file (when using Visual Studio 2013), or the hidden `.vs` folder (when using Visual Studio 2015) stops this problem temporarily.

(You'll need to set Explorer to show hidden files to be able to see the `.suo` file or the `.vs` folder.)

## How to diagnose whether you're seeing exactly this same problem

Collect the call stack of the "Main Thread" from the hung instance of VS using a second instance of Visual Studio:

1. Start a second instance (a "new window") of Visual Studio.

2. Close any open solutions in the new instance of VS.

3. Select "Debug -> Attach to Process".

4. Select the original hung instance of `devenv.exe` from the list of
"Available Processes".

5. Select "Debug -> Break All".

6. Make sure you have the "Debug Location" toolbar is enabled.

7. From the "Thread" drop-down menu in the "Debug Location" toolbar, select the
"Main Thread".

8. Open "Debug -> Windows -> Call Stack". If the Call Stack shows just
"[External Code]", then right-click "[External Code]" and select "Show External
Code" from the context menu before copying the information.

If you see "GetAdditionalResourcesFromAssemblies" in the call stack for the "Main Thread", then it is most likely that the hang your are hitting is due to this exact bug (Bug 36185).
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-24 02:05:51 UTC
Small wording correction for step 8 in Comment 1:

> 8. Open "Debug -> Windows -> Call Stack". If the Call Stack contains _any lines_
> that say "[External Code]", right-click "[External Code]" and select "Show
> External Code" from the context menu before copying the information.
Comment 10 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-24 02:06:02 UTC
## Status update

The XamarinVS team has been able to reproduce this issue locally and is
actively investigating a fix.
Comment 13 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-24 20:16:28 UTC
*** Bug 36162 has been marked as a duplicate of this bug. ***
Comment 16 wislon 2015-11-25 16:08:53 UTC
I've found the following works too:

0. Killing all instances of VS
1. Opening the solution in Xamarin Studio (windows version, on the same machine) 2. cleaning and rebuilding the entire solution
3. Closing XS
4. Reopening the solution in VS

also works. 

I don't know why, and git says there's been no changes to tracked files. But that doesn't mean the XS didn't do something to the untracked files (e.g. .suo or .vs as mentioned) which is enough to fix it until the next time.
Comment 18 Brendan Zagaeski (Xamarin Team, assistant) 2015-11-26 12:11:57 UTC
I am hiding Comment 17 to keep the bug report more readable. That stack trace matches comment 0, so there's no need for a duplication of it in another comment. Thanks!
Comment 19 Prashant Cholachagudda 2015-11-30 09:52:57 UTC
*** Bug 36301 has been marked as a duplicate of this bug. ***
Comment 27 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-02 23:23:00 UTC
Created attachment 14089 [details]
Experimental Xamarin.Android.Common.targets candidate fix

## Status update: experimental fix available

The Xamarin engineering team has an experimental candidate fix for this issue that can be applied fairly easily to an existing installation of Xamarin. It has stopped the problem successfully in my own local tests.

To try the fix:

1. Ensure you are using XamarinVS (the latest Stable Channel version as of today).

2. Download the "Xamarin.Android.Common.targets" file attached to this comment.

3. Copy the file into the following location, overwriting the existing file:

> C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets

## Cautions

This is an experimental fix. It adds a few lines to the `.targets` file to skip some resource processing steps during the initial project loading phase.

This change should be fairly safe. Skipping those resource processing steps is unlikely to cause any regressions as a side effect. I have also tested some basic resource update scenarios to ensure that they work correctly with this patch in place.

That said, if anyone tries this experimental fix and notices that it introduces a new issue related to Android Resources, be sure to leave a comment on this bug report with the details. Thanks!
Comment 28 wislon 2015-12-03 05:53:21 UTC
OK, I've been using it for a few hours now across a number of shared and PCL xam forms projects. Lots of opening and closing VS and solutions and reloading projects (was upgrading some nuget packages). 

Hopefully I'm not just one of the lucky ones, but it's been working flawlessly with XamarinVS Thanks guys!
Comment 29 xamarin-release-manager 2015-12-03 21:21:02 UTC
Fixed in version (cycle6-baseline)

Author: Dean Ellis
Commit: d300845536a04027eae6a4ce7a3797d54af855cc (xamarin/monodroid)
Included in Commit: 430364f4647e3f82c85e674c17bd01b74fdb1f0f (xamarin/XamarinVS)
Comment 31 Brendan Zagaeski (Xamarin Team, assistant) 2015-12-04 17:46:00 UTC
I am hiding Comment 30 to keep the bug report more readable. As per Comment 1 ("If you see "GetAdditionalResourcesFromAssemblies" in the call stack"), that stack trace matches Comment 0, so no need to keep the duplicate stack trace visible in another comment.

As discussed in Comment 27, the Beta channel does _not_ yet include the fix for this issue. In order to apply the candidate fix you would need to download the additional file from Comment 27 and install it as described there.

(Alternately, if we consider the version number mentioned in the automated Comment 29 ("Fixed in version"), we can see that the current Beta version has a lower build number: "", so it would not be expected that the patch for this issue would be included in the current Beta version.)

## Tip for other users who might attach stack traces in the future

If any other users wish to attach stack traces to this bug report, feel free to attach them as text files rather than pasting them into the body of the comment. That will help keep the bug report more readable. Thanks!
Comment 32 Ben Beckley 2015-12-04 19:15:16 UTC
Hi all,

I spent some time and was able to reproduce this on when using the test case provided in Comment 26. Below is a screenshot of the call stack after attaching to the hanging VS process[1] along with the full call stack[2].

I updated to the current candidate build and was not able to reproduce the issue after multiple attempts. These attempts included:

1) Using a "dirty" solution - this test case had just been used (and thus the .suo was verified to be problematic) in the reproduction of the issue before upgrading the build. I was able to load and build the solution without any hang.

2) Using a "clean" solution - this test case was a fresh extraction from the .rar file that Brendan provided. I was able to load and rebuild the solution without any hang.

3) Using the same setup as the above verification, I also restored the solution's NuGet packages and did not experience any hang.

[1] http://screencast.com/t/rfcNPq0Ijx4
[2] https://gist.github.com/BenBeckley/37c7ce1aa5910b44af4a
Comment 33 Brendan Zagaeski (Xamarin Team, assistant) 2016-02-23 23:37:12 UTC
*** Bug 36094 has been marked as a duplicate of this bug. ***
Comment 36 Ivan Toledo 2016-04-21 14:14:00 UTC
I'm using the latest stable Xamarin.Android version and I hit this bug everytime with a solution that contains many Xamarin.Android binding projects.

The workaround is to delete the .vs folder, but it gets tiresome after a while.

VS2015 Update 2
Comment 37 Yogi 2016-09-28 15:06:10 UTC
We have VS 2015 update 3 with patches. We have latest Xamarin Stable updates installed. Visual Studio just hangs while loading the iOS project. After deleting the .vs folder, everything starts working.
Comment 38 Brendan Zagaeski (Xamarin Team, assistant) 2016-09-28 18:31:44 UTC
Note that this particular bug can be considered closed.  New appearances of similar issues will need to be filed in their own new bug reports for them to be investigated.  Be sure to include the call stack of the main thread as described in Comment 3 in the _new bug report_ (or even better, attach the full minidump _without_ heap [1]) Thanks!

[1] https://msdn.microsoft.com/en-us/library/d5zhxt22.aspx