Unexplained AppDomainUnloadedException when running a unit test on TFS Build server - by RobSiklos

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 797525 Comments
Status Closed Workarounds
Type Bug Repros 12
Opened 8/15/2013 2:09:07 PM
Access Restriction Public


I have a particular unit test which is causing an AppDomainUnloadedException to show up in the build log.  The test seems to run without any problems in Visual Studio (both on my workstation and Visual Studio running on the build server over remote desktop).

This is the output in the build log:

System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.

There are a couple of problems here:
1) It was very hard to discover which test was causing the problem, since the log file doesn't provide any indication about this
2) I need to find a way to catch and swallow this error, so that the build log is clean.
Sign in to post a comment.
Posted by Chuanbo Zhang on 2/22/2015 at 9:55 AM
this error might also show up when the Unit Test is an async Task return, and there is exception thrown from the UnitTest that is not caught.
Posted by 2re on 5/20/2014 at 4:03 AM
We also see this issue. It would be nice with a better warning message that could direct us in the right direction of the problem so that a lot of investigation can be avoided in case of multiple projects with multiple tests.
Posted by Nicklasviden on 3/5/2014 at 1:55 AM
Thanks for your assistance trying to solve the issue.
Unfortunately the suggested solution makes the Option Enable Code Coverage disappear in the Settings.
Is there a fix for this bug soon?
Posted by RobSiklos on 10/30/2013 at 6:39 AM
Thanks for your explanation Vinay.

I completely agree that unhandled exceptions such as this should be bubbled up as warnings.

However, my problem is that for cases in which the author of the test knows the warning is harmless, it should be possible to tell the test runner to ignore it.

As you can see from the example provided in the Details, the problem is completely out of our control (potentially a bug in System.DirectoryServices.AccountManagement). The test runner gives me absolutely no option to prevent or swallow the error.

Also, I was hoping to report this problem as a bug to whoever is in charge of System.DirectoryServices.AccountManagement. However, I'm unable to reproduce the AppDomainUnloadedException outside of Team Build. Perhaps you could provide some guidance as to how to create a minimal repro for the exception without relying on Team Build?
Posted by Microsoft on 10/29/2013 at 7:02 PM
In the old MSTest runner we were swallowing all exceptions and hence this was not showing up on the build log.
In the new runner, given the extensibility support for running other framework tests, we wanted to bubble up such inconsistencies as Warnings.
Closing this as By Design, please revert if you have concerns.

Posted by zer0nes on 10/26/2013 at 10:43 PM
I have the same issue. This happens when I run tests that refer a native dll via P/Invoke.
Posted by RobSiklos on 10/17/2013 at 7:21 AM
No - this is affecting our builds. We expect our builds to complete with no errors or warnings, but this defect causes the build to complete with warnings, where there should be none. This creates unnecessary noise which is distracting and makes real warnings not stick out as much.
Posted by Microsoft on 10/17/2013 at 7:04 AM
Thanks RobSkilos for your feedback.

I am assuming that this is harmless warning coming from the underlying library that you are using and is not affecting your builds. Is this correct?

Aseem Bansal
Posted by Microsoft on 8/16/2013 at 3:43 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 8/15/2013 at 2:52 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)