NDIS драйвер, хелп, проблемы

1. в моем собственном драйвере (IM) не отрабатывает NdisRequest (возвращает 0x103 с кодом NDIS_STATUS_PENDING - всегда! При посылке нижестоящему драйверу OID_GEN_VENDOR_DRIVER_VERSION, OID_GEN_SUPPORTED_GUIDS, OID_GEN_MAXIMUM_LOOKAHEAD, OID_GEN_MAC_OPTIONS и тд. -- это в начале.



До этого же все стандартно: по событию NetEventReconfigure вызываю NdisReEnumerateProtocolBindings (естественно для нулевого PADAPT). ProtocolBindAdapter, NdisOpenAdapter, NdisMRegisterDevice, MiniportInitialize отрабатывают успешно.



При этом же раскладе переписанный passthru драйвер от SteelRat на NdisRequest возвращает успехх. Причем и в этом драйвере и у меня ProtocolBindAdapter подсистемой NDIS вызывается с тремя различными pDeviceName: \DEVICE\NDISWANIP, \DEVICE\NDISWANBH, \DEVICE\4ADFC094-xxx-xxx-xxx-xxx -- драйвер сетевой карты. Но у него на любые события от PnP менеджера драйвер сетевой карты отвечает без задержек, а у меня с задеркой (NDIS_STATUS_PENDING).



И чистый passthru из DDK кстати тоже всегда возвращает NDIS_STATUS_PENDING. А дальше никакая работа IM драйвера невозможна, т.к. эти запросы постоянно приходят пачками. В чем тут может быть проблема?



ЗЫ: регистрация драйвера библиотекой NDIS проходит на ура...

 

Ну так это нормально. По завершении просто будет вызываться RequestCompleteHandler.

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

 

Ms Rem

Дело в том, что он всегда, на все запросы возвращает pending. вызов NdisRequest в реализации от SteelRat проходит успешно, без pending. Вот мне и интересно, почему? Код одинаковый.

 

Из за фазы луны наверно .

Еще раз повторяю, если возвращает NDIS_STATUS_PENDING - то надо это обрабатывать, а не говорить что другая реализация не возвращает. Вот что по этому поводу напсано в DDK.

Код (Text):

1. NdisRequest forwards a request to the underlying driver that it query the capabilities or status of its NIC or that it set the state of its NIC.
2. Status
3. Pointer to a caller-supplied variable that is set on return from this function. The underlying driver determines which NDIS_STATUS_XXX is returned, but it is usually one of the following values:
4. NDIS_STATUS_SUCCESS
5. The requested operation completed successfully.
6. NDIS_STATUS_PENDING
7. The request is being handled asynchronously, and the caller's ProtocolRequestComplete function will be called when it is completed.
8.  

Тоесть, если идет возврат NDIS_STATUS_PENDING, значит обработка запроса отложена, и по ее завершении будет вызван ProtocolRequestComplete. Можно просто ожидать завершения (синхронизируясь с ProtocolRequestComplete с помощью евента), но лучше не ждать, а делать асинхронную обработку событий.

 

=) хорошо, тогда почему же обработка _любого_ запроса _в_любой_момент_времени может быть отложена?

 

попробую сделать синхронную обработку, может что-то прояснится.

 

Потому что так работает драйвер минипорта либо NDIS IM сидящие сверху него. Читай блин DKK, если там сказано что так может быть, то надо это учитывать ьез лишних разговоров.

А то перед юзерами использующими твою программу (когда она начнет бсодить) тоже придеться отчитываться "почемуууу обработка может быть отложена..., я этого не знал...".