Устранение неполадок перезагрузки веб-приложений

Наш процесс веб-приложений перезапускается регулярно, и мы не можем определить причину.

При изучении событий приложений (используя "Диагностика и решение проблем" на Azure Portal) существует куча следующих Info журналов "IIS AspNetCore Module",

Идентификатор события 1005:

Failed to gracefully shutdown process '14040'.

Идентификатор события 1001:

Application 'MACHINE/WEBROOT/APPHOST/myapplication__xxxx' started process '31628' successfully and is listening on port '17663'.

Нет ничего подозрительного в использовании общего ресурса и ничего в журналах приложений.

Каков наилучший способ устранения неполадок, связанных с этими перезапусками?

ИЗМЕНИТЬ 1:

После возиться с ведением журналов в журналах диагностики веб-приложений, теперь я получаю сообщение об ошибке из W3SVC-WP после каждого перезапуска, но сообщение абсурдно:

1<br/>5<br/>50000780

Application Events

EDIT 2:

Идентификатор события 2284 относится к этому:

Модуль FailedRequestTracing не смог записать буферизованные события в файл журнала для запроса, который соответствовал определению отказа. Никакие журналы не будут созданы до тех пор, пока это условие не будет исправлено. Проблема произошла как минимум% 1 раз за последние% 2 минут. Данные являются ошибкой.

Я не уверен, может ли это быть связано с нашей конфигурацией диагностических журналов, но кажется маловероятным.

ИЗМЕНИТЬ 3:

Согласно предложению Брандо Чжана, я использовал расширение "Диагностика ошибок при сбое веб-приложений" и попытался контролировать 2-х случайные необработанные исключения как на моем процессе приложения, так и на w3wp, но ничего не сбрасывается.

Из того, как я это понимаю, исключения 1-го шага не разрушат процесс, поэтому нет необходимости контролировать их.

Ответ 1

Очень вероятно, что приложение сбой из-за фатального исключения и вызывает перезагрузки.

На платформе Azure App Service. Вы можете использовать диагностику как услугу (DaaS) для устранения этой проблемы

Он также может сделать анализ и рассказать вам основную причину большую часть времени. Более подробная информация об этом может быть найдена в этом блоге msdn. Также обратитесь к советам по использованию диагностического прибора

Memory Dumps