Подскажите, пожалуйста, как можно из драйвера под NT (.sys, kernel mode)
вызвать функцию dll (user mode) при уже загруженных виндах?
Если где-нибудь есть исходники программки-фильтра, буду очень признателен
за ссылку.
Спасибо.
Здравствуйте Andrew__S, Вы писали:
AS>Подскажите, пожалуйста, как можно из драйвера под NT (.sys, kernel mode) AS>вызвать функцию dll (user mode) при уже загруженных виндах?
Правильный ответ: никак. Нельзя из kernel-mode вызывать user-mode код.
Если ты хочешь из драйвера сообщить user-mode программе о каком-то событии, то у тебя есть выбор из двух вариантов:
1) Иметь объект события, доступный как в драйвере, так и в приложении. При возникновении события, драйвер переводит объект в signaled state, а приложение, соответственно, ждет на этом объекте.
2) Приложение посылает в драйвер ioctl посредством DeviceIoControl, который драйвер возвращает со статусом STATUS_PENDING. Когда происходит событие, драйвер завершает этот ioctl. Со стороны приложения это выглядит как длительная операция ввода/вывода.
Поправьте, если ошибаюсь, скорее подходит первый вариант, т.к.
вызов должен быть именно из драйвера, и драйвер же должен дожидаться
возврата от приложения.
AF>Q176415 Event.exe Shows How to Share and Signal an Event Object AF>http://support.microsoft.com/support/kb/articles/Q176/4/15.asp
Посмотрел.
Если и разберусь, то с трудом...
Если подскажите где лежит волшебный пример попроще, буду очень
признателен.
AF>1) Иметь объект события, доступный как в драйвере, так и в приложении. При возникновении события, драйвер переводит объект в signaled state, а приложение, соответственно, ждет на этом объекте.
AF>2) Приложение посылает в драйвер ioctl посредством DeviceIoControl, который драйвер возвращает со статусом STATUS_PENDING. Когда происходит событие, драйвер завершает этот ioctl. Со стороны приложения это выглядит как длительная операция ввода/вывода.
Забыл спросить:
как в драйвере в том же 'device control' дожидаться возврата от приложения?
Т.е. задача такая: послать буфер в приложение и, подождав пока приложение этот
буфер обработает, получить его обратно...
Здравствуйте Andrew__S, Вы писали:
AS>Подскажите, пожалуйста, как можно из драйвера под NT (.sys, kernel mode) AS>вызвать функцию dll (user mode) при уже загруженных виндах? AS>Если где-нибудь есть исходники программки-фильтра, буду очень признателен AS>за ссылку. AS>Спасибо.
Здравствуйте Andrew__S, Вы писали:
AS>Забыл спросить: AS>как в драйвере в том же 'device control' дожидаться возврата от приложения? AS>Т.е. задача такая: послать буфер в приложение и, подождав пока приложение этот AS>буфер обработает, получить его обратно...
Например:
1. Драйвер выставил событие (общее для драйвера и приложения) в сигнальное состояние и заблокировал свое выполнение через внутреннее событие (KeWaitForSingleObject) — лучше не до беконечности ждать, т.к. приложение может и упасть, а прикинуть по максимуму, сколько приложению надо на ответ (например, 30 сек).
2. Приложение увидело событие и запросило у драйвера данные по событию (через IOCTL).
3. Драйвер получил запрос, обработал его (т.е. буфер ушел в приложение).
4. Приложение получило данные от драйвера, поменяло там что-то и отправило еще один запрос в драйвера.
5. Драйвер получил новые данные и выставил внутреннее событие в сигнальное состояние.
6. Поток, заблокированный в п.1 — разблокировался.
7. Если приложение упало, то через 30 сек все и так разблокируется.
Связано это с тем, что:
1. Драйвер не может ничего послать в приложение. Только наоборот или через shared memory, что ИМХО не лучший способ.
2. Обработчики IRP вполне реентерабельны (если сам драйвер их не блокирует).
Но это вариант "сходу". Т.е. требует двух IOCTL и т.п. Можно сделать пару событий и один IOCTL и синхронизовываться по ним. Можно один IOCTL, а в его обработчике считать вхождения. На каждое второе — разблокировать поток. Ну и т.п. Варианты есть. Возмодно где-то я ошибся, но в целом логика такая.
