System.Threading.ThreadAbortException: Thread was being aborted.
at System.Globalization.CompareInfo.InternalFindNLSStringEx(IntPtr handle, String localeName, Int32 flags, String source, Int32 sourceCount, Int32 startIndex, String target, Int32 targetCount)
at System.Globalization.CompareInfo.IndexOf(String source, String value, Int32 startIndex, Int32 count, CompareOptions options)
at System.String.IndexOf(String value, Int32 startIndex, Int32 count, StringComparison comparisonType)
at System.String.IndexOf(String value, StringComparison comparisonType)
at <our .NET 2.0 library>
at <our .NET 4 web-site>
We've only noticed this when the code is running on Azure (and we've used the library code in many other web-sites (not running on Azure) for several years without problems).
The scriptData variable is a local string that is populated from a BLOb and is being reassigned several times throughout the method call.
This exception seems to happen in the first 2 hours after a publish, and where before it had only happened very rarely or not at all after a publish, it recently happened several times in rapid succession bringing down all running instances of our
web-site (I'm guessing that's because ThreadAbortExceptions are automatically rethrown unless a Thread.ResetAbort is called).
Some other things:
I've also once seen this exception happen in a scriptData.SubString() call near the same code that normally crashes.
The method where it crashes has many calls to .IndexOf, but only the one that's in the while-condition seems to raise the exception (and there's nothing statistically significant about it over any of the IndexOfs that are called inside the loop on the same
variable, except maybe, that it has a slightly higher chance of being called straight after scriptData is reassigned).
Other than adding a Thread.ResetAbort() around this code, I've no idea how to continue.
Hi, usually ThreadAbortedException can be ignored. They're thrown when Thread.Abort is invoked. This can happen explicitly (you call Thread.Abort) or implicitly (for example, Response.Redirect will call Thread.Abort). They usually do not cause any problems.
So if your application is working fine, just ignore it.
As you already know, ThreadAbortedException will automatically be rethrown. And the above call stack looks like a call stack in the rethrown, because it's missing Thread.Abort. So the call stack doesn't help to identify the problem. To find the original
cause, you may have to debug the application, and configure Visual Studio to break whenever an exception is thrown, even if it is already handled. It may take a lot of time to install Visual Studio on a cloud machine, but you can use WinDbg, and configure
it to break on first chance CLR exceptions. You can refer to
http://blogs.msdn.com/b/johan/archive/2008/01/31/using-windbg-hunting-exceptions.aspx for more information.