New VS feature allows VS to crash!

One of the newer "features" in Visual Studio 8.0 is the ability for us to collect better information about exceptions that are thrown in VS.  When an exception is thrown (and unhandled), VS will generate a Watson report that will send microsoft a minidump where the exception occurred.  Once we get this watson report, its easier now for us to locate the exact cause and issue a fix.

Of course, a side effect of this is that unhandled exceptions will bring down VS and may cause loss of data if you had not saved your current work.  This can be particularly bad in some scenarios where your control is being used in VS and throws an exception.  We do a lot to try to capture these exceptions.  For example, if the exception is thrown during designer load (when your control is being hosted in the windows forms designer) we will not shutdown VS.  Instead the user will see what we call the WSoD ("white screen of darn").  This indicates the callstack of the exception and disallows further edits to the form.  Also, if the exception is thrown as a result of a window message sent through the designer, we will catch the error and display it to the user.  An example of this is a button click or a mousehover/mouseover event.  These messages are intercepted by the designer before the control in the designer is allowed to process them.

There are, however, scenarios that we can not catch during design time.  If you throw an exception in a Timer_Tick event, this will not go through a designer and it will therefore bring down VS.  We could not change this behavior in the runtime because doing so would be a compat breaking change (apps that used to show the exception dialog in this case would no longer show it).

It should be rare that you encounter this error.  However, if you do -- it can be particularly painful.  Especially if it happens whenever a certain form designer appears.  What is worse, is that if a solution has stored that it should show a form immediately when you load the solution, you can end up in a situation where VS crashes every time you open the solution!  One fix here is to delete the .suo file.  This is a solution config file that stores what documents should be opened when the solution is opened.  If there is no .suo file, no documents are opened by default.  This will give you a chance to fix any errors (in code) that might be giving you problems.

Comments

• Anonymous
  September 18, 2005
  The most frequent problem is if you have a stack overflow exception in your custom control.
  
  
  The best way to debug this is to open up your visual studio command window and use the "mdbg" application to debug visual studio.
  
  
  
  c:> mdbg.exe
  r devenv.exe
  ca ee
  g
  
  This should help you track down your stack overflow exception. When you get it, you can type "where" to show the stack, if you want more frames type "where 200".
  
  
  
• Anonymous
  September 18, 2005
  Ben talks about working with custom controls that can crash VS, and how to delete the .suo file to prevent...
• Anonymous
  September 18, 2005
  The binary .suo file is a cause of problems in VS2k3, especially when sharing amongst a team.
  
  Any chance of making them readable (xml, say)?
  
  - Daniel