The official source of product insight from the Visual Studio Engineering Team
Since the release of Visual Studio 2010 we have received a few reports of crashing behavior which can be traced back to issues with MSBuild. We’ve analyzed all of these and there are several particular cases where a crash can occur. We’ve also added a notification to Windows Error Reporting to help guide those who hit these errors. You can determine you your error is one of these either by matching the problem description below, or looking in the Event Viewer as follows:
Fault bucket 1055654512, type 1 Event Name: APPCRASH Response: xxxxxxx Cab Id: 0
Fault bucket 1055654512, type 1
Event Name: APPCRASH
Response: xxxxxxx
Cab Id: 0
Problem: This can occur if the build process is missing a required target. This is normally due to an improperly customized build process. If you are using the .NET MicroFramework 4, which is not supported in Visual Studio 2010, you may also see this issue.
Solution: Provide the missing target. Try building the project/solution on the command-line. If MSBuild logs an error that a target is missing, that could be the problem.
Problem: COM registration requires the user have permission to certain registry keys, and lacking that permission the RegASM task crashes.
Solution: Ensure the registry keys needed to perform the registration are accessible to the account doing the registration. Look under HKCR\Record for the GUID matching the type (or types) associated with the COM components you are registering.
Problem: When building projects with Visual Studio 2010 and the .NET MicroFramework 4, the build would fail with an InvalidProjectFileException. The .NET MicroFramework 4 is not compatible with Visual Studio 2010.
Workaround: There is unfortunately no workaround for this. According to the .NET MicroFramework 4 team, the next version of the MicroFramework will support VS2010. Check out http://www.microsoft.com/netmf/default.mspx for updated information.
Problem: Building on the command-line or from Visual Studio displays an error that MSBuild could not find MSBuild.exe during a C++ or multiproc build. If your username is exactly 20 character long excluding your domain (the maximum allowed under Windows), there is a bug in the .NET Framework which will prevent us from authenticating the other MSBuild nodes.
Workaround: Build under an account with a name that is less than 20 characters. The bug should be fixed in the next version of the .NET Framework.
Problem: Your build in Visual Studio aborts with an OutOfMemory exception. It may or may not also do this when built from the command-line. This occurs typically when there are a very large number of projects with a lot of interdependencies, or when projects have an extremely large number of source files.
Workaround: Build your solution on the command-line, so that your process does not have Visual Studio’s initial memory foot print; or build on a 64-bit machine under a 64-bit command window so we can take advantage of the additional virtual memory spacel or split your solution into smaller chunks which can be built individually; or create a solution configuration in which only a subset of your projects build.
Problem: When building a solution which contains C++ and WiX projects, Visual Studio may crash.
Solution: This problem has been traced to a bug in the WiX project system. Please contact the WiX project for a newer version with the correct bits.
Problem: You have a solution with customized projects that make use of Microsoft.Common.targets (this has been commonly seen but is not the only possibility) and during the course of your customization, you eliminated one or more targets which are referenced by the included targets. For instance, if you create a custom build process that utilizes the ‘Compile’ target, but you di not implement the ‘CoreCompile’ target (which Compile depends on by default), then the build process will generate an error. In VS this error can manifest as a crash. This issue can occur under various permutations of this issue where there is a missing required target in your project (or one of its imports.)
Solution: Ensure that all referenced targets exist (even if empty) or remove dependency references to non-existent targets.
For some crashing issues we have set up Windows Error Reporting so that it will automatically request for you to send us additional information and contact us directly. If you see such a request, please consider providing us with the requested additional information so we can either determine that your issue is already known or address it in the next version of the product.
Has anyone noticed that in large solutions, pressing F5 (debug) on a mid-way project seems to want to build projects that are higher up in the dependency chain. It's quite annoying.
In my solution there are 27 projects which are related and written in C# & VC++ . I am trying to migrate it to VS2010 from VS2005 and targetting .NET Framework 4.0 . When I am building with Visual Studio 2010, it building successfully but when try to build from cmd line [devenv.exe] i am getting below exception.
An unhandled microsoft .net framework exception occurred in MSBuild.exe [3116] .
Some times i get
An unhandled microsoft .net framework exception occurred in devenv.exe [2440].
Please help.
Thanks,