tag:blogger.com,1999:blog-7754674872362895099.post2163091900603431881..comments2023-05-03T16:18:51.793+03:00Comments on Очень серьезный блог: Post mortemAnonymoushttp://www.blogger.com/profile/10666299351005530153noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7754674872362895099.post-24292926281443689112011-04-19T13:26:16.605+04:002011-04-19T13:26:16.605+04:00Интересный блог, буду почитывать :-)Статейка стара...Интересный блог, буду почитывать :-)<br><br>Статейка старая, но захотелось оставить комментарий. <br><br>Подкладывание pdb файлов в каталог с дампом очень неудобное решение. Версий может быть много и придется вручную подбирать pdb файлы... гораздо проще сделать это автоматизировав выкладывание pdb файлов для каждой сборки в единое хранилище. Можно это сделать с помощью symstore (входит в пакет Debugging Tools for Windows), но у меня это выполняется своей утилитой, которая выкладывает файлы на ftp. А для программ, использующих pdb файлы, сделать переменную окружения <b>_NT_SYMBOL_PATH</b> со значением вроде такого: <b>srv*d:\symstore*http://main/pdb/store;SRV*d:\symstore*http://msdl.microsoft.com/download/symbols</b><br><br>В этом случае отладчик сам найдет pdb файлы для нужного релиза. Только некоторые нехорошие программы, будут делать запросы за pdb файлами не смотря на их наличие в каталоге кеша, поэтому адрес сервера можно убрать. Предварительно натравив на файл дампа symchk.exe (входит в пакет Debugging Tools for Windows), указав ключем /s путь к серверу, получим в кеш pdb файлов все, что нужно.<br><br>Ну а для анализа дампа я бы советовал использовать не Visual Studio, а WinDbg (входит в пакет Debugging Tools for Windows). Он работает гораздо быстрее, не требует наличия исходников и бинарников. Ну а встроенные команды вроде !analyze -v или !locks, частенько помогают выяснить причину падения за несколько секунд.<br><br>Прям какая-то реклама Debugging Tools for Windows получилась... :-)Alex Nekipelovhttp://www.blogger.com/profile/11644484550750096086noreply@blogger.comtag:blogger.com,1999:blog-7754674872362895099.post-68491685968827194482009-03-26T05:17:00.000+03:002009-03-26T05:17:00.000+03:00Интересный блог, буду почитывать :-)Статейка стара...Интересный блог, буду почитывать :-)<BR/><BR/>Статейка старая, но захотелось оставить комментарий. <BR/><BR/>Подкладывание pdb файлов в каталог с дампом очень неудобное решение. Версий может быть много и придется вручную подбирать pdb файлы... гораздо проще сделать это автоматизировав выкладывание pdb файлов для каждой сборки в единое хранилище. Можно это сделать с помощью symstore (входит в пакет Debugging Tools for Windows), но у меня это выполняется своей утилитой, которая выкладывает файлы на ftp. А для программ, использующих pdb файлы, сделать переменную окружения <B>_NT_SYMBOL_PATH</B> со значением вроде такого: <B>srv*d:\symstore*http://main/pdb/store;SRV*d:\symstore*http://msdl.microsoft.com/download/symbols</B><BR/><BR/>В этом случае отладчик сам найдет pdb файлы для нужного релиза. Только некоторые нехорошие программы, будут делать запросы за pdb файлами не смотря на их наличие в каталоге кеша, поэтому адрес сервера можно убрать. Предварительно натравив на файл дампа symchk.exe (входит в пакет Debugging Tools for Windows), указав ключем /s путь к серверу, получим в кеш pdb файлов все, что нужно.<BR/><BR/>Ну а для анализа дампа я бы советовал использовать не Visual Studio, а WinDbg (входит в пакет Debugging Tools for Windows). Он работает гораздо быстрее, не требует наличия исходников и бинарников. Ну а встроенные команды вроде !analyze -v или !locks, частенько помогают выяснить причину падения за несколько секунд.<BR/><BR/>Прям какая-то реклама Debugging Tools for Windows получилась... :-)Alex Nekipelovhttps://www.blogger.com/profile/11644484550750096086noreply@blogger.com