Решил провести кое-какой рефакторинг на сайтах, обновить версии .NET Framework, перевести методы на асинхронные где еще не было сделано до этого.

В результате потом три дня разбирался с исключениями и периодическими падениями IIS. Зато разобрался как определять причину падения w3wp.exe.

Если коротко, то нужно снять дамп во время падения и проанализировать его.

Для снятия дампа нужно:
1. установить на сервер Debug Diagnostic Tool от Microsoft.
2. запустить DebugDiag Connection и настроить к какому процессу сайту цеплять отладчик и какой дамп снимать. Я выбрал полный. Все это занимает буквально несколько кликов.
3. Ждать падения, в окне будет увеличиваться счетчик ошибок.

Для анализа:
1. Запустить DebugDiag Analysis
2. Загрузить дампы, которые насобирал DebugDiag
3. Выбрать нужный отчет, в моем случае Default (Crash report) и нажать Анализ
4. В отчете ищем текст исключения и трассировку.

В общем в падениях была виновата одна библиотека, которая использовалась при синхронизации сайта с ВКонтакте. Для нее после обновления .NET почему-то в конфиге сайте не прописался нужный binding. В тестовой среде все работало, а вот на продакшене уже нет.

Ошибку исправил, а заодно еще исправил несколько проблемных мест. Сейчас бы это все заняло, конечно, гораздо меньше времени.

Но опыт получен 😉