O>>Когда вас забрасывают в поле дебажить ваш продукт, который работает, а точнее глючит, у кастомера на ноуте девочки-припевочки с 14" и каналом гпрс, то играет роль два фактора — чтобы дебагер можно было быстро скачать-поставить, и чтобы он позволял эффективно дебажить в таких условиях. При этом вариат скачать может и не работать, если ваш глючащий продукт — файрволл.
Ops>Какая-то надуманная ситуация. Ну найдешь ты баг, и что? На чем будешь исправленную версию собирать, и если это где-то в офисе, то еще раз с флешкой поедешь?
Ops>Мне в поле доводилось отлаживать и править софт, причем в жутких условиях, но комп со всей средой разработки у меня был.
Комп со средой конечно же есть. Но он со средой, а не багом. Дебаггер нужен не там где среда, а там где баг. Причем такие полевые баги как правило еще и крайне капризны в воспроизведении — ребут — и бага нет. А ты может именно заради него три часа летел. А баг воспроизводится примерно раз в день и только на машинах кастомера. Потому что только у них есть очень специфичный девайс, и активх в браузере для работы с оным при захоте на ихний корпоративный портал. А ваш продукт — файрволл, который изредка ломает етот активх. И на кону контракт на пару лямов баксов. И вот сидишь, в офисе дебажишь багу.
А если ко всему этому в добавок еще и windbg не захочет устанавливаться т.к. ИХНИЕ корпоративные политики не позволяют ставить прилаги с маркета, а после того как его таки вкорячишь — он не захочет влазить своим интерфейсом в монитор...

O>>Когда вас забрасывают в поле дебажить ваш продукт, который работает, а точнее глючит, у кастомера на ноуте девочки-припевочки с 14" и каналом гпрс, то играет роль два фактора — чтобы дебагер можно было быстро скачать-поставить, и чтобы он позволял эффективно дебажить в таких условиях. При этом вариат скачать может и не работать, если ваш глючащий продукт — файрволл.
Ops>Какая-то надуманная ситуация. Ну найдешь ты баг, и что? На чем будешь исправленную версию собирать, и если это где-то в офисе, то еще раз с флешкой поедешь?
Ops>Мне в поле доводилось отлаживать и править софт, причем в жутких условиях, но комп со всей средой разработки у меня был.
Комп со средой конечно же есть. Но он со средой, а не багом. Дебаггер нужен не там где среда, а там где баг. Причем такие полевые баги как правило еще и крайне капризны в воспроизведении — ребут — и бага нет. А ты может именно заради него три часа летел. А баг воспроизводится примерно раз в день и только на машинах кастомера. Потому что только у них есть очень специфичный девайс, и активх в браузере для работы с оным при захоте на ихний корпоративный портал. А ваш продукт — файрволл, который изредка ломает етот активх. И на кону контракт на пару лямов баксов. И вот сидишь, в офисе дебажишь багу.
А если ко всему этому в добавок еще и windbg не захочет устанавливаться т.к. ИХНИЕ корпоративные политики не позволяют ставить прилаги с маркета, а после того как его таки вкорячишь — он не захочет влазить своим интерфейсом в монитор...
Я к чем windbg хорош именно как минимально зависимый отладчик, который легко и быстро разворачивается на любой, мало-мальски дышащей системе. К примеру им можно дебажить если сетевой стек убит — главное символы по локальным путям чтобы были все. Им можно было дебажить если в системе разломана база sxs длл- потому что ему было нужен kernel32/advapi32/user32/dbgeng и все (опять же, если символы все локально доступны). Его можно было запустить и иметь функциональный гуй в окошке виртуальной машины ESX сервера с фиксированным разрешением 800х600.
Если windbg превратиться в студию, то он будет не нужен, т.к. уже есть студия и в ней уже есть дебаггер.