title: Visual Studio Community 2015 crashes on project building after updates
body: <p>Greetings to all who can help,
  I have been running VS Community 2015 successfully for C# dev. on Win.8 on Mac/bootcamp. Tonight I wanted to try C++/CLI, and downloaded the packages recommended by VS.</p>
  
  <p>Now the thing crashes when building the simplest C# console program. The JIT-debugger with the following error:</p>
  
  <p>Unhandled exception at 0x6F1F0192 (msenv.dll) in devenv.exe: 0xC0000005: Access violation reading location 0x00000010.</p>
  
  <p>If there is a handler for this exception, the program may be safely continued.</p>
  
  <p><strong>the debugger pop-up window says:</strong>
  An unhandled exception of type 'System.AccessViolationException' occurred in Microsoft.VisualStudio.Shell.14.0.dll</p>
  
  <p>Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.</p>
  
  <p><strong>And general help for this error links to:</strong>
  <a href="https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&amp;l=EN-US&amp;k=k(EHAccessViolation)&amp;rd=true" rel="nofollow">https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&amp;l=EN-US&amp;k=k(EHAccessViolation)&amp;rd=true</a></p>
  
  <p><strong>stating:</strong>
  An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value. Not all reads or writes through bad pointers lead to access violations, so an access violation usually indicates that several reads or writes have occurred through bad pointers, and that memory might be corrupted. Thus, access violations almost always indicate serious programming errors. An AccessViolationException clearly identifies these serious errors.
  In programs consisting entirely of verifiable managed code, all references are either valid or null, and access violations are impossible. An AccessViolationException occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.
  Starting with the .NET Framework 4, AccessViolationException exceptions thrown by the common language runtime are not handled by the catch statement in a structured exception handler if the exception occurs outside of the memory reserved by the common language runtime. To handle such an AccessViolationException exception, you should apply the HandleProcessCorruptedStateExceptionsAttribute attribute to the method in which the exception is thrown. This change does not affect AccessViolationException exceptions thrown by user code, which can continue to be caught by a catch statement. For code written for previous versions of the .NET Framework that you want to recompile and run without modification on the .NET Framework 4, you can add the element to your app's configuration file. Note that you can also receive notification of the exceptions if you have defined a handler for the AppDomain.FirstChanceException or AppDomain.UnhandledException event.</p>
  
  <p>Can anyone here help me make sense of this, cause I didn't yet write any unmanaged code, VS crashes on a hello world program. Your help is appreciated</p>