Всем привет. Собственно проблема описана в сабже, схематично: Код (Text): .... SetBreakpoint(breakpointAddr1); ... SetBreakpoint(breakpointAddrX); ... AddVectoredExceptionHandler(TRUE, BreakpointsHandler); ... B результате иногда программа вылетает с эксепшном при вполнении необрабатываемого int 3, по одному из тех адресов, куда ставились брейкпойнты.. В версии для х86 все работало нормально, подскажите, плз, кто знает с чем это может быть связано.
Clerk хм... что-то у меня такой функции в ntdll нету(или я что не так делаю) версия ntdll.dll 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
Ну так как понять почему не вызывается то, что должно быть вызвано. Там сразу должен стоять вызов векторного обработчика исключений. Идёт проверка головы списка обработчиков, есть зареганые - будет вызван. Перед этим идёт захват критической секции и дешифровка указателя. Где именно выполняется переход нитуда ?
Clerk проблема в том что брейкпоинт в диспетчере исключений(если я ничего не напутал и это KiUserExceptionDispatcher(а вообще пробовал ставить на все функции из RtlpFunctionAddressTable)) поставленый в WinDBG не срабатывает. С чем это может быть связано?
Я забыл что x64.. Тут нужно у когото есчо спросить почему точки останова не ставяться/не срабатывают в виндбг.
я так понимаю под x64 структура, на которую указывает RtlpCalloutEntryList совпадает с описаной здесь http://www.wasm.ru/print.php?article=veh (_VECTORED_EXCEPTION_NODE)? Так вот на выходе из AddVectoredExceptionHandler m_pfnVectoredHandler = baadf00d`00000001 т.к. память под _VECTORED_EXCEPTION_NODE выделяется RtlAllocateHeap похоже на то что поле m_pfnVectoredHandler не было заполнено, что весьма странно т.к. остальные поля структуры заполнены. Вообщем мистика какая-то
nobodyzzz Ох, что же сегодня такое творится. First-Chance Exception, Last-Chance Exception — говорит о чём-нибудь? First-Chance: жми меню Debug -> Go Unhandled Exception. Единственное, из-за чего реально может не вызываться векторный хендлер — очень хитрое повреждение кучи (ведь там хранятся элементы списка, ага), или сброс бита Peb.ProcessUsingVEH. А так вызов VEH в x64 аналогичен x86 — только вместо RtlCallVectoredExceptionHandlers сразу вызвается RtlpCallVectoredHandlers (хотя вызов RtlCallVectoredContinueHandlers оставили как есть лол).