Home Dashboard Directory Help
Search

MSBuild and ConHost remain in memory after parallel build by Brett Shearer


Status: 

Closed
 as By Design Help for as By Design


6
0
Sign in
to vote
Type: Bug
ID: 554791
Opened: 4/27/2010 9:08:57 PM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description

using the /Maxcpucount option to build a solution containing multiple CSharp projects results in MSBuild executables being left in memory.
Details
Sign in to post a comment.
Posted by ET3D on 6/28/2012 at 6:49 AM
"The ConHost really has nothing to do with MSBuild"

So why is there a conhost for every msbuild, and they appear and disappear in tandem?
Posted by Michael Bendtsen on 4/12/2012 at 12:15 AM
I see the same problem. We are using the upgrade template in Visual Studio 2010 TeamBuild and sometimes the files in BuildType folder is locked and cannot be deleted. Very annoying. All other developers think that TeamBuild is unstable.

I will try the /nodereuse:false, but I have to set this in every build definition I have.
Posted by Martin Moe on 9/13/2011 at 12:18 AM
I don't think this is good design. The default value should definitely not have the potential to lock up the build system, as it does in our case. The gain on this as opposed to starting up brand new agents is neglizable in a life-sized project with a lot of code and a lot of tests.

We are seeing concrete problems with this "feature" (that's why I post here). The effect is that the get operation before the build kicks off (recursive on the configuration folder) is not able to get dlls that we later import in TFSBuild.proj. They are locked by MSBuild agents hanging around from the previous build.

So I vote for the sensible default setting beeing not to sacrifize reliability for performance in this case. Please change.
Posted by Microsoft on 6/4/2010 at 4:01 PM
Thanks for taking the time to send us this feedback.

The behavior you are seeing is by design. MSBuild will continue running for 15 minutes after a build in case there is another build. This reduces the time for the build if you are building in the IDE or on the command line over and over again.

If you do not wish for MSBuild to hang around as above, you can use /nodereuse:false to when you invoke MSBuild.

The ConHost really has nothing to do with MSBuild. It is the Console host process which is a part of Windows.

For more information on ConHost, see for example: http://www.howtogeek.com/howto/4996/what-is-conhost.exe-and-why-is-it-running/

The NodeMode switch is used internally only, and is not supported for customer use.

I will close this issue as By Design.

Chuck England
Visual Studio Platform
Program Manager - MSBuild
Posted by Microsoft on 4/28/2010 at 8:19 PM
Thank you for reporting this issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 4/28/2010 at 1:39 AM
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)
Posted by Brett Shearer on 4/27/2010 at 9:26 PM
After a little research I've found that the process will terminate after 15 minutes.

int millisecondsTimeout = Math.Max(0, BuildParameters.NodeConnectionTimeout - ((int) span.TotalMilliseconds));

internal static int NodeConnectionTimeout
{
    [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
    get
    {
        return GetTimeoutVariableOrDefault("MSBUILDNODECONNECTIONTIMEOUT", 900000);
    }
}

I've set my connection timeout to 5000 and have resolved the issue.

Perhaps the hidden parameter (/NODEMODE) should be documented.
Sign in to post a workaround.