This is a self-explanatory question:
Why does this thing bubble into my try catch's even when nothing is wrong?
Why is it showing up in my log, hundreds of times?
I know its a newb question, but if this site is gonna get search ranking and draw in newbs we have to ask them
This is probably coming from a Response.Redirect call. Check this link for an explanation:
http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx
(In most cases, calling Response.Redirect(url, false) fixes the problem)
The most common reason for a ThreadAbortException is calling Response.End, Response.Redirect, or Server.Transfer. Microsoft has published some suggested functions that should be used in stead of those functions.
As others have said, it occurs when you call Response.End() (which occurs when you call Response.Redirect without passing false as the second parameter). This is working as designed; typically, if you call Response.Redirect, you want the redirect to happen immediately. See this for more information:
Knowing that there are (at least) three APIs that internally use Thread.Abort, I'd like to answer in more practical terms, how to work out what to do about it.
For us, this error started being logged all-of-a-sudden. What changed? We fixed a bug in some database procedure that was dealing with sitemaps.
The log4net logs showed the X-Forwarded-For header (we're behind an NLB) was Googlebot's IP address, 66.249.78.x which bolstered my theory about the sitemap change leading to Google crawling our site more aggressively looking for images.
The first thing was to find out why only the Googlebot was able to cause this problem. No other client was triggering whatever code path uses Response.Redirect, or whatever.
So in the HttpApplication.Error handler, I added some code to log extra detailed output with all headers, and most data in the HttpResponse and HttpContext spewed to log.
This let me see that the problem was that Googlebot is using an iPhone user agent string and armed with that, I was able to search the codebase for "iPhone" and come up with:
private void CheckIPhoneAccess() { ... }
And that uses a Redirect.
What to do about it?
Well, for this aged codebase, it's not worth retro-patching all the Response.Redirect calls, so I'm going to lower the logging level for ThreadAbortException for the application.
I will change the behaviour for Googlebot's mobile crawler, that would not lead to 'lies' about what our site serves to mobiles since it only redirects on the first hit, subsequently it reads a cookie and shows the image. Googlebot does not seem to cache that cookie.
It's not perfect, but the site is due to be rebuilt. probably by another team using Scala or something, so in practical terms, I think this is a good choice. I'll add comments and may revisit the issue later, build a Response.SafeRedirect extension that encapsulates this advice:
Why Response.Redirect causes System.Threading.ThreadAbortException?
Luke
The reason of why Response.Redirect will give this exception is asp.net internally implement this API with Thread.Abort(). When this method is called, a special ThreadAbortException is thrown.This exception wont be swallowed by any catch block. It will be re thrown at the end of each catch block.
