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
15)
- 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.