Здравствуйте, sergma, Вы писали:

S>Подскажите в чем может быть проблема?
в том что не используете WinDbg

После нажатия ctrl+D в VMWare окно SoftIce не появляется.

.wmx файл я редактировал, 2 опции добавил.
vmmouse.present="FALSE"
svga.maxFullscreenRefreshTick="2"

Подскажите в чем может быть проблема?
Заранее спасибо.

Здравствуйте, sergma, Вы писали:

S>После нажатия ctrl+D в VMWare окно SoftIce не появляется.

Система при этом "замерзает", или продолжает работать? Если покинуть окно VM, утащить его за пределы экрана и вернуть обратно — на экране что-нибудь появляется?

S>vmmouse.present="FALSE"

Для VMware 5 можно не ставить.

S>svga.maxFullscreenRefreshTick="2"

Вместо этого лучше ставить svga.forceTraces = TRUE

S>Подскажите в чем может быть проблема?

Какие версии VMware, системы под VM, SoftICE, каково происхождение установочного набора SoftICE?

Здравствуйте, Valery A. Boronin, Вы писали:

S>>Подскажите в чем может быть проблема?

VAB>в том что не используете WinDbg

Я вот тоже предпочитаю использовать SoftICE, несмотря на его глюки Во-первых — одна и та же версия SoftICE имеется и для 9x/ME, и для 2k/XP/2k3, а отлаживать 98 с помощью WinDbg без бубна не получится Во-вторых, трассировка в VM/SoftICE выполняется в разы быстрее, чем в VM/WinDbg.

Здравствуйте, emusic, Вы писали:

E>Здравствуйте, sergma, Вы писали:

S>>После нажатия ctrl+D в VMWare окно SoftIce не появляется.

E>Система при этом "замерзает", или продолжает работать? Если покинуть окно VM, утащить его за пределы экрана и вернуть обратно — на экране что-нибудь появляется?

S>>vmmouse.present="FALSE"

E>Для VMware 5 можно не ставить.

Большое спасибо, заработало.
Я просто посчитал что нет нужды ставить host components на VM, оказалось без этого не работает.

S>>svga.maxFullscreenRefreshTick="2"

E>Вместо этого лучше ставить svga.forceTraces = TRUE

S>>Подскажите в чем может быть проблема?

E>Какие версии VMware, системы под VM, SoftICE, каково происхождение установочного набора SoftICE?

Здравствуйте, sergma, Вы писали:

S>Я просто посчитал что нет нужды ставить host components на VM

Кто такие "host components"? Host — это система, в которой работает VMware, а в VM ставятся VMware Tools.

S>оказалось без этого не работает.

Без этого работает, но только в режиме VGA, разумеется.

Здравствуйте, emusic, Вы писали:

S>>>Подскажите в чем может быть проблема?
VAB>>в том что не используете WinDbg

E>Я вот тоже предпочитаю использовать SoftICE, несмотря на его глюки Во-первых — одна и та же версия SoftICE имеется и для 9x/ME, и для 2k/XP/2k3, а отлаживать 98 с помощью WinDbg без бубна не получится Во-вторых, трассировка в VM/SoftICE выполняется в разы быстрее, чем в VM/WinDbg.
ни в коем случае не пытаюсь переманить всех soft-ice фанатов в наш лагерь. Как говорится, дело хозяйское. Насчет 98 уже (для меня) не аргумент, да и МС уже не поддерживает свое детище, как известно. Я понимаю что заказчики и проекты разные и поддерживать чтото приходится, но надо двигаться вперед, оставляя 98 с так ей понравившимся SI позади, ИМХО! В свое время SI действительно обошел всех в т.ч. и саму MC. Но это из серии про старого и молодого бычка. Сейчас старый бычок уже спустился с гор )

насчет трассировки — всегда можно снизить уровень отладочного спама или нагрузить только отлаживаемый участок — короче у себя я особых проблем не ошушаю даже с медленным соединением по zmodem кабелю или при большом объеме логов из VMWare. Тоже недостаточно чтобы покупать SI и его осваивать ради этого.

Поймите, раньше ядро и инструменты разработки у МС было as is, потом стали немного инфраструктуру тут подтягивать, надавили на Visual Studio — и где тот Borland OWL нынче? Даже не самая блестящая либа классов MFC оказалась получше.

Последние же годы МС осознало что надо приложить усилий именно в области поддержки ядерных разработчиков (ибо кач-во всей ОС страдает и т.п.) — здесь а не где то еще — и сначала подтянули документацию, потом взялись за инструменты разные помогающие улучшить кач-во кода — driver/application verifier, prefast, HCT, WHQL и конечно же главное WinDbg наконец уделили самое серьезное внимание, сервер символов подняли для всех и плагинная система поволяющая писать свои расширения для WinDbg (не в курсе SI поддерживает чтото подобное?)

короче МС по своей отработанной схеме завоевания новых рынков проделала (специально пишу это в прошедшем времени) прекрасную работу и по совокупности просто не вижу смысла упираться против локомотива и не переходить на WinDbg.

Жизнь все равно заставит перейти — все же CompuWare это не Microsoft и соотв просто в силу этой причины всегда будет отставать с поддержкой новых Microsoft инициатив и новых продуктов вроде следующих ОС, Windows Driver Framework и т.п.

PS конечно всегда есть некий процент пользователей сидящих и сейчас на Win95 даже не OSR2

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Жизнь все равно заставит перейти — все же CompuWare это не Microsoft и соотв просто в силу этой причины всегда будет отставать с поддержкой новых Microsoft инициатив и новых продуктов вроде следующих ОС, Windows Driver Framework и т.п.

Жизнь заставит — перейдем А пока SI 4.2.7 даже в 2k3 делает все, что нужно. Хотя и имеет свои баги

Здравствуйте, emusic, Вы писали:

E>Жизнь заставит — перейдем А пока SI 4.2.7 даже в 2k3 делает все, что нужно. Хотя и имеет свои баги

кстати да, WinDbg is for free! понимаю что не аргумент на постсоветском пространстве, но все же стоит отметить

Здравствуйте, Valery A. Boronin,

VAB>короче МС по своей отработанной схеме завоевания новых рынков проделала (специально пишу это в прошедшем времени) прекрасную работу и по совокупности просто не вижу смысла упираться против локомотива и не переходить на WinDbg.

VAB>Жизнь все равно заставит перейти — все же CompuWare это не Microsoft и соотв просто в силу этой причины всегда будет отставать с поддержкой новых Microsoft инициатив и новых продуктов вроде следующих ОС, Windows Driver Framework и т.п.
--
Стоит заметить, наверное, что вместе с отладчиком SoftIce поставляется еще вполне приличная библиотека классов C++ для проектирования драйверов.

C уважением,
Геннадий Майко.

Здравствуйте, emusic, Вы писали:

E>Здравствуйте, Valery A. Boronin, Вы писали:

VAB>>Жизнь все равно заставит перейти — все же CompuWare это не Microsoft и соотв просто в силу этой причины всегда будет отставать с поддержкой новых Microsoft инициатив и новых продуктов вроде следующих ОС, Windows Driver Framework и т.п.

E>Жизнь заставит — перейдем А пока SI 4.2.7 даже в 2k3 делает все, что нужно. Хотя и имеет свои баги

Ok. Тогда такой вопрос к Вам — как в SI получить корректный анализ креша или хотя бы контекст где этот креш произощел из креш-дампа? Вчера получил по почте обновление ДрайверСтудио до 3.2 с новым Visual SoftIce. ДрайверСтудио не используем — так, нагрузка от Компуваре с комплектом других их продуктов. Решил вчера попробовать открыть креш в VSI... и очень удивился, увидев следующее сообщение:

BUGCHECK: 100000d1  [Unknown 0x100000D1]
Undecoded bug code parameters. Additional data may be available in the DDK help files.

Parameter 1 : 0x000000000000056c 
Parameter 2 : 0x0000000000000002 
Parameter 3 : 0x0000000000000000 
Parameter 4 : 0x000000000000056c

Неужели SI не знает кодов или не умеет их анализировать?

Так что хоть и было у меня желание возможно перейти на SI, но после же первых 5 минут было
решено — остаюсь с WinDbg, который справляется с этой задачей на мой взгяд получше.

M_M>Так что хоть и было у меня желание возможно перейти на SI, но после же первых 5 минут было
M_M>решено — остаюсь с WinDbg, который справляется с этой задачей на мой взгяд получше.

Возможно, но вот вам живой пример из практики.
На двух процесорной машине искал баг. Вылет в драйвере.
Пробовал и SI и WinDbg и что в итоге. При возникновении BugCheck WinDbg
всегда останавливался в одной и тойже точке кода (в своей точке входа в отладку), а не там где реально возникал сбой.
Раскрутка по стеку не давало ничего интересного кроме как путь по которому прошла система до вызова отладчика.
А вот SI остановится в большинстве случаев там где возник сбой, да и о соостоянии стека даст больше информации.
Да и потом отладка по COM порту или через пайп не оставляет никаких хороших впечатлений. Так что SI получше будет.

Здравствуйте, Mike_MS, Вы писали:

M_M>как в SI получить корректный анализ креша

Не знаю, никогда не пробовал даже. Я SI использую исключительно для живой отладки, в этом он мне удобнее. Анализ дампов, когда нужно, делаю в WinDbg, но нужно бывает крайне редко, ибо каждый проект под завязку напичкан Assert'ами, и непонятные глюки у заказчиков, влекущие сваливание системы, происходят от силы пару раз в год.

Здравствуйте, emusic, Вы писали:

E>Здравствуйте, Mike_MS, Вы писали:

M_M>>как в SI получить корректный анализ креша

E>Не знаю, никогда не пробовал даже. Я SI использую исключительно для живой отладки, в этом он мне удобнее. Анализ дампов, когда нужно, делаю в WinDbg, но нужно бывает крайне редко, ибо каждый проект под завязку напичкан Assert'ами, и непонятные глюки у заказчиков, влекущие сваливание системы, происходят от силы пару раз в год.

Все зависит от ситуации. У меня хоть и проверки идут разные, и эвристика для предупреждения разных аварийный ситуаций — все равно из 10-ти миллионов пользователей мы имеем немного меньше тысячи крешей в день. И не всегда это связано с моим драйвером.

Здравствуйте, Аноним, Вы писали:

M_M>>Так что хоть и было у меня желание возможно перейти на SI, но после же первых 5 минут было
M_M>>решено — остаюсь с WinDbg, который справляется с этой задачей на мой взгяд получше.

А>Возможно, но вот вам живой пример из практики.
А>На двух процесорной машине искал баг. Вылет в драйвере.
А>Пробовал и SI и WinDbg и что в итоге. При возникновении BugCheck WinDbg
А>всегда останавливался в одной и тойже точке кода (в своей точке входа в отладку), а не там где реально возникал сбой.
А>Раскрутка по стеку не давало ничего интересного кроме как путь по которому прошла система до вызова отладчика.
А>А вот SI остановится в большинстве случаев там где возник сбой, да и о соостоянии стека даст больше информации.
А>Да и потом отладка по COM порту или через пайп не оставляет никаких хороших впечатлений. Так что SI получше будет.

Зависит для чего. WinDbg c анализом лучще справляется. На счет отладки по СОМ-порту — WinDbg намного быстрее. Сам давно использую IEEE1394, что работает быстрее в WinDbg чем сеть в SI (только что специально проверил).

Здравствуйте, <Аноним>, Вы писали:

А>При возникновении BugCheck WinDbg всегда останавливался в одной и тойже точке кода (в своей точке входа в отладку), а не там где реально возникал сбой. Раскрутка по стеку не давало ничего интересного кроме как путь по которому прошла система до вызова отладчика. А вот SI остановится в большинстве случаев там где возник сбой, да и о соостоянии стека даст больше информации.

Это зависит. Я до сих пор пользуюсь SI 4.2.7 (ставится быстро и просто, 3.x замучишься ставить на несколько VM подряд), так он в ряде случаев (PF in nonpaged area, division by zero) не ловит само исключение, а лишь вход в KeBugCheckEx. Соответственно — ни параметров верных, ни стека Плюс под XP конфликтует с тамошними средствами ловли исключений и создания отчетов (такое впечатление, что система у него забирает точки входа, а он их не восстанавливает). Но достоинства перевешивают

M_M>Зависит для чего. WinDbg c анализом лучще справляется. На счет отладки по СОМ-порту — WinDbg намного быстрее. Сам давно использую IEEE1394, что работает быстрее в WinDbg чем сеть в SI (только что специально проверил).

Если учесть что SI на локальной работает а WinDbd только удаленно, то спрашивается кто из них шустрее?
Да и остановка в месте сбоя даст больше информации чем анализ крешдампа.
Скажим так за свою практику анализ срешей полученый в Visual SI давал мне намного больше информации
и помогал быстрее найти сбои чем WinDbg. не исключено что в MS им пользуются для отладки так как
WinDbg явно тут храмает, особено по СОМ порту.