Странность с функцией GetThreadContext

Asterix
Мило. Не знали, что 9x не отматывает. А, стоп – или он отматывает rip (изменяет rip в структуре контекста), но адрес исключения (в записи исключения) оставляет в соответствии со значением, которое должно было бы быть у rip?

Rel
Таки имеет смысл обратить больше внимания на пост diamond'а

 

Sol_Ksacap

не смотрел, но все-таки логично отдавать именно адрес инструкции вызвавшей исключение
а не адрес+1

 

вариант с выводом ContextRecord->Eip

имеем
в XP:

Exception: 0x80000003 at address: 0x00401084 ContextRecord->Eip: 0x00401084

в Win98:
Exception: 0x80000003 at address: 0x00401085 ContextRecord->Eip: 0x00401085

 

Asterix
Не только #BP приводит к изменению Ip, например тотже результат будет для #OF([Prefixes]/Into).
Rel

Вы должны понимать как формируется контекст. Та структура именуемая CONTEXT является пользовательской, её аналог - аппаратный контекст(собственно это и есть состояние задачи, трап-фрейм), где последовательность некоторых регистров нельзя изменить(например Iret-фрейм). Когда поток меняет кпл на нулевой сразу формирует этот контекст, часть его формируется аппаратно, часть програмно, после чего этот контекст сохраняется в ядерном стеке и окружение сменяется соответствующим образом, дабы поток работал в ядре. При возврате из ядра в юзермод(точнее из сервиса/прерываний или ислючений) этот хардварный контекст загружается обратно в процессор. Таким образом предыдущее состояние задачи, на момент входа потока в ядро сохраняется и доступно, пока поток находится в ядре. Манипуляции железячным контекстом выполняются через посредника - пользовательский контекст. Более подробно в ядре доставляется апк и в неё этот хардварный контекст конвертируется в пользователький и возвращается.
Например поток вызвал сервис. Трап-фрейм формируется, для возврата из сервиса Ip корректируется должным образом, который определён самой моделью вызова. Например в случае сервиса при формировании трап-фрейма в Ip загружается адрес возврата на KiFastSystemCallRet. Далее пока поток находится в ядре(не имеет значения это ожидание или есчо что) при запросе на получение контекста этого потока будет возвращён базовый трап-фрейм сконвертированный в контекст, который и был изначально сохранён при входе в ядро.
Функции конвертирующие железячный контекст в пользовательский выполняют некоторые поправки его, этого требует архитектура оси и защита, но это не касается Ip.
Проблема в вашем отладчике, а не в системе, код не смотрел пока.

 

Clerk
пару моментов из вашего поста я знал, а за остальное - большое спасибо!