Веб-приложение стало использовать очень много памяти и зависать или ещё один пример использования расширения отладки SOS в приложении ASP.NET

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


В данной ситуации Visual Studio мало чем могла помочь. Анализ исполняемого кода в режиме отладки с точками останова результатов почти не дал, потому что всё отрабатывало нормально. А использовать SOS из студии невозможно, так как его можно загрузить только во время останова отладчика, а просидеть день перед монитором с запущенным отладчиком, дожидаясь нестандартного поведения приложения не охота. Естественно пришлось использовать отладчик Windows. Подключился я к процессу приложения с помощью WinDbg и загрузил расширение SOS (более подробно о том как использовать WinDbg с расширением отладчика SOS написано тут). Cделал дамп кучи, чтобы представить примерную картину использования памяти. Так как пямяти много было использовано, то и сам процесс получения сведений о типах занял некоторое время.
 

Как видно из снимка, количество объектов DataRow было подозрительно большим. Дальше не составило труда просмотреть стек вызовов и выявить вызов процедуры SQL Server, код которого был модифицирован очень хитро, но конечно не преднамереннно. А сервер БД у нас расположен на отдельной машине и естественно вся команда имеет к нему доступ (точнее к базе приложения). Оказалось, что в очень специфических ситуациях процедура зависала и возвращала огромное количество ненужных данных (правда чтобы это понять понадобилось приличное количество времени). Ещё один простой пример применения данных возможностей на практике.