ПАУЗА В ДРАЙВЕРЕ

Great

дело не в уровне. Обработчик (по крайней мере у меня) работает на PASSIVE_LEVEL, как и требуется для Callers of KeDelayExecutionThread must be running at IRQL = PASSIVE_LEVEL

 

cresta
ну пассив так пассив. значит действительно винда ждет ответа.. а что за бсод кстати? покажи

 

Great

Вообще-то я слегка смухлевал )) Немного подыграл автору: мой драйвер работает и с KeDelayExecutionThread, бсод возникает при попытке выгрузить драйвер до окончания обработки пакета: DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS

Чего не хватает авторскому драйверу - трудно сказать. Кода нету, что возвращается из обработчика - неизвестно. Может нужно возвращать STATUS_MORE_PROCESSING_REQUIRED, или использовать IoMarkIrpPending с возвратом STATUS_PENDING...

Продолжаем гадать на кофейной гуще.

 

дык у тебя на чем построен твой драйвер? небось на ndis, tdi?
у автора же на кривом виндовом фильтре. там и не такое может быть...

 

вообще-то мой на tdi построен.

 

и сразу в драйвера, ужос.. в таких условиях появляются элитные бсодогены

 

Спасибо Freeman'у за "элитные бсодогены" - улыбнуло. На знакомом языке говоришь
Я смотрю мою проблему так расписали, так расписали, аж но привстал и окончательно упал!
TermoSINteZ: по поводу исходников : в первом посте есть сцылка на статью, код взят ПОЛНОСТЬЮ из этой статьи. (Примечание: у кого не открывается, удалите точечку в конце ссылки). Спасибо van'у. А вот и ссылка: http://www.wasm.ru/article.php?article=netfilter
А насчет ошибки, то система намертво зависает, не показывая ничего, даже фиги в виде СЭС. Это при использовании KeDelayThreadExecution(бл я уже из памяти функцию написал), ну и подобных ZwYieldExecution.
П.с.: *KeDelayExecutionThread ошибочка в памяти моей.
Система стабильная ... не помню чтобы так зависала ... win pro lic preSP3 last update 26.12.2007 один год прямо хорошо работает(тьфу,тьфу,тьфу, крест).
n0name: зачем же сразу обзываться, "кривой виндосовский фильтр", в умелый руках все работает.

ПЫСЫ: ну тема ТЕМА ТЕЕММАА то какая, ПАУЗА В ДРАЙВЕРЕ, вот и выкладывайте все возможные идеи на эту тему, не одну функцию мусолить собрались же... за самую реальную с меня без базара 10WMZ.

 

В общем, не поленился, собрал тот драйвер, на который автор указал ссылку.
Ну и оказалось, что фильтрация вызывается на DISPATCH_LEVEL ))

"Любой поток с IRQL >= DISPATCH_LEVEL не может использовать никакие функции ожидания Диспетчерских Объектов ядра с отличным от нуля временем ожидания."

Так что cou, делайте выводы

 

Выводы я давно сделал, написав что KeDelayThreadExecution не работает.
invoke KeStallExecutionProcessor,500000 - вот эта работает... но процессор загружает... а нужно чтобы не загружала... ёпт
так же работает и пустой цикл... процессор загружен... кинь те уже в меня куском кода со счетчиком таймера и моя душа будет спокойна...

 

на DISPATCH_LEVEL можно использовать KeStallExecutionProcessor.
Проверил - бсодов нет.
Правда время ожидания для драйвера по KeStallExecutionProcessor не рекомендуется делать более 50 мс.
Хотя я попробовал 2000 мс - бсодов не было.
В общем попробуй.

Самому понижать irql - геморрой ещё тот.
А таймер ничего не даст - задержка никуда не денется, а прерывания обрабатывать надо.

 

ну вот и я о чем, там же совершенно разные технологии

при применении таймера тоже DISPATCH_LEVEL не пройдет. прочти KmdTut для начала, там все доступно описано, и примеров много.

хех. ожидаемо. все-таки pending на таком высоком уровне фильтрации афаик не реализован.

 

cou

нельзя ждать на диспатч левел. яснО?
я ведь сразу почуял

может быть можно, а зачем? если есть необходимость ждать на irql>=2 значит код плохо спроектирован

 

Хе у мну подобный дров валяеться, только не по этой статье его клепал, давно правда, года 2 назад попросили.
cou Если надо то могу дать, но честно сказать этот метод наверно самый хреновый который можно сделать.
P.S. Дров на Си.

 

Выклади пожалуйста,О.

 

Доступно, я кое что понял из всей этой долгой беседы, ночью подведу итоги.

 

делаю вывод что не умеешь читать документацию
Callers of KeDelayExecutionThread must be running at IRQL <= APC_LEVEL.

 

Есть теоретики, а есть практики...
Что по теме скажешь?

 

cou ЛС проверил?