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

    Question

  • I am getting the following line "A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll" in my debug output

    I do not know what is causing it (break points on every try/catch I could think of didn't provide any hints). The program runs and performs as expected

    How do you go about finding out what is causing these? There is a rather lot of them occuring, and I'd rather not have them if possible
    Monday, November 21, 2005 12:18 AM

Answers

  • 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
    Monday, November 21, 2005 3:25 AM
    Moderator

All replies

  • 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
    Monday, November 21, 2005 3:25 AM
    Moderator
  • 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)
    Monday, November 21, 2005 5:00 AM
  • 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?
    Sunday, May 07, 2006 4:18 PM
  • 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.
    Sunday, May 07, 2006 6:58 PM
  • Menue Debug -> Exception -> Common Runtime Exceptions -> System -> Argument Exception

     

    little_Attila

    Thursday, August 09, 2007 11:37 AM
  • Hi,
    I want to know how to catch the first chance exception in code if I know that one is happening. Like if the memory access violation exception or something is happening like
     
    "First-chance exception at 0x0041236f in Coexistense.exe: 0xC0000005: Access violation reading location 0x00000020."

    I don't want debugger to handle it but I should handle this on my own.

    Thanks,
    Thursday, November 13, 2008 5:17 PM
  • Wow, thanks!  I was able to finally track down my first chance exception by turning on all CLR exceptions in the Debug menu.  I've never had a need to open that menu before today!  If only I had found this post three hours ago...

    Thanks!

    Wednesday, February 25, 2009 7:39 PM
  •  Michael, that was a great suggestion.

    And I always knew about that menu,too. It's just for some reason I already thought everything was checked, but it was actually only user-unhandled exceptions. This allowed me to track all such bugs and others. Thanks.

    Wednesday, July 07, 2010 7:30 PM
  • Wow, really thanks for such a valuable post. I have been unaware of the Exceptions menu item. You save me hours of research.

     

    Thanks

    Monday, December 06, 2010 4:11 PM
  • Really Thanks for this post.
    Thursday, April 21, 2011 3:08 PM
  • Great thanks!

    Managed to track a System.ArgumentException using the output window and Exceptions menu. The expcetion was thrown somewhere but only caused a non responsive AutoCompleteTextbox. In my case a method in an ASP.NET was called asynchroneously by Ajax toolkit, leading to the exception evidently not bubbling up to cause a stacktrace screen like I'm used to with standard synchroneous calls.

    Thursday, December 08, 2011 10:31 AM
  • Thank you for that explanation! I really should handle my catch blocks rather than just ignore them D:
    Wednesday, November 07, 2012 7:27 PM