Здравствуйте.

Здесь кто-нибудь пользуется WinDbg? Скажите, пожалуйста, для каких задач Вы его применяете? Что предпочитаете в большинстве случаев для повседневной разработки -- встроенный в Visual Studio отладчик или WinDbg? В каких ситуациях Вам не хватает возможностей встроенного отладчика, и Вы прибегаете к использованию WinDbg? Что лично Вы видите в нём замечательного и плохого?

Интересуюсь с целью выяснить для себя, стоит ли заморачиваться с изучением данного инструмента.

Заранее благодарю.

1) дампы (особенно с нейтив приложений ) однозначно надо разбирать только в windbg. В студии для этого просто нет инструментов.
2) отладка ядра — это исключительно привилегия windbg ( в новых студиях есть нечто, которое вроде как должно быть отладчикоя ядра, но это аццкое убожество )
3) отладка на тестовых машинах — устнаовить туда windbg довольно просто и быстро + никаких проблем с лицензиями и.т.д.

Отладчик студии имеет для меня только два жирных плюса: интеграция с IDE ( написал, запустил, отладил, исправил и.т.д ) и более-менее неплохая работа с STL. Поэтому я обычно VS использую при написании нового кода ( я идиот и не могу писать сразу правильно и поэтому любой кусочек кода обязательно трассирую), тут VS очень удобна. А когда приходят проблемы из IRL ( дампы, непонятные баги и.т.д.) — тут только windbg. Возможно, у VS есть куча удобствий при отладке managed кода или связки managed-unmanaged — не знаю, никогда на .Net не писал.

Кстати, порекламирую свой прожект:
https://pykd.codeplex.com/ автоматизация windbg питоном

По поводу IRL -- Вы на тестовые машины и машины клиентов поставляете *.pdb-файлы или как? Собираете Release-версию с отладочной информацией? В общем, какой инфой для WinDbg достаточно располагать для того, чтобы комфортно решить какую-нибудь реальную проблему?

FH>По поводу IRL -- Вы на тестовые машины и машины клиентов поставляете *.pdb-файлы или как? Собираете Release-версию с отладочной информацией? В общем, какой инфой для WinDbg достаточно располагать для того, чтобы комфортно решить какую-нибудь реальную проблему?

примерно так:
1) сборочный конвейер при сборке а) выкладывает private pdb на Symbol Server б) пробивает в pdb нужную ревизию для интеграции с source control ( лично я более-менее удачно работал с perforce, TFS и svn ). В мире "закрытого" софта общепринятая практика приватные pdb не выкладывать в общий доступ.

2) когда к нам поступает дамп и мы его открываем в windbg ( в студии кстати тоже, это не привилегия windbg ) символы автоматически подтягиваются с symbol store, исходник — с source control а.

3) далее применяем всякую windbg магию.
Ну напрмер, магия 0 уровня: узнать состояние блока памяти в хипе: !heap -x address. Тут разговор обширный, материала полно в сети. Встречаются маги которые анализируя дампы реально творят чудеса ))).


откуда берутся дампы?
1)автоматический сбор минидампов — по ним можно иногда быстро найти проблему и всегда можно оценить масштабы бедствия. Кстати, MS своим партнерам дает досутп к собственной статистике ( те самые "отправить отчете в MS"), к минидампам, также можно запросить и полный дамп по проблеме. Если у вам сотни тысяч инсталляций — это актуально завести с MS подобные отношения. Никто естественно не мешает наладить собственный сбор дампов.

2) обращение пользователей в саппорт. тут им дают инструкции как собрать, куда прислать.

3) автоматические тесты, инженеры контроля качества и бета тестеры. тут в + к пункту 2 можно попросить всякие дополнтельные "плюшки" — включить application verifier, настроить сбор стеков и.т.д. Также тестер может поставить у себя на машине windbg и сделать его отладочным сервером.