3

I'm working on a asp.net web application with Visual Studio 2010. There are a bunch of output window messages during debugging regarding:

A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll

and

An exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll but was not handled in user code

I've read some great Q&A on the topic of how and why these might be raised and how to handle them (or not handle them). My first guess is that it is related to Response.Redirect()s that are in the code. However, I see them in the output and I'm not sure of the source of those output messages.

Question: how do I determine where the first chance exception came from in Visual Studio 2010?

Once I determine the source, I can investigate, solve or simply ignore per the Q&A linked to this question. Thanks in advance!

Community
  • 1
  • 1
Mark A
  • 5,881
  • 5
  • 26
  • 34

1 Answers1

1

From personal experience, unless there is specifically an error occurring as a result of these, these messages can generally be ignored.

I have read in the past that this can be solved by adding false to the second parameter of Response.Redirect to stop processing occurring after redirect.

E.g. Response.Redirect("path/to/page.aspx", false);

Response.Redirect on MSDN

When you use this method in a page handler to terminate a request for one page and start a new request for another page, set endResponse to false and then call the CompleteRequest() method. If you specify true for the endResponse parameter, this method calls the End method for the original request, which throws a ThreadAbortException exception when it completes. This exception has a detrimental effect on Web application performance, which is why passing false for the endResponse parameter is recommended. For more information, see the End method.

Ash Clarke
  • 4,807
  • 1
  • 37
  • 48
  • The linked questions show all of the ways of resolving, ignoring or otherwise dealing with these -- I am trying to determine "the where" they are coming from. – Mark A Jun 30 '11 at 00:26
  • You can try pressing ```CTRL+ALT+E``` or ```CTRL D, E``` (can't remember which shortcut) or going to ```Debug > Exceptions``` and checking Thrown on all unchecked checkboxes. That might reveal what is the source of the exception. – Ash Clarke Jun 30 '11 at 00:32
  • I had a lot of hope for that idea, but despite checking all unchecked checkboxes for C++, CLR Exceptions, Win32, Managed Debugging Assistants, Native Run-Time Checks etc. -- no change in behavior. – Mark A Jun 30 '11 at 00:40
  • Perhaps the message we see in the output window is the exception handling for the thread ending. I admit, when I first saw that, starting my new job, it frustrated me too that the supposed reason for it was "It just happens"! – Ash Clarke Jun 30 '11 at 00:44
  • 1
    To me it doesn't seem reasonable for asp.Net to let a thread exit in that way. It should end normally and return into the pool ready to pick up a new request. – Louis Somers Apr 22 '13 at 13:09
  • I re-read my quoted text in my answer. The answer to _where_ this is coming from is the `End` method for the original request", so I assume `Response.End` - "... calls the End method for the original request, which throws a ThreadAbortException exception when it completes" – Ash Clarke Jul 18 '14 at 09:13
  • To avoid this exception, you could potentially catch the `ThreadAbortException` in the method you are calling the `Response.Redirect`, or the recommended way is to set the second parameter value to `false`. Then exit/return the function to prevent any code after the redirect from being evaluated. – Ash Clarke Jul 18 '14 at 09:17