На выходных заходил я к своему другу new_s в гости и он показал мне интересную вещь. Ему по работе нужно было анализировать дамп памяти .net приложения, где он искал утечки памяти и другое аномальное поведение и показал мне, что при старте любого .net приложения окружение резервирует память для трех исключений:

• ExecutionEngineException
• StackOverflowException
• OutOfMemoryException

И это нормальное поведение. Почему?

Хабраюзер burdakovd задал в Q&A задачку про C++, vector и запись в чужую память. Задачка, кроме всего прочего, хороша тем, что на ней можно удобно продемонстрировать, как пользоваться инструментом Application Verifier и находить, кто же портит память.

Application Verifier — очень мощный инструмент, кроме диагностики работы с хипом он умеет уйму всего другого, например определять неправильную работу с хендлами, ошибки реализации многопоточности, эмулировать нехватку ресурсов, чтобы проверить корректную работу программы в таких условиях, но об этом как-нибудь в другой раз.

В процессе поиска своих утечек памяти в приложении написанном на Silverlight (последняя запись в моём личном блоге) обнаружил в классе ChildWindow ошибку, приводящюю к утечке памяти.

Писал сложную форму на Silverlight и когда дописал, с ужасом обнаружил, что у меня где-то происходит утечка памяти. Волноваться я не стал, а снял несколько дампов на 3,5 гигабайта и хотел было в WinDbg выяснить в чём собственно дело, но SOS упорно посылал меня на любую из команд.

Дело в том, что Silverlight это x86, поэтому, как только мы загрузим дамп в WinDbg x86, то надо явно сказать, что работать мы будем 32х битном режиме.

Волшебное слово:
!wow64exts.sw

Пример:
.loadby sos coreclr
.chain
!wow64exts.sw

Дальше работаем как обычно.

Have fun

Копая залежи документов на своем рабочем компе обнаружил инструкцию по развертыванию сервера отладочной информации, которую писал два-три года назад. Попробую представить её хабросообществу. Данная инструкция будет полезна C++ разработчикам под Windows, которые хотят использовать отладку релизных версий своего продукта (удаленно и напрямую, на своих компах и компах тестировщиков), а также делать разбор крашдампов (postmortem debugging).

Хочу начать серию статей, посвящённых отладке ваших .NET приложений на стороне заказчика, а также оптимизации вашего кода. В связи с этим понадобиться немного подготовить вашу систему. В этой статье мы ознакомимся с различными инструментами для отладки приложений, немного углубимся в описание CLR, где это будет необходимо.