Как открыть поток, зная его ID (номер) в отладчике?

Если при отладчик получает сообщение типа Create_thread, то в структуре u он получает несколько полей и HANDLE нового потока в отлаживаемом приложении. При этом ThreadId в структуре DEBUG_EVENT содержит номер того потока, который создал этот поток. Если возникает сообщение Exit_Thread, то HANDLE того потока, который закончился, не возвращается, а в самой структуре DEBUG_EVENT есть только его ThreadId.
Вот и получается - когда создается поток - мы узнаем его HANDLE, а когда этот поток заканчивается, мы узнаем его ID-номер. Поэтому надо как-то узнать HANDLE этого потока, закрыть этот объект и, тем самым, узнать - какой поток завершился.
Вопрос - как открыть поток, зная его HANDLE или как узнать ID-номер уже открытого потока?

 

А про какой отладчик вообще речь идет?

 

Блин...
Так и знал что это спросят. Я тренируюсь в использовании Debug API, поэтому я пишу маленький отладчик (эх, щас пинать меня будут). Вот такая проблема у меня возникла - при завершении потока никак по ID не могу узнать - какой поток завершился, так как в событии Create_thread передается не ID, а HANDLE.

 

Код (Text):

1. DWORD WINAPI GetProcessId( HANDLE Process );
2. DWORD WINAPI GetThreadId( HANDLE Thread );

 

Да? А у меня их в справке чего-то нету. Нет там и EnumProcesses.

 

EnumProcesses??? Сам придумал? Сначала делается снапшот системы, а потом Process32First...

SDK? Бери MSDN и будет тебе счастье

 

MSoft

А это что по твоему?

Код (Text):

1. BOOL WINAPI EnumProcesses( DWORD * pProcessIds, DWORD cb, DWORD * pBytesReturned );

В подтверждение
http://msdn.microsoft.com/en-us/library/ms682629(VS.85).aspx

 

Почему-то компилятор говорит что нет такой функции GetThreadId. Может подключить надо чего?

 

AndreyMust19
При создании потока отладчику передается не только хэндл потока, но и указатель на его TEB (=lpThreadLocalBase), из которого через ReadProcessMemory можно вытащить не только ThreadID, но и еще кучу всякой всячины

PS: GetThreadId есть только в висте и вынь2003

 

спас всем! leo, молодец, добавил в свой пост то, что я только что хотел спросить!
Ждите завтра дополнительных вопросов. Может, выложу исходники.

 

Forever
а я говорил, что такого нет? просто предложил альтернативный вариант Кроме того, мнение автора может не совпадать с его точкой зрения

 

Как найти место в коде, где располагаются данные потоков??........никак не могу найти ((((...
использую OllyDBG

 

stellaco
бряк на запись?

 

SPA
На произвольную память?... если так, то ставил... программа пароль и логин, всегда располагает в разных участках памяти.

 

Ох, беда с моей программой. Никак не получается нормально запустить отладку. Сначала возникает Create_process, потом много Load_dll, потом 2 exception, которые я пропускаю (потому что это Breakpoint). Потом, иногда, Create_thread. Но рано или поздно возникает еще одно exception (0xC0000005 - AV). В Блокноте оно возникает когда открываем или сохраняем файл, а в wincmd32.exe - когда появляется главное окно. То есть ни одно из этих маленьких программ не удается отладить полностью.
И еще. Никак не пойму - как работает ContinueDebug. Вроде бы ее надо вызывать после вызова WaitForDebugEvent. Если Wait-функции передать 0 во 2-м параметре, то она сразу проверит состояние отлаживаемого процесса и вернет последнее DEBUG_EVENT, которое возникло. Я думаю, что ContinueDebug надо вызывать только после того, как возникает новое отладочное событие. Дело в том, что иногда в моем отладчике продолжение отладки не происходит, и приходится насильно писать команду cont, чтобы вызвать ф-ю ContinueDebug еще раз. Вот я и не понимаю - почему иногда эта ф-я не продолжает отладку.

 

AndreyMust19
Странные вопросы задаешь, однако
На то он и отладчик, чтобы отлавливать исключения. Можно проигнорировать AV, передав его обработку проге (DBG_EXCEPTION_NOT_HANDLED): либо просто проигнорировать, либо предварительно поставить бряк на следующую за AV команду или на SEH-обработчик. Можно самому "обработать" исключение, подправив контекст потока и вызвав ContinueDebugEvent с флагом DBG_CONTINUE.

При возникновении отладочного события WaitForDebugEvent возвращает TRUE, отлаживаемая прога ес-но замораживается и соотв-но для ее разморозки после обработки события нужно вызывать ContinueDebugEvent. Eсли же происходит выход из Wait по тайм-ауту, то возвращается 0, при этом содержимое DEBUG_EVENT не определено и соотв-но никаких свитчей и ContinueDebugEvent делать не нужно
PS: Если что-то не срабатывает см.возвращаемый рез-т и GetLastError

 

То есть если она возвращает 0, если программа не прервана и продолжает работать? А то в справке на WinAPI-функции как всегда просто написано "если успешно - возвращается ненулевое значение, если 0 - возникла ошибка, используйте GetLastError". Вот и непонятно - что значит "успешный вызов" WaitForDebugEvent - то ли указанное время кончилось, то ли появилось новое отладочное сообщение.
А в каком случае ContinueDebug возвращает истину? Когда выполнение программы было успешно продолжено? А ложь - когда оказывается что программа итак уже выполняется?

 

stellaco 12
Все данные самого потока хранятся в TEB. А локальные переменные потока - на стеке (когда всплываешь в отладчике). Сам TEB находится по адресу FS:[0].

 

При завершении по тайм-ауту функция вернет 0, а GetLastError вернет WAIT_TIMEOUT

 

leo, Partner
Ладно, иду кодить, используя новые знания.