error MSB4014 when building any Visual C++ project - by ED4729EF-05DF-4AD9-A210-7F334B070454

Status : 


Sign in
to vote
ID 535129 Comments
Status Active Workarounds
Type Bug Repros 11
Opened 2/21/2010 5:25:12 AM
Access Restriction Public


Building any Visual C++ project in Visual Studio 2010 RC fails with the following error:
error MSB4014: The build stopped unexpectedly because of an internal failure.
Microsoft.Build.Exceptions.BuildAbortedException: Build was canceled. MSBuild.exe could not be launched as a child node as it could not be found at the location "C:\Windows\Microsoft.NET\Framework\v4.0.30128\MSBuild.exe". If necessary, specify the correct location in the BuildParameters, or with the MSBUILD_EXE_PATH environment variable.
   at Microsoft.Build.BackEnd.NodeManager.AttemptCreateNode(INodeProvider nodeProvider, NodeConfiguration nodeConfiguration)
   at Microsoft.Build.BackEnd.NodeManager.CreateNode(NodeConfiguration configuration, NodeAffinity nodeAffinity)
   at Microsoft.Build.Execution.BuildManager.PerformSchedulingActions(IEnumerable`1 responses)
   at Microsoft.Build.Execution.BuildManager.HandleNewRequest(Int32 node, BuildRequestBlocker blocker)
   at Microsoft.Build.Execution.BuildManager.IssueRequestToScheduler(BuildSubmission submission, Boolean allowMainThreadBuild, BuildRequestBlocker blocker)
Additional information:
- "MSBuild.exe" exists at the location mentioned in the error message.
- Building C# projects works.
Sign in to post a comment.
Posted by yecril on 6/19/2013 at 1:44 AM
No files get generated to %TEMP% called MSBuild_CommsTrace_xxxx.txt. However, there are files called MSBuild_CommTrace_PID_????.txt, containing:

OutOfProc Endpoint Packet Pump (TID 4) 635072279767609637 +         1ms: Waiting for connection 900000 ms...

(TID 14) 635072278565819470 +         2ms: Successfully launched msbuild.exe node with PID 5572
(TID 14) 635072278566199508 +        38ms: Attempting connect to PID 5572 with pipe MSBuild5572 with timeout 30000 ms
(TID 14) 635072278866259511 +     30006ms: Failed to connect to pipe MSBuild5572. The operation has timed out.

BTW, here is a script that does the right thing:

$msbuild = ps MSBuild
if ($msbuild) { kill $msbuild }
if (ps MSBuild) { Write-Error 'MSBuild not killed!' }
# and that any instances of those files in %TEMP% are removed.
$pat = $env:temp + '\MSBuild_CommTrace_PID_????.txt'
rm $pat
if (dir $pat) { Write-Error 'Traces not killed!' }
Start-Process devenv
Posted by HelgeKlein on 3/3/2012 at 5:56 AM
I have this problem occasionally on Win7 SP1 and VS 2010 SP1 with Microsoft Security Essentials as virus scanner.

It occurs only with one C++ project. Restarting VS fixes it (temporarily).
Posted by maspeir on 2/23/2012 at 10:43 AM
I am having the same problem. XP SP3 + hotfix and no solution.

This is by no means optimal, but I found that if I copy MBBuild out of the Windows directory into my project directory that I can drag my solution file onto the MSbuild icon and it will build.
Posted by net12345 on 1/11/2012 at 4:55 AM
I get the same error messages although I applied the KB2298853 hotfix. The hotfix only avoids that I have multiple MSBuild processes running after the error occurred.

My installation:
MS VS 2010 Professional - ENU Version 10.0.40219
MS VS 2010 Service Pack 1 Version 10.0.40219
MS .NET Framework 4 Multi-Targeting Pack 4.0.30319
MS .NET Framework 4 Extended 4.0.30320
MS .NET Framework 4 Client Profile 4.0.30320
McAffe VirusScan Enterprise Ver. 8.7i is running,
No Avast Virus Scanner

My windows user name is shorter than 20 characters

The error message still exists. Is there a solution or workaround from Microsoft?
Posted by franck.revolle on 5/23/2011 at 9:22 AM
So, no feed-back about this issue...
On my daily PC, error apperas, disappears...
So, what to do next ? Buy a new PC ?
Posted by franck.revolle on 5/5/2011 at 8:25 AM
I have the same problem, I have applied the KB2298853 hotfix, re-installed VS2010.
My real project CANNOT be compiled on one XP-PC. This same project CAN be compiled on another XP-PC which is not mine ( without the hotfix, and same installation ).
I can compile a simple "hello world" Console program on the two PC.
Posted by David Schuman on 2/25/2011 at 11:37 AM
I have the same problem, I have applied the hotfix, re-installed VS2010. I can run msbuild from the visual studio command prompt, but not from within VS2010. My username is 4 characters long, so that can't be the problem.
I am running Win 7 64 bit on a single core processor. Task manager shows several msbuild.exe*32 processes before/after an attempt to build in VS2010.
Posted by JVGoertz on 2/11/2011 at 9:06 PM
same problem in Visual C++ 2010 Express with KB2298853 applied on Windows 7 64-bit in Fusion VM with one core assigned - problem disappeared when assigning two cores (out of two).
Posted by Acrab on 2/1/2011 at 10:38 AM
I am getting the same error message attempting to compile a basic application using SFML (an OpenGL/windowing library).
My user name is less than 20 characters (11 to be precise), and I have applied the patch specified below (KB2298853).
I am using Visual Studio 2010, starting from an empty project, on Windows 7 64-bit
Looking at the task manager after a failed build, I find a number of conhost.exe and MSBuild.exe *32 processes have spawned.
Any help you can give with this problem would be much appreciated.
Posted by DanMoseley - MSFT on 9/20/2010 at 1:32 PM

Published to Code Gallery:
Published to MS connect:
Posted by DanMoseley - MSFT on 9/16/2010 at 10:00 AM
There is a hotfix for this issue now, but it's not on the public knowledgebase. Please contact product support and ask for the patch for KB2298853.

Apologies for the bug here. It was a one liner in System.IO.Pipes.

Dan [MSFT]
Posted by David Kean1 on 8/30/2010 at 4:26 PM
By a future version of the Framework, we mean in a future version *after* .NET 4.0.
Posted by GeertVc on 8/28/2010 at 10:40 AM
Just installed C++ and the problem is still there. I'm using .Net Framework 4.0.30319 and can't find a more recent one (just did a reinstall of the latest .Net setup, without success).

Where can the .Net Framework that solves this issue, be found? Pls. provide link.
Posted by Microsoft on 6/11/2010 at 8:45 AM
Hello Alexander

This has been fixed in the next version of the framework

Thank you for reporting the issue

Vipul Patel
Base Class Libraries
Common Language Runtime Team
Posted by David M. Kean on 5/25/2010 at 8:38 AM
Jan: If you are blocked by this issue, please contact support directly (
Posted by Jan Willem Penterman on 5/25/2010 at 2:51 AM
When can we expect a permanent fix for this issue? There's no way I can use my workstation other than with my full 20 character name as I have a domain user account that is not to easily changeable into something shorter.
Posted by Microsoft on 5/5/2010 at 12:05 PM
Thank you for the feedback. We've confirmed that this is a bug and the fix will appear in the next available version of .NET Framework.


David Kean
Developer, Base Class Libraries Team
Posted by ares_123 on 3/4/2010 at 5:07 PM
I reproduced the username problem and confirmed too, and im using English US version.
Posted by ED4729EF-05DF-4AD9-A210-7F334B070454 on 3/3/2010 at 2:47 AM
My user name is exactly 20 characters long. If I run Visual Studio using another account with a shorter user name the issue disappears. So the length of the user name must be the problem.

Since I'm using C++ only for a small pet project this bug is not a big problem for me right now. I hope it will be fixed in the RTM build, though.

Thanks for your help, Cliff.
Posted by Cliff Hudson on 3/2/2010 at 1:50 PM
I have been able to reproduce the symptoms of this issue locally using a user name which is 20 characters long (this appears to be the limit of the number of characters you can enter for a username using the Windows UI.) Does your username happen to be 20 characters long? If you create an account with a shorter name, does it work for you?
Posted by Cliff Hudson on 3/2/2010 at 1:03 PM
Are you currently using a German-localized version of Visual Studio? Or are you running an English version on a German OS?
Posted by Cliff Hudson on 3/2/2010 at 12:59 PM
Thank you for the information. I haven't seen any issues with that call before. I wonder if it has something to do with the locale. I will pass this on to one of our pipe experts. I don't have a current workaround for you other than to build on the command-line, which I am sure would be very frustrating. I will try to track down a better solution and get back to you.

Posted by ED4729EF-05DF-4AD9-A210-7F334B070454 on 3/2/2010 at 12:48 PM
Cliff, I have 10 of these files now and all of them have the same content:
Waiting for connection 900000 ms...
Handshaking with host..
Client connection failed. Exiting comm thread. System.IO.IOException: Der an einen Systemaufruf übergebene Datenbereich ist zu klein.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode)
at System.IO.Pipes.NamedPipeServerStream.GetImpersonationUserName()
at Microsoft.Build.BackEnd.NodeEndpointOutOfProc.PacketPumpProc()
"Der an einen Systemaufruf übergebene Datenbereich ist zu klein." means "The data area passed to a system call is too small."
Posted by Cliff Hudson on 3/2/2010 at 9:59 AM

Could you please set the environment variable MSBUILDDEBUGCOMM=1, then run visual studio in that environment? (You can open up a Visual Studio Command Window from the start menu, set the environment variable, then run devenv.exe.) When you do this, some files will get generated to %TEMP% called MSBuild_CommsTrace_xxxx.txt. Before you do this, make sure no other instances of MSBuild.exe are running and that any instances of those files in %TEMP% are removed. We might be able to determine that there is an error of some sort occurring in the communication between the Visual Studio IDE and its external nodes which are used to build C++ projects.
Posted by omegainfinity on 3/2/2010 at 8:10 AM
Is it possible to use the batch file to override the default Build actions?
Posted by ED4729EF-05DF-4AD9-A210-7F334B070454 on 3/2/2010 at 3:41 AM
This is what I found out:
- No other version of the .NET Framework 4.0 are installed
- MSBuild.exe exists at the expected location
- Permissions on MSBuild.exe look good ("Users" group has "Read" and "Execute" permissions)
- Building from the command line works

Posted by Cliff Hudson on 3/1/2010 at 9:55 AM
By 'command window' do you mean the command window within Visual Studio? That would not be expected to work. Instead, you should open up a Visual Studio Command Prompt, which you can find under Start->Programs->Microsoft Visual Studio 10.0->Visual Studio Tools->Visual Studio Command Prompt. Here, you can execute your build. Note that like all command-line arguments, if the path to your solution file contains spaces, you will need to put it in quotes, such as:
msbuild "C:\My Path Has Spaces\My Solution.sln"
If *that* doesn't work, then we need to figure out if your install has gone wrong or if there is some other error occurring.
Posted by ares_123 on 2/27/2010 at 10:28 AM
Cliff, i have the same problem i decided to reply, ive been monitoring this page for a while waiting for response. I did try "msbuild C:\Documents and Settings\Compaq_Administrator\My Documents\visual studio 2010\Projects\test\test.sln"
in the "Command Window" and what i got is: Command "msbuild" is not valid.
Id also want to state that building c# and vb works.
Posted by Cliff Hudson on 2/25/2010 at 8:12 PM
This error would normally occur if your MSBuild.exe did not exist or was not accessible at the path specified. Can you verify that you have permissions to the MSBuild.exe at that location? Can you build the project/solution from the Visual Studio 2010 command-line (msbuild <your_project_or_solution_file>)? Do you have any other versions of the .Net 4.0 framework installed. Go to %windir%\\framework and see if there are any other v4.0 directories there - there should only be v4.0.30128 and the earlier versions of 3.5, 3.0 etc.
Posted by Microsoft on 2/22/2010 at 7:01 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(