Итак, народ. DS 3.0.1 final уже в пути, уже есть в сети. Только радости от этого... Мгм :(
Не исключено, конечно, что я при настройке что-то не учитываю... Но маловероятно, если честно. Т.к. 2.7 у меня работал как часики.

Проблема: bpm - работает, bpx - тоже работает,
а вот bpx MessageboxA, как это было встаринку по Ctrl+D и без напряга, сейчас что-то меня разлюбила... И не меня одного :(

NuMega уже говорила о такой проблеме
h**p://frontline.compuware.com/nashua/patches/ - некоторые решения.

Мой случай - Win2k sp4.
И bpm, и bpx - рабочие, но вот bpx ФункцияDLL - уже рыпаться не хочет, а точнее рыпается время от времени!

Возможно, проблема в osinfo.dat... Как никак важный файлик! Может еще в чем...
Кроме того, если честно, я теоретически не особо понимаю как БЫЛО поставить бряк на функцию dll во всех контекстах! Мы с Four-F уже об этом спорили (поиск по форуму), но понятнее мне не стало :((

Один паренек, вроде, нашел решение (и так достаточно очевидное), но хотелось бы услышать мнение спецов! Dr.Golova? Sten?
Sten, ты, помнится, говорил, что хочешь дождаться релиза? Вот он. И весьма загадочно работает. Время разбираться!

Да, вот слова паренька:

I have found the issue. To get this to work, you must create/enable the breakpoint while in the address context of the process who will actually call the function you want to break on.

You can see your current address context in the bottom-right of the SI window, I think it is always Idle when you Ctrl+D.

As an example, I wrote a quick Delphi app to test this (just a button on a form that calls MessageBoxA), it's called Project1. When I Ctrl+D, my address context is Idle. If I bpx MessageBoxA now, pressing the button on my form will show the messagebox without breaking. But, if I Ctrl+D, then do ADDR Project1 (or if I have more than one process running called Project1, I can do PROC, see the Process ID of the instance I want to break, and do ADDR <Process ID> ), then do bpx MessageBoxA, when I press the button on my form, it breaks correctly.

Also, if you already have a breakpoint, instead of clearing the breakpoint and recreating it in the right address context, you can just disable it then reenable it in the right address context (less typing! ).

As far as I know, you had to do this same thing to get breakpoints to work in SoftICE 2.7. At least I did. That's how I knew what the problem was, since I had to figure this out while using 2.7 .

One thing I discovered is, when you run an app through symbol loader, and SI breaks on entry point, even though SI says you're in the right address context, if the PROC command shows more than one process with the name of the process you're debugging, you still have to manually do ADDR <process id>. I found that while Delphi was open, PROC listed two or more Project1 processes, one being my real running process, and the others having a status of Deleting. When I loaded my app through SL and immediately did bpx MessageBoxA, it didn't break properly. But, if I loaded my app through SL, and did ADDR <my running process id>, it worked. Once I closed Delphi, and loaded my app, PROC only showed one instance of Project1 (the one with the status of Deleting was no longer there), and immediately setting my bpx without doing ADDR worked. So, the rule here is, if PROC shows more than one process with the name of the process you're debugging, you always have to type ADDR <process id> before setting any breakpoints, regardless of what SI says your current address context is!

Since every time you press Ctrl+D, your address context is Idle, I find it useful when debugging an app to write a quick macro (I call mine AC) that just does ADDR <name/id of process I'm debugging>. Then, every time I hit Ctrl+D, I just type AC to get in the right address context, then breakpoints etc work correctly.

Let me know if my explanation is too confusing, or if you find a better solution.

volodya

А перевести.. ;-)

Asterix

Сам. Со словариком :)

А не подскажете по какому пути пройти, что-бы встретить ентот 3.0.1? А то 3.0b2 каким то сыроватым кажется...

angelex

Не подскажем! Это не варезный форум!

Злой ты аднака :)
Но и на том спасиб. Сам уже у китайцев надыбал...
А проблема действительно решается при помощи ADDR...

[ angelex: А проблема действительно решается при помощи ADDR... ]

Только если процесс уже загружен, к сожалению. А как быть исследователям оси? Например, если нужно исследовать работу загрузчика - скажем нужен бряк на какую-нибудь ntdll!LdrLoadDll. Она вызывается в контексте создаваемого процесса, но как поставить бряк в этом самом контексте пока он еще не создан? В старом айсе работал такой простой трюк: запускаем процесс, ставим бряк, убиваем процесс, запускаем опять - трапаемся. Почему это работало я точно не знаю - только догадываюсь, а времени копаться в айсе пока нет, хотя и жутко интересно. Возможно это работа с кешем или прямо с физической памятью... В общем, в старом айсе у меня это работало как часы, в новом только иногда. Причем айс иногда путает контексты и бряк начинает срабатывать в другом процессе ;-)

В общем, если кому до зарезу понадобится бряк на все контексты сразу или еще до создания процесса, могу предложить такой ОЧЕНЬ геморройный способ, но зато работать это будет железно - прописать CCh прямо в физическую память.

Пример для ntdll!LdrLoadDll:
Входим в айс, page LdrLoadDll - получаем физический адрес.
db -p <физ. адр.> - запоминаем, что там было и ставим CCh.
Проверяем, включено ли отслеживание int 3. Либо i3here on либо bpint 3.
Выходим.

Поскольку код длл разделяется между процессами то такой бряк сработает во всех процессах, даже в тех, которые еще не созданы. Когда же он сработает, предстоит жуткий геморрой - восстановить старое значение, выполнить инструкцию опять поставить CCh и так до посинения. Если это часто вызываемая функция, то я Вам не завидую ;-))) Можно для автоматизации макросы написать, если получится.

Four-F

Мдя... :((( ОК, спасибо хоть на этом, повторяя некоторых.

мдя скачал я 3.0 обламался просто напрочь не всплывает сравнивал с 4.2.7 разница колосальная 4.2.7 сразe сечет все функции а 3.0 игнорирует :(((( это во первых а во вторых система стала дольше грузится хотя sice не стоит в автозапуске короче 3.0 или конкретно сырой или я дальше чем 4.2.7 не сдвинусь так как 4.2.7 просто рулит :))))если есть решения более гуманные чем приведенные выше то прошу написать

если выбрать тип загрузки Boot отладчик всплывает нормально на любой bpx. если грузить вручную такая же канитель. а что в сайсе из ds 2.7 при ручной загрузке bpx ставится на все контексты?

Лучше ставить System (например в айсе 4.27 при мануал не работают bpx <адрес> какой нить проги с аспром под NT ось)

Пришлось вернуться с 4.3 обратно на 4.2.7 (ВинХР СП1 + куча хотфиксов с ВинАпдейта).

В 4.3 не ставятся бряки на все контексты, необходимо явно указывать контекст с помощью ADDR (как написано несколькими постами выше). Просто можно использовать ATTACH вместо макроса, чтоб при поп-апе САйс сам переключался в нужный контекст.

Кстати, в 4.3 была еще проблема. Ставлю бряк в контексте как положено - срабатывает. Стоит процесс завершить и запустить заново - поминай этот бряк как звали - не вывалится ни за что. Вылечилось подстановкой osinfo.dat и загрузкой символов ntoskrnl.

В 4.2.7 все бряки работают как часы с кукушкой. И без всяких там контекстов. И P RET, и всё остальное тоже работат. Вот так...

Compuware взялась за "ненужных использователей айса", хотя сами в интервью сказали, что не будут ограничивать айс (может нас хотели успокоить???)