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

Существует ли какое-нибудь событие по subj?

 

хм. drX + отлов обращений к порту.

 

Уж тогда проще ослеживать не порт, а IRP'ы.
Нужно отлавливать из UserMode.

 

Делаем cli, очистка drx, перенаправления обработчика int1 на себя. Как теперь отлавливать будешь?

 

Agent666
есть _конструктивные_ предложения?

 

Что за - drx, драйвер?

 

Agent666

Ха, а если запретить обращение к регистрам отладки, то первая же твоя "очистка" dr будет в старом обработчике.
Второй момент Vista контролирует целостность IDT и просто так не даст перехватить int1

Третий мометнт
1) dr содержит адрес где хранится int1 (т.е. внутри таблицы IDT)
2) запрещено обращение к отладочным регистрам

Тгда если попробовать обратится к dr процессор зависнет, или обратится к адресу где int1 то процессор тоже зависнет вот и все
Делаем cli, очистка drx, перенаправления обработчика int1 на себя. Как теперь отлавливать будешь?
идут в одно место (но выход есть).

 

n0name

По поводу конструктивных предложений - не знаю как на IDE, а на SCSI встретил такую фишку помоему у IBM (давно было) есть комманда запрещающаяя реагировать винт на все обращения по управлению питанием, но это частный случай. Я бы всеж таки использовал SoftICE ест-но под виртуалкой и ставил бряк на порт комманд, если al= .. не помню уже какой код.

 

Ну так я сначала поставлю обработчик, а потом и буду очищать.

Да это тоже параллельно. Делаю cli, потом lidt и пусть она хоть до посинения проверяет, неколышит.

Запрещено - разрешим. А idt загрузим вобще свою.

Если процессор поддерживает виртуализацию, то вырубаем ее поддержку.

 

Agent666

Да это тоже параллельно. Делаю cli, потом lidt и пусть она хоть до посинения проверяет, неколышит.
Она проверяет и регистр IDT. Интересно а разве cli сможет противостоять межпроцессорному прерыванию. Кстати я попался на эту удочку с переходом на Core 2 Duo
PS: если процессор в виртуальном режиме - то виртуализацию невозможно отлючить в гостевой системе

 

Как же она проверит, если для проверки надо чтобы проверящий код мог получить управление в момент работы с подмененной IDT?

Проверки все идут из DPC (которые исполняются внутри прерывания таймера), а не из NMI. Да и NMI при переходе на свою IDT можно легко переопределить.

Если код исполняется на виртуальной машине, то тут вобще может и не быть никакого hdd. Остается только накрыться простыней и медленно ползти на кладбище.

 

debug registers

 

Agent666
PROFi

что спорить, и так ясно что снять слежение, построенное на drX-регистрах достаточно просто.
Правда есть вариант редактировать таблицу страниц так, чтобы при обращении к IDT генерировалось исключение. И обрабатывать его в своём обработчике.

 

Топик запощен в WIN32, отсюда можно сказать, что средствами ринг3 - никак

 

Ну почему же никак, есть - GetDevicePowerState. Но нужно не опрашивать, а отлавливать событие.

 

Неужеле придется тупо вызывать эту функцию приводя к ненужной загрузке CPU?

 

Мона через каждые Sleep(100) вызывать, тада загрузки ненужной не будет

 

Чем хуже таймер?

 

А можно поподробнее? На первый взгляд это самый верный способ отправить проц в даун из-за triple fault.

 

triple fault? я только double встречал.
а в чем проблема-то? встречал несколько сорцев где заменялся стандартный обработчик.