Счетчик в процедуре.

[Аноним]

В диспетчерской процедуре есть счетчик:

Count++

Некоторые команды

Count –

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

То есть:

Процедура Unload:

Если count <> 0 то ожидание пока все таки count не станет равным нулю, то есть продолжается выполнение диспетчерской процедуры.

[Scorp__)]

Если я не ошибаюсь, то диспетчерская процедура не может ждать - это приводит к синему экрану. Нужно выйти из DISPATCH_LEVEL подождать, а уж потом выгружаться.

[Аноним]

Scorp__), здесь речь о том, чтобы ждала не диспетчерская процедура, а процедура выгрузки.

[Scorp__)]

Тогда ты можешь использовать стандартные средства для синхронизации, например семафор. И пользуйся KeWaitForSingleObject().
По-моему так

[Аноним]

У меня не PnP фильтр.
Пробовал так:


переменная KEVENT event в DRIVER_EXTENSION

в driverentry

KeInializeEvent

в диспетчерской процедуре

KeClearEvent

потом например

IoSkipCurrentIrpStackLocation

IoCallDriver

и

kesetevent


в Unload

KeWaitForSingleObject


и нифига не работает

Как тогда, чтобы KeWaitForSingleObject работал ?

[Scorp__)]

А поподробней параметры и возвращаемые значения напиши пожалуйста. Просто основных знатоков почему-то нет сейчас  , а я с такими данными не могу ответить, все-таки недавно совсем драйвера начал писать  :oops:.

[Серж]

Аноним, что возвращает KeWaitForSingleObject?

[Аноним]

Переменная KEVENT Event в Device Extension

DrtiverEntry

KeInitializeEvent (pDeviceExtension->Event, SynchronizationEvent, FALSE)
Возвращает указатель на «событие»


Dispatch



KeClearEvent (pDeviceExtension->Event)
Возвращает указатель на «событие»
Count++
IoSkipCurrentIrpStackLocation
IoCallDriver

Count --
KeSetEvent (pDeviceExtension->Event, 0, FALSE)
Возвращает ноль



DriverUnload

Detach


If count != 0
KeWaitForSingleObject (pDeviceExtension->Event, Executive, KernelMode, FALSE, NULL)
Возвращает ноль и количество объектов (count)  = 0
Endif
Если диспетчерская процедура не выполнялась или выполнилась (все IRPs уже прошли) , то KeWaitForSingleObject конечно же (из кода выше) не выполняется.

IoDeleteDevice

Если выполнялась диспетчерская процедура, то после вызова IoDeleteDevice синий экран с ошибкой 0x00000CE.

[Серж]

Аноним, раз KeWaitForSingleObject возвращает 0, то она дожидается события, а посмотри, сам device к моменту выполнения IoDeleteDevice существует? Такое впечатление, что его уже нет.

[Серж]

Аноним, либо вновь возникает прерывание. Если есть обработка прерывания, проверь, делаешь ли IoDisconnectInterrupt.

[Pe]

"... а посмотри, сам device к моменту выполнения IoDeleteDevice существует?"

Куда он может деться ?
Может просто на него есть ссылки, и при удалении устройства, ссылки на него не удаляются. Код ошибки 0x00000CE, то есть Driver_unloading_without_cancelling_pending_operations.

Серж, нет обработки прерывания.

[Серж]

Может быть, действительно остаются IRP в очереди, им тоже нужен Cancel.
Попробуй остановиться  в SoftIce на удалении устройства, и посмотри, что еще осталось живое.

[Pe]

Серж,  у меня не испоьзуется внутренняя очередь устройства и если вызывается Unload при выполнении диспетчерской процедуры, действительно count != 0, но функцию KeWaitForSingleObject ставлю для чего, для того, чтобы выполнение диспетчерской процедуры продолжилось, пока count не станет равным нулю (код приведен выше) .

Ошибка появляется после вызова IoDeleteDevice (когда вызывается ExRelese вроде Resource или WorkItem, которая вызывает KeRemoveQueue и уже после нее ... дец, то есть, наверное при высвобождении ресурсов системной нитки) .

Только что не освобождается ...

И еще заметил, когда идет "загрузка" фильтра, pFile сначала равен нулю, потом он не равен нулю, но после выгрузки, он не становится равным нулю, хотя вызывается OdDereferenceObject pFile.

Количество ссылок на филтруемый объект не уменьшается.

Где pFile "держится" ...

[Серж]

Pe, без текста можно долго гадать, что происходит в твоей программе.
По тем обрывкам кода, которые приведены, могу еще высказать гипотезу,
что IoCallDriver может вернуть STATUS_PENDING вместо нормального завершения, а ты не проверив его, уничтожаешь свой девайс, оставляя висящим запрос к нижележащему драйверу.

[Pe]

Серж, с pFile' ом уже все понятно. Сделал.

Так у меня в диспетчерской процедуре кроме того, что написал выше, ничего нет.
И у меня - то ассинхронная обработка IRP, отправили и не ждем что там "внизу".