Yes. This is NDIS6 driver.

I have not seen that issue for sometime. I will try to check for outsanding
OID request.
I do track the outstanding OID request. But is there a way I can find the
OID request that miniport is holding w/o
completion?

"Alireza Dabagh [MS]" <alid@online.microsoft.com> wrote in message
news:uwPjme0JHHA.4112@TK2MSFTNGP04.phx.gbl...

Unless a protocol specifies a Bind and Unbind handler in the protocol
characteristics, it can not register with NDIS (regardless of what version
it specifies or how it got installed). So in summary, while it is true that
a protocol (no matter how it is installed) can call NdisOpenAdapter
unsolicited, NDIS still will call its UnbindHandler before halting any
miniport that protocol is bound to. Therefore the assumption that this issue
may be due to an old non-PnP protocol being present and NDIS not being able
to ask it to unbind from the adapter is not correct.

BTW, UnloadHandler entry points is not relevant to this discussion.

-thanks, ali
--
This posting is provided "AS IS" with no warranties, and confers no rights.

<soviet_bloke@hotmail.com> wrote in message
news:1166981112.580883.153330@42g2000cwt.googlegro ups.com...

Don't you have a per miniport pointer to keep track of an outstanding OID
request? You should.

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Praveen Kumar Amritaluru" <apraveen.kumar@gmail.com> wrote in message
news:O$FiIo6JHHA.448@TK2MSFTNGP04.phx.gbl...

Alireza,


Do you mean that, from NDIS perspective, protocol driver still remains
PnP-compliant one, no matter how it got installed and bound itself to
the miniport below??? In fact, I never wrote protocols this way for the
reasons, mentioned by Maxim - you never know what and when to expect
from it, and doing things this way just does not offer you any
practical advantage
over the "supported" way of doing things. However, I've seen a
statement somewhere on OSR forum saying that, in practical terms, such
approach turns your driver into NDIS 3 style one, despite NDIS version
specified upon protocol registration. Are these concerns
unfounded???





I know - I meant to say UnbindHanler(), but for the reasons unknown
even to myself, said
UnloadHanler(). Please ignore this stupid omission

Anton Bassov

Alireza Dabagh [MS] wrote:

It depends how you define PnP-compliant. In any case, all I am saying is
that NDIS can unbind this protocol from the miniport whenever it wants to.

But from the point of NDIS knowing what should bind to what and initiating
the binding itself, you are correct that for protocols that have not been
installed properly, NDIS has no idea. Still NDIS can unbind them whenever
necessary (before halting the miniport).

-ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

<soviet_bloke@hotmail.com> wrote in message
news:1167064192.503620.59260@48g2000cwx.googlegrou ps.com...

Alireza,


Even if it *CAN* do it, *WILL*it??? This is quite an interesting
question.

The thing is, few times I was in a situation when enumerating adapters
yourself and binding to them right from DriverEntry(), instead of
relying upon .INF file and NetCfg, was quite desirable option, which
I did not take only because of the concerns about Unbind() and
PnPEvent() handlers that I have mentioned on this thread.

If NDIS does not really care about installation, then, probably,
legacy-style installation and binding to adapters right from
DriverEntry() is an option not as bad as it is generally perceived?

Anton Bassov


Alireza Dabagh [MS] wrote:

When an adapter is about to get halted, NDIS not only can but it -will-
unbind all the protocols bound to the adapter.

I am not sure what you mean by legacy installation. But you should install
your protocol through the inf file so user can see your protocol in the
network control panel and be able to bind/unbind the protocol from the
adapter by check/unchecking the box next to the protocol. Also when protocol
is installed properly, when a compatible adapter has been installed or
enabled, since binding engine has set up the registry properly, NDIS knows
that this protocol should be bound to the newly installed or enabled
adapter. If protocol is not installed properly this will not happen because
the binding information will be missing from the registry. i.e., if protocol
is not installed properly, disabling and enabling the adapter will leave the
protocol unbound from the adapter.
I do not see any reason for a protocol to get installed without inf file
except those legacy firewalls that like to stay hidden and register with
NDIS only to hijack NDIS and TCPIP's entry points (NOT good and a source of
many crashes, don't get me started there...)

-thanks, ali

--
This posting is provided "AS IS" with no warranties, and confers no rights.

<soviet_bloke@hotmail.com> wrote in message
news:1167207036.635992.20750@48g2000cwx.googlegrou ps.com...

Alireza ,

Thank you for your explanation.

In such case you don't need to bind to adapters anyway - just register
a protocol, cast it to
NSIS_PROTOCOL_BLOCK and get a pointer to the next protocol in a chain.
At this point you can deregister your protocol - NDIS library is yours
anyway...


You should just have some respect to the fact that some other drivers
may be around - don't get involved with anything, apart from packets,
and restore everything you touch. If you do it this way, everything
should be OK. Unfortunately, some AV/PF software does not take this
approach when it goes for NDIS hooking. For example, when Kaspersky is
around, everything in between TCPIP-WANARP and NDISWAN is out of play
(uncluding even PSCHED) - Kaspersky provides its own "packet
scheduler", and this piece of crap does not appear as PSCHED on its
either edge anyway . Due to Kaspersky and the likes, this wonderfull
technique is, unfortunately, frowned upon.......

Anton Bassov


Alireza Dabagh [MS] wrote:

Why Kaspersky AV ever needs a scheduler??
--PA

<soviet_bloke@hotmail.com> wrote in message news:1167282440.347098.101200@42g2000cwt.googlegro ups.com...

Pavel,

I am afraid you have to ask Mr.Kaspersky about it....

Is not it easier to block "undesirable" outgoing packet simply by not
passing it to the actual callee, queueing it for status indication,
returning STATUS_PENDING, and, at some later point, indicating it as
having been sent successfully (if you don't want to block a packet,
just pass it to the actual callee without getting involved in any
possible way)???


However, Mr.Kaspersky seems to have a different opinion on the issue -
all TCP packets with SYN flag get sent only in context of a system
thread; absolutely all calls to NdisSend() are protected by a spinlock;
PSCHED is out of play completely; and, in all respects, the system
behaves differently when Mr.Kaspersky "scheduler" is around.

As a result, even good and properly-written third-party drivers may
stop functioning on the system with Kaspersky AV installed.....

Anton Bassov

Pavel A. wrote: