Отладка процесса, запущенного другим процессом

leo
Понятно. Погуглив, ничего на msdn не нашел, только вырезки кода как обработать это первое исключение.

 

KeSqueer
SecondChance генерится програмно при не обработанных исключениях посредством NtRaiseException, это позволяет избежать зацикливания(eg: #BP -> Dbg(FirstChance) -> SEH() -> NtRaiseException(SecondChance) -> Dbg(SecondChance) -> NtTerminateProcess). Ядро само завершит процесс если такая ситуация не будет разрешена отладчиком. Ведь в #15 написано.

Первый в процессе брейк системный, он находится в загрузчике и выполняется после его инициализации. Также и при иных разных условиях могут возникать останов, это например если в конфиге указан параметр "BreakOnDllLoad", логгирование событий и ошибок хипа и пр. Эти события необходимо пропускать, как и сказал leo.

Если вы будите трассировать чтолибо, то этой части нужно уделить особое внимание, ибо изза ошибки в ядре всякое исключение при трассировке приведёт к деадлоку.

 

Clerk

Не совсем понял, как это может произойти. В ядре есть ошибка, допускающая деадлок, если в отлаживаемой программе возникает исключение?

 

KeSqueer
Да. При всяком исключении отличном от #DB, значение TF переносится не в контексте как инфа об исключении, а в текущий контекст потока, трассировочный останов произойдёт в самом диспетчере исключений, а далее при входе в кс возникнет деадлок.

 

Просто фильтровать брейки - если не свой, то DBG_CONTINUE?

 

KeSqueer
Да. Если трассируете, то проверять Ip ~ [KiUserExceptionDispatcher % +15], в этом случае сбрасывать TF.

 

Забавно)

Ещё раз спасибо, всё предельно ясно.

 

Если пропускать вообще все #DB то можно нарваться на древнейше-примитивнейший антиотладочнй трюк с вызовом int3 в самой проге - если отладчик его обработает, то не будет вызван SEH-обработчик самой проги и она может "пойти лесом" совсем "не в ту степь"

 

Можно, но вроде никаких антиотладочных приёмов в данной программе замечено не было.