что в нем то же возможны не вполне предсказуемые эффекты. Например:
a eip в точке останова приводит к тому, что при повторном проходе этого фрагмента в этом месте окажется int 03. А если брекпойнт убрать все будет нормально.
А попытка поставить bpr в любом месте под 98SE наглухо вешает систему.
Трейсю прогу айсом под 98... (Оле-сервер, я в него защиту встраиваю)
Цепочка флоут пойнт операций. Делаю очередной степ (F8) - операция флоут-умножения. Вдруг: Поверх айса (!!!) всплывает месагбокс клиента - "рунтайм еррор" и включается мышка!!! Потом под ним - сам клиент. Когда я жму Ок, клиент дохнет, вместо него остается белое пятно, а вокруг него - клочья айса! Мало того! Когда я изрядно о--ев я запускаю ИЕ, чтобы поделиться ох-ением с общественностью (с Вами т.е.) клочья винайса проступают сквозь окно эксплорера и вних бегут строчки!!!
Это что же получается?! До сих пор, я считал айс единственной надежной прогой под МД, крайним средством распутывания проблем, если ничего больше не помогает (крайнее только мыло и веревка), а теперь и на него надеяться нелзя!
Выходит, захочешь удавиться, мыло обернется клеем, а веревка превратится в лом?
И вообще, конструктивно: как под айсом ОЛЕ-клиент ухитрился обнаружить, что сервер не отвечает, если айс даже часы останавлвает!?
Есть такой глюк в Soft Ice19.06.02 10:42 Автор: :-) <:-)> Статус: Elderman
Подобное у меня случалось в Win9x, когда трейсишь обработчик прерывания в V86 и доходишь до команды iret. А сразу после iret иногда пападаешь на команду ARPL. В принципе это стандартный для win9x способ перехода из ring3 в ring0 (по ARPL генерится исключение и оно ловится в ring 0). Но если на этом ARPL нажать F8/F10, то произойдет в точности то же самое, что у Zef'а: винда "выскальзывает" из под Софт-Айса, причем похоже что Софт-Айс этого даже не понимат (его картинка остается на экране, а потом сообщения из его command window выползают поверх Десктопа, пока не нажмешь Ctrl+D)
Вот как этот глюк воспроизвести (Win98SE, Soft Ice 4.01).
следующий код в io.sys (это конец обработчика int 2Fh, imho):
4636: 7503 jne 00000463B
4638: 83C9FF or cx,-001
463B: 1F pop ds ;<========= сюда ставим BPX
463C: CF iret
---
bpx я ставлю так:
:s 0 l ffffffff 75 03 83 c9
Pattern found at 0028:00102426 (00102426)
:bpx 0028:0010242B
Ждем пока сработает bpx, трейсим до ARPL и офигеваем :-)
[Win32] A ARPL то откуда берется?!19.06.02 11:51 Автор: Zef <Alloo Zef> Статус: Elderman
From SoftICE Users Guide
Understanding Transitions From Ring-3 to Ring-0 Many times when tracing into code using Windows 95 and Windows 98, you arrive at either an INT 0x30 or an ARPL. Both are methods for making a transition from Ring-3 to Ring-0.When you wish to follow the ring transition, you can save yourself the time and effort of stepping through a large amount of VMM code by using the G(o) command to execute up to the address shown in the disassembly.
Windows 95 and Windows 98 uses the following methods to transition Ring-3 code to Ring-0 code:
* For V86 code, Windows 95 and Windows 98 use the ARPL instruction, which causes an invalid opcode fault. The invalid opcode handler then passes control to the appropriate VxD. The ARPL instruction is usually in ROM. Windows 95 and Windows 98 use only one ARPL and it varies the V86 segment:offset to indicate different VxD addresses. For example, if the ARPL is at FFFF:0, Windows 95 and Windows 98 use the addresses FFFF:0, FFFE:10, FFFD:20, FFFC:30 and so on.
The following example shows sample output for disassembling an ARPL:
FDD2:220D ARPL DI,BP ; #0028:C0078CC9 IFSMgr(01)+0511
[Win32] Да нет, ты не понял! (Или я не понял)20.06.02 04:32 Автор: Zef <Alloo Zef> Статус: Elderman
как через ARPL передавать управление в R0 я знаю, но по твоему посту я понял, что ARPL появляется в коде там, где его раньше не было. А если это не так, то почему он стоит сразу после возврата? Или сей глюк появляется только когда прерывание пришло непосредственно перед выполнением этой команды? Но какова тогда вероятность на него нарваться?!
[Win32] ARPL находится в BIOS20.06.02 13:56 Автор: :-) <:-)> Статус: Elderman
> Трейсю прогу айсом под 98... (Оле-сервер, я в него защиту > встраиваю) > Цепочка флоут пойнт операций. Делаю очередной степ (F8) - > операция флоут-умножения. Вдруг: Поверх айса (!!!) > всплывает месагбокс клиента - "рунтайм еррор" и включается > мышка!!! Потом под ним - сам клиент. Когда я жму Ок, клиент > дохнет, вместо него остается белое пятно, а вокруг него - > клочья айса! Мало того! Когда я изрядно о--ев я запускаю > ИЕ, чтобы поделиться ох-ением с общественностью (с Вами > т.е.) клочья винайса проступают сквозь окно эксплорера и > вних бегут строчки!!! > Это что же получается?! До сих пор, я считал айс > единственной надежной прогой под МД, крайним средством > распутывания проблем, если ничего больше не помогает > (крайнее только мыло и веревка), а теперь и на него > надеяться нелзя! > Выходит, захочешь удавиться, мыло обернется клеем, а > веревка превратится в лом? > И вообще, конструктивно: как под айсом ОЛЕ-клиент ухитрился > обнаружить, что сервер не отвечает, если айс даже часы > останавлвает!?
Ничего удивительного - в какой-то цепочке проги произошло исключение и сдохла та цепочка которую ты отлаживал. Обычное дело - пока ты трейсишь одну цепочку по команде, другие выполняются потихоньку.
Айс по идее должен останавливать все, или?06.06.02 04:43 Автор: Zef <Alloo Zef> Статус: Elderman
> если отлаживаемый тред дохнет (там и правда был пэйдж фолт > из-за неправильной передачи указателя в функцию), он > разрешает выполняться другим?
Когда ты нажимаешь F10 чтобы перейти к следующей команде твоего thread'а система начинает жить своей жизнью (как жила до того как ты ее остановил) до тех пор пока твой Thread не добереться до своей следущей команды...
по F8 он НЕ ДОЛЖЕН передавать управление другим тредам. По F10, F12,ctrl+D - да, но в пошаговой трассировке он должен выполнять только отлаживаемый поток. И только по одной команде.
Да нет, так не должно быть:11.06.02 09:45 Автор: SerpentFly <Vadim Smirnov> Статус: Member
> по F8 он НЕ ДОЛЖЕН передавать управление другим тредам. По > F10, F12,ctrl+D - да, но в пошаговой трассировке он должен > выполнять только отлаживаемый поток. И только по одной > команде.
Может тогда и sheduling потоков отменить? Если слайс времени потока истек контекст должен переключиться, а в твоем понимании получается что при трассировке контекст потока никогда не переключается, то есть сайс превращает систему в однозадачную/однопоточную. Это вообще-то создает искуственную среду отладки забивая весь смысл отладки в реальной живой системе. Не говоря уже о том что должны вызываться обработчики прерываний, исполняться DPC и т.п..
То есть реален сценарий когда у тебя есть драйвер с ISR(устройство с прерыванием) и трассируешь какой-нить рабочий поток по F8, который допустим в цикле проверяет значение какой-то переменной в памяти (для большей реальности эксперимента устанавливаемой например в обработчике ISR, это так называемая spin блокировка в упрощенном варианте) и делает что-то как только ISR присвоит переменной определенное значение. В твоем понимании трассируя поток по F8 ты должен будешь вечно крутиться в цикле проверяющем эту переменную!!! Что же в этом правильного?
Да и если не упираться в драйвера, то как отлаживать многопоточные приложения?
Ну и на закуску, чем же отличается F8 от F10:
F8- The T command uses the single step flag to single step one instruction.
Execution begins at the current CS:EIP, unless you specify the start-address parameter.
F10 - The P command executes a logical program step. In assembly mode, one instruction at the current CS:EIP is executed unless the instruction is a call, interrupt, loop, or repeated string instruction. In those cases, the entire routine or iteration is completed before control is returned to SoftICE.
То есть в режиме асма обе команды работают идентично за исключением "call, interrupt, loop, or repeated string instruction".
но именно так и проиходит, тем не менее12.06.02 01:02 Автор: z0 <z0> Статус: Member
> присвоит переменной определенное значение. В твоем > понимании трассируя поток по F8 ты должен будешь вечно > крутиться в цикле проверяющем эту переменную!!! Что же в > этом правильного?
правильно-неправильно это все субъективно
вопрос-то был как происходит на самом деле при степах - бежит мультипотоковость-мультизадачность или стоит
смотри:
---------------------test.asm----------------------
.386
thread:
db 0cch ;please use F8/f10 from here
inc dword ptr [check]
thread_0:
cmp dword ptr [check],0
jne thread_0
push dword 0 ;dwExitCode
call ExitThread
Я отлаживал многопоточность в ядре и контексты потоков у меня переключались (по крайней мере при трассировке по F10). Не говоря уже о том что при трассировке на PASSIVE_LEVEL пришедшее DPC прерывает текущий трассируемый поток... Это из опыта, что думает по этому поводу айс сказать сложно не помев его сырцов, поведение может и разниться между версиями...
Не хочу вдаваться в твой асм, но...14.06.02 16:42 Автор: z0 <z0> Статус: Member
> Я отлаживал многопоточность в ядре и контексты потоков у > меня переключались (по крайней мере при трассировке по > F10). Не говоря уже о том что при трассировке на > PASSIVE_LEVEL пришедшее DPC прерывает текущий трассируемый > поток... Это из опыта, что думает по этому поводу айс > сказать сложно не помев его сырцов, поведение может и > разниться между версиями...
ну ядро это круто конечно! УВАЖАЮ!!!
хотя... а давай посмотрим что там в ядре творится...
может чего нового узнаем...
итак ядро - а значит драйверочек:
----------------------drvdrv.asm-------------------------
.386
IRPprocessor:
mov ecx,[esp+8] ;IRP
mov eax,[ecx+60h] ;IRP->CurrentStackLocation
cmp byte ptr [eax],0eh ;operation code = DEVICE_IO_CONTROL
mov eax,0
mov [ecx+18h],eax ;IRP->IoStatus.Status
mov eax,[nBytes]
mov [ecx+1ch],eax ;IRP->IoStatus.Information
push eax ;IO_NO_INCREMENT
push ecx ;pIRP
jne IRPprocessor_not_interesting
inc dword ptr [check]
cmp dword ptr [check],1 ;only this IRP is processing by now
;если не сделать эту проверку
;то быстренько попадем в deadlock
;когда ВСЕ потоки торчат на cmp/jne (классика жанра)
jne IRPprocessor_not_a_case
mov ecx,1000h ;здесь может произойти переключение задачи и начнет
delay: ;выполнятся IRPprocessor для другой задачи(inc) но не успеет
loop delay ;закончиться(dec). сам он сюда не проходит (см. выше)
;тогда мы попадаем в айс
;на быстрых цпу тут можно поиграть задержкой
cmp dword ptr [check],2 ;2+ IRPs are processing now
jb IRPprocessor_not_a_case
db 0cch ;please use F8/F10 from here
IRPprocessor_loop:
cmp dword ptr [check],1 ;wait for other IRPs to gonna away...
jne IRPprocessor_loop
IRPprocessor_not_a_case:
call IoCompleteRequest
xor eax,eax
dec dword ptr [check]
retn 8
IRPprocessor_not_interesting:
call IoCompleteRequest
xor eax,eax
retn 8
_text ends
_data segment use32 para private 'data'
DeviceObject dd 0
check dd 0
nBytes dd 10h ;для выхода измени этот dword и скажи на jne 'r fl +z'
end DriverStart
------------------------------------------------------
можно было конечно и в ините запустить поток например PsCreateSystemThread - и было бы попроще конечно
но там и придраться легче - а тут железно: 2 равноправных thread-а в ядре
проверка степов предлагается на одновременной обработке IRP от разных процессов
соответственно два+ раза запускается вот такой екзешничек:
------------------------ app.asm ----------------------
.386
extrn DeviceIoControl :near
extrn ExitProcess :near
; skipped some imports
_text segment use32 para private 'code'
assume cs:_text
assume ds:_data
entry:
call LoadDriver ;возвращает handle от CreateFileA('\\.\DRVDRV' и так далее)
mov esi,eax
test eax,eax
jz exit
entry_loop:
push esp
mov eax,esp
push dword 0 ;lpOverlapped
push eax ;lpBytesReturned
push dword BufferSize ;nOutBufferSize
push offset Buffer ;lpOutBuffer
push dword BufferSize ;nInBufferSize
push offset Buffer ;lpInBuffer
push dword 0babebabeh ;ControlCode
push esi ;hDevice
call DeviceIoControl
pop eax
cmp eax,10h
je entry_loop
call UnloadDriver
exit:
push dword 0
call ExitProcess
LoadDriver:
; skipped
UnloadDriver:
; skipped
_text ends
_data segment use32 para private 'data'
;skipped some data
BufferSize equ 10h
align 4
Buffer db 10h dup('?')
_data ends
end entry
------------------------------------------------------
очень (по-моему) убедительно доказывает ОТСУТСТВИЕ мультивсего при НОРМАЛЬНЫХ степах
и покажи мне версию айса где это не так
а объясняется все довольно тривиально: у TraceFlag-а САМЫЙ высокий приоритет
поскольку он обрабатывается ПОСЛЕ ПРЕДЫДУЩЕЙ инструкции (это кстати отразилось
в "КАК-БЫ пропуске" одной команды после установки флага) и никакие IRQ0 etc
не проходят т.к. принимаются МЕЖДУ инструкциями (в зазоре, который ПРОПАДАЕТ внутри EXCEPTION1)
поэтому для всех степов по флагу - никаких внешних событий НЕ СУЩЕСТВУЕТ
для других степов типа 'F10-call' которые в общем-то и степами назвать
трудно (редко чтоли call не возващает или не туда...) - сколько угодно
[z0]
ЗЫ: проверялось на nt4 english server sp6 + ntice 4.0.5 build 334 cpu=p166mmx
Ты на асме пишешь наверное чтобы легче код читался?15.06.02 10:47 Автор: SerpentFly <Vadim Smirnov> Статус: Member
А ты все-таки создай потоки через PsCreateSystemThread. В твоем примере возможно айс препятствует второму потоку войти в ядро. Повторюсь, я не знаю как айс организует трассировку и не хочу вдаваться в детали. Однако как я уже говорил между двумя потоками в ядре переключение все-таки происходит !!! (Win2k SP2 SoftIce Driver Suite 2.6)
У меня поток не в ядре. Не понял, кому совет?16.06.02 04:56 Автор: Zef <Alloo Zef> Статус: Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
