Доброго времени суток! Суть вопроса в следующем: Имеем программу, загруженную в отладчик, в программе имеется проблемное место где происходит зацикливание, однако при нажатии на кнопку pause дебагер вываливается в библиотеке ntdll.dll. Каким образом выявить проблемное место? (особенно если в проблемном месте не происходит никаких вызовов с помощью call т.е trace window нам не помощник)
jCronuz тю я немного озадачен, но раз ты такое спрашиваешь вот тебе пример зацикливания: Код (Text): mov ecx,2 cc1: inc ecx dec ecx jecxz cc2 jmp cc1 cc2:
l_inc нет не там но ты был близок (на самом деле вываливается в ntdll_DbgUiRemoteBreakin) но как мне кажется суть дела это не меняет или я не прав? Если есть информация поделись пожайлуста, во всех случаях приходилось анализировать довольно значительную часть программы чтоб найти нужный кусок. Вопрос в том как указать дебагеру область отладки (или как это правильнее называется я хз) чтоб он не лез в ненужные мне длл. Кстати проблема была решена методом систематического тыка опций (конечно я стараюсь избегать применение этого метода ибо долго) вообщем нужно в опциях дебагера ставить такую хрень под названием stop on thread start/exit может быть кому то поможет сэкономить время в дальнейшем.
deadly83 Если поток зацикливается на коде, подобном Вашему примеру, то его EIP остается в пределах этого цикла. Следовательно, клацнув в IDA на соответствующий зацикленный поток в окошке Threads, Вы можете увидеть весь текущий контекст зацикленного потока, включая его EIP. Если же поток просто находится в состоянии ожидания, то его EIP указывает на KiFastSystemCallRet, с которого и продолжается исполнение потока в тот момент, когда планировщик потоков решит дать этому потоку процессорное время (в результате какого-то события, которого дожидался поток). Поэтому в случае, если поток вываливается на KiFastSystemCallRet (про DbgUiRemoteBreakin чуть ниже), Ваш пример не актуален. Большинство нормальных потоков при нажатии паузы с вероятностью, близкой к 100%, как раз и вывалятся на KiFastSystemCallRet. А теперь по поводу IDA (специально поставил, чтобы посмотреть на неё: сам пользуюсь OllyDbg в качестве отладчика). Когда Вы жмете паузу, то IDA вываливается на служебном потоке, предназначенном специально для отладки (как я указал выше, можно в окошке Threads клацнуть сразу на родной поток процесса и увидеть его контекст, не забивая себе голову разбором этого служебного потока), который создается системой в контексте отлаживаемого процесса. Вот этот поток и стартует с DbgUiRemoteBreakin. Как только вы оттрасируете этот поток до RtlExitUserThread, то IDA переключится на родной поток отлаживаемого процесса. Вот там Вы и увидите, где же зациклился родной поток.