Как отловить остановку двигателя HDD?

тупанул, действительно, если PF будет на IDT как процессор узнает обработчик этого исключения.

 

нет, суть такая: IDT разделяется на 2 страницы, на первой находятся несколько первых обработчиков, на второй -- все остальные (включая 0Eh). Первая страница делается неприсутствующей (NP). Обработчик #PF должен рапознавать page fault'ы на 1й странице IDT и соответственно обрабатывать их, начиная от парсинга инструкции вплоть до вызова целевого обработчика исключения.
Пример реализации есть в ядре Win9x -- как официальный способ обхода pentium F0 bug. Это к тому, что сама по себе разбитая на 2 страницы IDT не должна вызывать подозрений. Хз есть ли такое в NT/XP, не проверял.

 

Тема сразу же пошла налево, причем уверенными шагами!

Хорошо, попробуем сначала - существует ли легальный способ отлавливать IRP, связанные со сменой режима электропитания, без создания драйвера (у MS REM'а, что-то было про CallGate в нулевое кольцо).

 

угу, есть такая буква,сам делал. Кстати, тоже на Win98. Интересную фишку тогда обнаружил. Мануалы
утверждают, что GD в DR7 сбрасывается при входе обработчик int 1 (что неверно при вызове обработчика
инструкцией int 01). Так вот, если IDT разбить на 2 странички таким образом, чтобы дескриптор int 1 был
Not Present, то GD сбрасывается и при входе в обработчик #PF.

 

_BC_
подозрение вызовет не родной обработчик PF.
Можно имзенть значение неэкспортируемой переменной KiDebugRoutine, и ловить исключения так.

 

ну на той же 9х целиком его и не надо менять, достаточно пропатчить F0-часть и включить (afair в msconfig) обработку F0 bug'а. А vmm32.vxd в 9х на патч проверить гораздо сложнее, чем тот же ntoskrnl в nt. Да и... кому это сейчас может приспичить, разбираться в ядре 9х...

 

Люди добрые, да помогите!

 

Бог поможет...