Why does a worker thread my ASP.NET spawn experience a ThreadAbortException during a Sleep?

Question

I spawn a worker thread in an ASP.NET application running on Windows Server 2008, IIS 7.5 The first thing this worker thread does is sleep for N seconds, and then it does its real work. During the sleep, a catch a ThreadAbortException.

Can you explain this behavior, and bonus points of you point me to any IIS/ASP.NET settings that can be used to adjust the behavior.

EDIT: More info. The suggestion to catch the ThreadAbortException helped me work around the problem, so thanks. I totally rewrote the wording of this question based on what I learned, but still, the same question, WHY is this worker thread getting aborted during a sleep?

Uniat

What happens if you sleep for two consecutive 17 second or less periods? – Corpuscle

why not try-catch around the whole thread handler and see what happens? Most likely you get ThreadAbortException which may have something useful in it. – Properly

@Robert - no problem @liho1eye - will do – Uniat

Answer 1

A ThreadAbortException happens on your worker thread because someone else called Thread.Abort on it, so it's probably nothing directly that your worker thread did, but rather some external cause. The first place you should check is your own code for any thread management or aborting that you might do. Otherwise, for IIS, this could be due to a worker process (w3wp.exe) or app pool, or AppDomain being recycled.

The recycling might be due to the idle timeout setting for the app pool, a regularly scheduled recycle, or a memory/CPU use trigger. These are configurable through the IIS Configuration Manager in the Server Explorer (on Win 2K8) or by just running inetmgr.exe. According to Tess' blog here, there are a number of other reasons for AppDomain recycling:

• Machine.Config, Web.Config or Global.asax are modified
• The bin directory or its contents is modified
• The number of re-compilations (aspx, ascx or asax) exceeds the limit specified by the setting in machine.config or web.config (by default this is set to

• The physical path of the virtual directory is modified
• The CAS policy is modified
• The web service is restarted
• (2.0 only) Application Sub-Directories are deleted

That blog post also has information on tracking down why a recycle happened. For starters, try looking in the Event Log (eventvwr.msc) to see if there's any detailed info.

You could also try debugging the worker process directly. Attach the VS debugger to the w3wp.exe instance where your code runs, add a breakpoint on Thread.Abort (you might need to enable ".NET Framework source stepping" in the debugger options), and see where the Abort is originating from by using the call stack window. This won't tell you why it's happening, but at least you'll know who's doing it.

Yearlong

I can't debug the thread directly because the problem is happening on a hosting provider's machine, but not on machines that I control. My logic doesn't abort the thread. Default idle timeout is in minutes, whereas this problem is happening when my thread sleeps 20 or so seconds. None of the other reasons for recycling apply. No Response.Redirect nor Response.End is involved. So... still a mystery. – Uniat

Just solved my problem: my threads were aborted in the middle, and that happened because I was writing my logs into "bin" folder (which was causing to IIS reset)... – Dobb