A ThreadAbortException происходит в вашем рабочем потоке, потому что кто-то еще назвал Thread.Abort в нем, так что, вероятно, это не было ничего, что ваш рабочий поток сделал, а скорее какая-то внешняя причина. Первое, что вы должны проверить, это ваш собственный код для любого управления потоками или прерывания, которые вы можете сделать. В противном случае для IIS это может произойти из-за перезапуска рабочего процесса (w3wp.exe) или пула приложений или домена приложения.
Переработка может быть связана с установкой тайм-аута простоя для пула приложений, регулярной запланированной перезагрузкой или триггером использования памяти / ЦП. Их можно настроить с помощью диспетчера конфигурации IIS в обозревателе серверов (на Win 2K8) или просто запустив inetmgr.exe. Согласно блогу Тесс здесь , существует ряд других причин для повторного использования AppDomain:
- Machine.Config, Web.Config или Global.asax изменены
- Каталог bin или его содержимое изменены
- Количество перекомпиляций (aspx, ascx или asax) превышает ограничение
определяется
установка в machine.config или
web.config (по умолчанию это установлено на
15)
- Изменен физический путь к виртуальному каталогу
- Изменена политика CAS
- Веб-сервис перезапущен
- (только 2.0) Подкаталоги приложений удалены
В этом посте также есть информация о том, как произошла переработка. Для начала попробуйте заглянуть в журнал событий (eventvwr.msc), чтобы узнать, есть ли какая-либо подробная информация.
Вы также можете попробовать отладить рабочий процесс напрямую. Присоедините отладчик VS к экземпляру w3wp.exe, в котором выполняется ваш код, добавьте точку останова на Thread.Abort (вам может потребоваться включить «Исходный шаг .NET Framework» в параметрах отладчика) и посмотрите, откуда происходит Abort с помощью окна стека вызовов. Это не скажет вам, почему это происходит, но, по крайней мере, вы будете знать, кто это делает.