Добрый вечер. Во время отладки в ядре винды возникло противоречие опции /p (в контексте команды ba) и ожидаемым результатом, основанным на описании опции тут: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/ba--break-on-access- А именно, когда я хочу аппаратно остановится на какой-нибудь функции в контексте нужного мне процесса и изложив желание отладчику такой командой: ba e 1 /p [EPROCESS] nt!NtCreateFile, опция /p не дала ожидаемого результата - отладчик почему-то брякается с любого контекста, игнорируя указанный мной /p [EPROCESS]. Вопрос, почему так? Что я не понимаю? Ведь не могли же меня дяди из Microsoft обмануть Или может быть у меня какой-то процессор особенный, который своеобразным образом обрабатывает бряки, игнорируя команды отладчика /p P.S С программными бряками (bp), к счастью никаких проблем нет. Но хотелось, чтобы и аппаратные работали, как ожидалось(мной).
Проверьте состояние бряка командой bl (list). Скорее всего адрес структуры [EPROCESS] указан не верно. В доке по вашему линку сказано-же:
Хм, я только что заметил - первая остановка происходит как надо, согласно указанному EPROCESS, но вот последующие остановки игнорируют /p опцию. Разве это ожидаемый результат работы ba?
так вроде параметр "Options" отвечает за время жизни. например такой вариант должен отработать 5 бряков: ba e 1 /5 /p [EPROCESS] nt!NtCreateFile
Я не выставлял вообще эту опцию, а значит, я говорю отладчику, что время жизни неограниченно --- Сообщение объединено, 20 июл 2023 --- Ну ладно, фиг с ним. Если так работает , значит так надо! В любом случае, отладчик у них замечательный
Аппаратные точки ставятся через отладочные регистры DR0..DR7, при этом DR6 является информационным. Когда одна из 4-х точек сработает, то в битах DR6.[3:0] взводится соответствующий флаг. Суть в том, что ЦП не очищает сам эти флаги в DR6 после срабатывания точки, чтобы программист мог отследить факт останова. По ходу WinDbg тоже не сбрасывает в дефолт эти биты, в результате чего бряк срабатывает всего один раз. Можно попробовать конструкцию ниже для установки точки.. Здесь, при очередном срабатывании бряка, командой "rM 20" (Register Mask) выводится лог состояния регистров DR0-DR7 (см.биты DR6.[3:0]), после чего точка устанавливается повторно. Код (Text): ba e 1 /p [EPROCESS] nt!NtCreateFile " rM 20; ba e 1 /p [EPROCESS] nt!NtCreateFile; " --- Сообщение объединено, 21 июл 2023 --- Кстати можно в хвосте тоже поставить "rM 20", что посмотреть конфиг регистров до и после установки бряка: Код (Text): ba e 1 /p [EPROCESS] nt!NtCreateFile " echo ****; rM 20; ba e 1 /p [EPROCESS] nt!NtCreateFile; echo ****; rM 20; "
Ах дак вот в чём дело-то... Спасибо вам, как всегда помогли мне. А вот ещё, скажите, как вы определили корректную маску для отображения только нужных регистров - rM 20 Как вы выяснили, что именно маска 20 отобразит DR0-DR7?
В локальной справке WinDbg имеется табличка.. ну или здесь: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/rm--register-mask-
В команде выше ошибочка вышла (пишу навскидку, без тестов). Чтобы после установки HBP просмотреть состояние регистров DR0-7, нужно командой "р" в отладчике сделать шаг. Только тогда WinDbg обновит регистры DR. То-есть правильней будет указать примерно так: Код (Text): ba e 1 /p [EPROCESS] nt!NtCreateFile " rM 20; ba e 1 /p [EPROCESS] nt!NtCreateFile; p; rM 20; "
