Выкатили свежее веб приложение, которое себя отлично вело на предпродакшн серверах, а оно начало «крашить» w3wp.exe. Пытались «оддебажить» Debug Diagnostic Tool v2.0, но никаких результатов вменяемых мы не получили. И вот в один прекрасный день я наткнулся на замечательную статью и уже из нее узнал о существовании WinDbg. Дальнейший поиск вывел меня на еще одну статью.
IIS складывает дампы в папку c:\ProgramData\Microsoft\Windows\WER\ReportQueue\ и там уже AppCrash_w3wp.exe_<некий хеш> в которой находятся файлы, например:

WER87FF.tmp.dmp
WER4CC3.tmp.hdmp
WER4C63.tmp.appcompat.txt
Report.wer
WER4CB2.tmp.WERInternalMetadata.xml

Для отладки запускаем установленную WinDbg и дальше Ctrl+D (File — Open crash Dump...) и указываем файл с расширением .hdmp.
Открывшийся дамп предстает перед нами в таком виде:

Подгружаем SOS модули для .NET
Для .NET 2.0 | 3.0 | 3.5

.loadby sos mscorwks

Для .NET 4.0

.loadby sos clr

Для вывода Stack Trace вводим команду:

!clrstack

и получаем вывод типа:

Для вывода потоков вводим команду:

!threads

и получаем список потоков:

В этом списке потоков я обнаружил строку:

129    9  e08 000000554889dba0  1029220 Preemptive  000000507063E940:0000005070640758 00000055488f41c0 1     MTA (Threadpool Worker) System.StackOverflowException 0000004cb0501188 (nested exceptions)

Вот он тот самый «эксепшн» StackOverflow который мы и искали.
«Открываем» нужный нам поток командой:

~129s

А теперь смотрим что у него внутри:

!clrstack

и начинаем анализировать вывод:

Скачать WinDbg

WinDbg 6.12.0002.633 (x64)
WinDbg 6.12.0002.633 (x86)