Текущий IRP и запуск драйвера-фильтра

[sukhinin]

Написал драйвер-фильтр для клавиатуры (Windows). Возникла следующая проблема. После запуска драйвера первое событие клавиатуры проходит мимо. Как я понимаю, текущий IRP сидит где-то в IO Manager и ждет события, при этом ссылки на мой драйвер в его стеке просто нет.
Вопрос: Как можно удалить этот IRP? Никак не могу получить на него указатель. Может не там ищу и есть возможность включить мой драйвер в стек текущего IRP?
Помогите, пожалуйста.

[Ochkarik]

доброго!
сомневаюсь я что IRP может долго где то сидеть. - зачем ему?
хм... может IRP_MJ_FLUSH_BUFFERS  попробовать?

[sukhinin]

IRP именно сидит и ждет нажатия/отжатия кнопки. Система дает запрос на ввод. Формируется IRP, пробегает по всей цепочке драйверов. Каждый драйвет выставляет в IRP свой адрес Completion Routine. А моего драйвера в этот момент в цепочке еще нет. И событие IRP_MJ_FLUSH_BUFFERS просто пройдет мимо...
Непонятным является то, что при проходе всей цепочки драйверов до самого низа все DEVICE_OBJECT.CurrentIrp равны нулю. Из чего я и сделал вывод, что IRP околачивается где-то внутри IO Manager.
Это мой первый драйвер, поэтому не судите строго, если я, мягко говоря, чушь несу.

[Ochkarik]

минуточку... да  не может такого быть, помоему!?
IRP по идее формироваться должен ПОСЛЕ нажатия.
зачем его до нажатия незавершенным держать?

[Ochkarik]

аа... попробую сообразить. в драйвере клавиатуры есть буефер. драйвер, по прерываниям от клавы читает коды нажатых/отжатых клавишь и скидывает все это в свой буфер.
далее кто то, по MJ_READ из этого буфера все выгребает.
я правильно все представляю? /судя по kbdclass/

кстати вы к нему приатачились?

[sukhinin]

Все правильно. Вот только IRP_MJ_READ отправляется с опережением. И ждет когда появится что-либо для выгребания. А меня в момент отправки это IRP_MJ_READ еще нет. Соответственно в стеке IRP нет моей Completion Routine.
Со вторым событием уже все в порядке. Но для меня очень важно не пропустить ни ОДНОГО нажатия.

[sukhinin]

Извите, забыл про атач:
// ... //
NTSTATUS status = IoCreateDevice(pDriverObject,
              sizeof(DEVICE_EXTENSION),
              NULL,
              FILE_DEVICE_KEYBOARD,
              0,
              FALSE,
              &pHookDevice);
// ... //
NTSTATUS status = IoAttachDevice(pDeviceObject,
                                 &globals.deviceKeyboardUnicodeString,
                                 &pExtension->pKbdDevice);
То есть, атачусь к тому, что система считает драйвером клавиатуры верхнего уровни. Передо мной в цепочке находятся еще три драйвера.

[sukhinin]

Да, и вот еще имя устройства:
#define KEYBOARD_DEVICE_NAME L"\\Device\\KeyboardClass0"

[Ochkarik]

да, действительно, пардон, не дочитал)
"The IRP_MJ_READ request transfers zero or more KEYBOARD_INPUT_DATA structures from Kbdclass's internal data queue to the Win32 subsystem buffer. If there is no data in the data queue, a read request remains pending until it is completed or canceled." - последнее предложение.

значит надо его отменить: почему IRP_MJ_FLUSH_BUFFERS пройдет мимо?
он же по описанию как раз "IRP_MJ_FLUSH_BUFFER request flushes the Kbdclass input data queue" должен сбросить, соответственно и незавершенный IRP отменить?
и зависший IRP MJ_READ выйдет со статусом  "STATUS_CANCELLED - The request was canceled before the transfer actually took place. "
помоему так.
потому что? имено из этой очереди: "IRP_MJ_READ request transfers zero or more KEYBOARD_INPUT_DATA structures from Kbdclass's internal data _queue_"

[sukhinin]

Да, звучит убедительно. Полезу разбираться с параметрами для CcFlushCache. Но мне кажется, что все будет в порядке.
Большое спасибо за помощь!