How do you find a "First Chance Exception" recorded in Debug Output

How do you find a "First Chance Exception" recorded in Debug Output

• GameOver

  Thank you for that detailed reply! It instantly directed me to the issue (Debug | Exceptions and turned on ArgumentException -> Run and BINGO there the problem was...)
  
  I had been un-aware of the Exceptions Menu actually, wonderfully useful
  
  Thanks again!
  
  (EDIT: Annoyingly, it was in the source of a component we use, and wasn't really a "bug" just they used a large number of try...catch's to parse some data... Not sure I like the way it's done, will have to have a thinks about doing it another way)
  
  

• ArcJeremy

  Oops; my bad. Turns out there is a nested Try...Catch block I missed that was catching the error and issuing a Console.WriteLine. Now I have discovered the Output window as well as the Exceptions menu. That's progress.
  

• Lien Gangte

  Let me clarify for you what a first chance exception is and then I'll try and answer your question.  When an exception is raised in the system it is called a first chance exception.  This is the first time the system is giving you a chance to handle it.  If you have set up an exception handler then you're exception handler will be called at this time.  The debugger, if one is running, also gets a chance to deal with it.  If nobody handles it then a second chance exception occurs which in all probability will terminate the app.
  
  First chance exceptions can happen quite a bit in an app.  In fact the OS memory manager uses exceptions (at the hardware level) to know when to page in a page of memory that was swapped out.  Nevertheless you probably wouldn't ever see this exception in VS.  You'll see first chance exceptions whenever code attempts to do something and is protected by an exception handler.  Parsing code does this quite a bit.  Many parsing routines will wrap the parsing code in an exception handler and if something goes wrong may silently ignore some exceptions while rethrowing others.  So the appearance of a first chance exception, while negatively impacting performance, can happen with some regularity.  Without having a clearer idea of why the exception is occurring it is difficult to determine whether this is okay or not.
  
  In your case it would appear that the CLR is throwing, and then handling, an exception.  Without using the symbols for the CLR to get the line information and perhaps using Reflector or something to look at the code it is not easy to determine what caused the exception.  Depending on the type of exception you may get the exception message or at least the error code in the output window.  However  VS has an easier solution.  In VS you have access to the Exceptions dialog (from the Debug menu).  Within here you can tell the debugger to notify you whenever a first chance exception occurs for a variety of exceptions (or all of them).  By default the debugger will only tell you when the exception isn't handled but you can temporarily tell it to notify you of any exceptions.  Of course you may find that the debugger is continually notifying you of exceptions that you don't care about so you'll want to try and narrow down the exception that is being raised.  With .NET apps you'll actually have the option of handling various types of exceptions (.NET, CLR, Win32, etc.) differently.  Unless you know what exception is being raised (perhaps from the output window) then you'll need to be notified about all of them.  I don't remember the exact UI of VS 2003 so I can't tell you what to click but I think it is pretty straightforward.  Note that you can change these settings on the fly so you might want to get your app to the point where the exception occurs (perhaps using a breakpoint) and then have to notify on first chance exceptions.  This will save you from notifications that you don't care about. 
  
  In general however the first chance exceptions are probably harmless, other than performance, and therefore you may not be able to do anything about them.  Then again they could indicate an issue in your app that is silently being ignored now but will appear later.
  
  Good luck,
  Michael Taylor - 11/20/05
  
  

• Jcwf

  That answer was very helpful for me too; thanks for the pointer to the Exceptions menu. But it raises another question for me; the error (in my app it was passing a single number to a DateTime.Parse method that expected a month/day/year string) was in a DataGridView CellFormatting event procedure, inside a Try...Catch block. I'm surprised the exception was not caught by the Try; is there a way to trap it outside of VB's debugging tools
  

• John Douglas

  Menue Debug -> Exception -> Common Runtime Exceptions -> System -> Argument Exception

  little_Attila

  
  
• How do you find a "First Chance Exception" recorded in Debug Output