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.
[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.
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
> [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]
> [Managed to Native Transition]
> mscorlib.dll!System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle waitHandles, int millisecondsTimeout, bool exitContext)
## 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
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
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).
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.
## Status update
The XamarinVS team has been able to reproduce this issue locally and is
actively investigating a fix.
Duplicate forum threads (just for thorough bookkeeping):
> - http://forums.xamarin.com/discussion/55944/can-no-longer-load-xamarin-forms-solution-in-vs-2015/p1
> - http://forums.xamarin.com/discussion/56260/visual-studio-hangs-loading-solution/p1
> - http://forums.xamarin.com/discussion/56283/visual-studio-freezes-when-loading-a-xamarin-project
> - http://forums.xamarin.com/discussion/55947/vs2015-hangs-after-xamarin-4-0-installation/p1
*** Bug 36162 has been marked as a duplicate of this bug. ***
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
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.
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!
*** Bug 36301 has been marked as a duplicate of this bug. ***
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 18.104.22.1687 (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
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!
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 22.214.171.1247. Thanks guys!
Fixed in version 126.96.36.1996 (cycle6-baseline)
Author: Dean Ellis
Commit: d300845536a04027eae6a4ce7a3797d54af855cc (xamarin/monodroid)
Included in Commit: 430364f4647e3f82c85e674c17bd01b74fdb1f0f (xamarin/XamarinVS)
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 188.8.131.526"), we can see that the current Beta version has a lower build number: "184.108.40.2067", 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!
I spent some time and was able to reproduce this on 220.127.116.110 when using the test case provided in Comment 26. Below is a screenshot of the call stack after attaching to the hanging VS process along with the full call stack.
I updated to the current candidate build 18.104.22.1688 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.
*** Bug 36094 has been marked as a duplicate of this bug. ***
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
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.
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 ) Thanks!