насколько я помню в System Volume Information
я про то и говорю. в EPROCESS->ExitStatus и сохранит
Интересно на какой такой случай и что плохого может оказаться в сегментном регистре кода?
Rustem от этого не исчезнет необходимость чекать EIP всех потоков на предмет попадания в область кода, куда будет записан джамп
я же писал: смысл трактуется родительским процессом
чтобы понимать как работает винда свою ось писать будешь?
не знаю какой ты смотрел справочник и почему искал именно функции - это инструкции сопроцессора fdiv - деление двух чисел, результат ST(1) /...
один только вопрос - а наюя это надо?
да, еще dt nt!_IRP -r <адрес> тоже не помешает
этот бсод возникает, если Irp->CurrentLocation <= 1, то есть у pDeviceObject у тебя StackSize=0 во время вызова IoBuildDeviceIoControlRequest но...
видимо ты неправильно обрабатываешь ирп. покажи !analyze -v и сбойную функцию-обработчик irp в твоем дрове
чтобы не свалить их, замораживаешь и смотришь указывают ли ихний EIP кудато внутрь области, куда пишем джамп. Если да - придется временно...
я в курсе что это) я его аналог уже написал. отладку еще раз говорю он не делает возможным) только наблюдение, но не активное участие и нафига...
просто сохранит. обычно его запросит потом родительский процесс. зависит от договоренности, как будет его трактовать родительский процесс. обычно...
Каким раком юзермодный отладчик поймает багчек? livekd и Windbg в режиме локальной отладки могут же только пассивно наблюдать за системой, но...
а ну это вряд ли причина отказа в записи крешдампа и много можно так надебажить? чтото я сомневаюсь что из юзермодного гуи можно отлаживать чтото...
локально с windbg это как? Причин может быть много... файла подкачки может быть недостаточно, либо его нет вообще, либо он расположен не на...
Maveric а как же анализ крешдампа? зы. виндбг умеет не только через COM дебажить..
с какого перепугу?
я обычно вижу правильный вариант с <=
Имена участников (разделяйте запятой).
