We released CodeSmith Generator 5.1 with the new requirements of the Microsoft .Net Framework 3.5. One of our experiences in upgrading to the .Net Framework 3.5 is issues we have run into like our customers reporting Visual Studio disappearing or closing extremely quick when they try to generate code using CodeSmith’s Visual Studio Integration. The following link Tools - Part 11 - Add-ins - Attempting to work around the “VS Silent Death” bug describes this issue in detail. Since his blog content is currently offline I’ll quote his content.
One very annoying and elusive problem that sometimes slam down on VS2008 / .net 3.5 SP1 developers is the “VS Silent Death” bug. It manifests itself by simply making the Visual Studio IDE ‘disappear’ at a random point such as when opening a project or when opening a certain type of file in Visual Studio.
The annoying part is the lack of feedback from VS that leaves many baffled. The VS IDE just “disappears” without any feedback, although there is always an entry in the Windows event log (app log) for each crash stating something along the lines of
*.NET Runtime version 2.0.50727.1434 - Fatal Execution Engine Error (79FEC5F0) (80131506)or
.NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (7A035E00) (80131506).
The elusive part of the problem is that for some users it happens only on rare occasions, while for others it can occur with relatively high frequency. It can happen for a specific project or solution on one machine while the same project/solution works fine on an identical machine next to it (and vice versa). This makes it tricky to reproduce and troubleshoot “on demand”.
A mitigating factor is if any tools or add-ins used reference the .net 3.5 framework, so it can happen more frequently when VS add-ins are installed but also when using certain features in VS2008/.net 3.5 such as ASP.Net MVC, Entity Framework, Linq-to-SQL, WPF, etc. The fact that third party add-ins are commonly affected has made it easy to put the blame on the add-ins; Microsoft’s PowerCommands, Huagati DBML/EDMX Tools, Jetbrains Resharper, Ankh, Gallio, and many other third party add-ins have been affected and sometimes blamed for causing the crashes. So has the WPF designer, L2S designer, MVC libraries etc. However, debugging* and research* points to corrupt NGen images and assembly load problems.
Finally Microsoft wakes up
There have been numerous reports* to Microsoft on this issue through Microsoft Connect but despite the reporting party supplying crash dump files for several of the reports they have all been closed with “not reproducible”. In fact, until very recently I have not found a single acknowledgement from Microsoft of this bug, even when actively pursuing an answer (i.e. asking them directly). A few days ago a Microsoft blogger, Jim Nakashima, wrote in his msdn blog that they have reproduced it when working with MVC in Azure projects and that the CLR team is working on a fix:
Fantastic. Great. Terrific.
So far there’s no “official” acknowledgement from MSFT of this bug or ETA for a hot fix on docs.microsoft.com. Not even Microsoft’s primary communication channels to the developer community (a.k.a. Scott Guthrie or Scott Hanselman’s blog) mention the problem except in user comments.
Microsoft has a patch, KB963676 that addresses this issue. After installing it on my repro-system it looks promising; I have not yet been able to trigger the ‘VS death’ after applying the patch. No word (yet) on when it will be publicly available, but I assume that affected parties can request this hot patch through MS Support by referring to the MSKB #.
The patch is now available for download from Microsoft connect. See Jim Nakashima’s announcement at Fix available: ASP.Net MVC RC Crash in a Windows Azure Cloud Service Project
A current workaround for this issue is to apply the Microsoft Visual Studio Patch
which is no longer available. It was referenced by
installing reboot your computer.