Вопрос касается грамотности написания драйверов, не только состоящих в «стеке», но и «одиночек».
1) как должен реагировать на все MJ_??? И MN_??? сообщения: а)можно ли поля в DRIVER_OBJECT struc, соответствующие различным (ессно, не основным) сообщениям оставить нулевыми, или б)обязательно направить на какую-нибудь PROC, чтобы она не делала ничего, а просто возвращала STATUS_SUCCESS? Вриант а-рабочий, но вдруг у меня ничё не «вылетало», только по тому, что мой драйвер еще не дорос до каких-то «особых» сообщений?
2) отдельный интерес к AddDevice. Когда в этом поле присутствует адрес какой-то PROC, то низя вырубить(выгрузить) драйвер (это и оправдано, if он в «стеке», а иначе если поле пустое и драйвер вырубить получаем #GP), но ведь есть IoDetachDevice – а после этого вызова реально вырубить драйвер? (ужасно неудобно ведь для пробы новой версии драйвера перегружаться и грузить его заново)
3)а теперь если я в стеке, то можно ли просто не обрабатывая послать вниз по стеку таких, как: POWER,PnP и др.

Цель понятна: добиться максимальной стабильности работы в любых ситуациях и оптимизировать процесс его(драйвера) разработки, тестирования и т.д.

Заранее благодарен. ---===PPS===---

1. Тупо возвращать STATUS_SUCCESS в любом случае есть очень плохо.

Если это не фильтр, то MajorFunction заполняешь только тем, что обрабатываешь. Остальные заполняет система указателями на IopInvalidDeviceRequest, которая возвращает STATUS_INVALID_DEVICE_REQUEST.

Если фильтр, то обрабатывать нужно все IRP_MJ_XXX, скопировать свою стековую область (IO_STACK_LOCATION) вниз, вызвав IoCopyCurrentIrpStackLocationToNext и звать драйвер ниже IoCallDriver.


2. Если есть AddDevice, то это P'n'P драйвер, а значит система будет слать ему IRP_MJ_PNP.IRP_MN_REMOVE_DEVICE. Там детач и делай.


3. Если имеется ввиду, можно ли послать свой собственный IRP вниз по стеку, то можно.

ЗЫ: Исходников P'n'P драйверов-фильтров полно - возьми да посмотри. Там много ещё всяких тонких моментов.