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
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.
While I'm not getting this error in the event log, the WiX crash issue is hitting us for C# based projects. I would be surprised if WiX has any specific logic for C++ projects given that it works using project binary output so I think this may occur for any project type build by WiX.
There are a couple known bugs in the Visual Studio integration for the WiX toolset. If you found a new issue or have more information about an already open bug, please add it to the WiX bug database at: sourceforge.net/tracker
We are getting intermittent occurrences of the Out Of memory crash on build. Are there plans on correcting this in the future? And is there a timeline or plan for the SP1 build. Each issue like this puts more pressure on me from management for making the switch to VS2010.
We are working on the OOM issues, and in fact some new fixes have already gone in. Scalability is a high priority for MSBuild and Visual Studio in general.
Not a crash, but a major functionality regression with building solution files:
I would love to see this fixed correctly.
@Boyd, if there's a bug, please make sure it's open in Connect. We don't open bugs directly from the forums, as then they're invisible outside of Microsoft.
@Brian, getting the OOM.
Please open a Connect bug. Include details of your solution, such as the size, languages and so forth, and any other useful information, such as whether the OS is 32 bit or 64 bit, and what the memory useage is at the time of crash. To get this, look in task manager -- look at the Commit Size column. In the OOM case VS is crashing either because (1) It's running out of VM space, ie., Commit Size or (2) there is a bug where far too much memory is requested or (3) your physical memory+pagefile size are unusually tiny. For (1) if you're not hitting 2GB on 32 bit or 4GB on 64 bit, it's (2) or (3). If you like, post back with the Connect ID. The most easy way of course for us to investigate is to send the solution itself. But we can't take that if it's confidential or GPL, so I realize that's probably not possible.
By the way, here's another way to know whether you have this problem. Windows will display a page suggesting that you email in order to help diagnose it. If you click on the email link the title of the email will reference bug number 861431. If you don't get this, this blog post does not apply to you.
We (or rather the CLR) are currently looking into whether we can issue a patch for the 20 character username crash. In the meantime the workaround is to create a user just for VS, and run it as that user. That assumes you don't need network access, etc.
I have updated this posting with an additional common problem relating to customized build processes. If you have missing targets in your build process, Visual Studio can crash under certain circumstances. Please see the post above.
A patch is in progress for the 20 character username crash.
There is a hotfix for the 20 character username crash, but it's not on the public knowledgebase yet. Please contact product support and ask for the patch for KB2298853.
The hotfix for the 20 character username crash is at connect.microsoft.com/.../DownloadDetails.aspx