Вызов KeSetEvent прямо в обработчике аппаратного прерывания самоубийство ?

[SergeiS]

Здравствуйте! У меня есть драйвер для обслуживания устройства ввода цифрового сигнала. Я передаю в него события и затем, по прерыванию от устройства, взвожу эти события для пользовательского процесса чтобы он обработал информацию в отображенном на его пространство совместном с драйвером разделе памяти. Проблема в том что сегодня вдруг система "зависла" без синего экрана но не реагируя ни на какие раздражители. Я подумал что это повышение IRQL. Дело в том что я набираюсь наглости и вызываю KeSetEvent для совместных с пользовательским приложением событий прямо в процедуре обработки аппаратного прерывания от устройства. Может быть так что внтури KeSetEvent временно повысится IRQL (как написано в документации) а в это время происходит переключение ? и после переключения идет мертвая петля с ожиданием понижения IRQL ? Или же взведенное событие взывает переключение прямо при обработке прерывания ? Но это по идее невозможно. Обязательно ли в этом случае использовать DPC процедуру в драйвере для окончательной обработки поступившего прерывания и в частности взведения события ? Буду очень признателен за замечания и рекомендации!

[Ochkarik]

http://msdn.microsoft.com/en-us/library/ms801639.aspx

The KeSetEvent routine might temporarily raise the IRQL. If the Wait parameter is FALSE, the routine, before it returns, restores the IRQL to the original value that it had at the start of the call.

If Wait is set to FALSE, the caller can be running at IRQL <= DISPATCH_LEVEL. Otherwise, callers of KeSetEvent must be running at IRQL <= APC_LEVEL and in a nonarbitrary thread context.

ТОЛЬКО DPC.

[SergeiS]

СПАСИБО!!!

[SergeiS]

Премного Благодарен! Все заработало!

[Ochkarik]

да не за что)))
просто читайте внимательнее про каждую функцию, в DDK почти все есть)

а по поводу первого сообщения... почитайте руссиновича. там просто великолепно про IRQL, функции ожидания и переключения задач написано.