ThreadAbortException in String.IndexOf(string) in WebRole

Question

Hi,

  We have the following line of code in a library we wrote (.NET 2.0) referenced by our web-site (.NET 4) running on Azure:

while((indexBegin = scriptData.IndexOf("<!--?")) != -1) { .. }

  ..that [infrequently] causes the following crash:

  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 <snip>
   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.

Thank you for any help,
Kind regards,
Eliott.

Answer 1

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.

---

Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

Thank you very much Ming Xu; that sounds entirely reasonable.

I will give the WinDbg a twirl out of curiosity, but otherwise, this is no longer at issue with me.

Thank you again,
Kind regards,
Eliott