Hello,
I have modified passthru sample from the latest WDK on WinXP SP2 platfom.
The only change was that I’ve inserted “return STATUS_UNSUCCESSFUL” (=
NDIS_STATUS_FAILURE) at the first line in DriverEntry. After that, computer
was unable to get IP address and connect to net. I thought if DriverEntry
fails initialization, the driver will not remain loaded and that’s all… or
am I wrong?
Thanks,
Petr
Sure, that is true, the driver will not remain loaded.
What you fail to realize is the consequences of *not* loading that an IM
driver has on the system network stack.
What you have created is a situation where the IM driver is ?bound? into the
logical stack of drivers for a network interface. The IM driver is not
starting and you are expecting it to have no effect. That is not how it
works.
When an IM driver is bound to an adapter, the IM driver protocol edge
becomes exclusively bound to the adapter and a new ?virtual? adapter is
created by the miniport edge of the IM driver. This new virtual miniport is
where protocols are bound.
If the IM driver does not load that virtual miniport does not ever start and
as far as the system is concerned, the network adapter is not started.
If an IM driver is *bound* to an adapter, the IM driver becomes a critical
component for that logical interface.
That is just the way it works.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Friday, June 05, 2009 11:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DriverEntry of NDIS IM
Hello,
I have modified passthru sample from the latest WDK on WinXP SP2 platfom.
The only change was that I?ve inserted ?return STATUS_UNSUCCESSFUL? (=
NDIS_STATUS_FAILURE) at the first line in DriverEntry. After that, computer
was unable to get IP address and connect to net. I thought if DriverEntry
fails initialization, the driver will not remain loaded and that?s all… or
am I wrong?
Thanks,
Petr
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>When an IM driver is bound to an adapter, the IM driver protocol edge becomes exclusively bound to
the adapter and a new ?virtual? adapter is created by the miniport edge of the IM driver.
Is this also true for NDIS 6 filters?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
If your driver is marked as mandatory in the INF file, then the
networking stack would fail if you don’t load it properly
Gene
Petr Kurtin wrote:
Hello,
I have modified passthru sample from the latest WDK on WinXP SP2
platfom. The only change was that I’ve inserted “return
STATUS_UNSUCCESSFUL” (= NDIS_STATUS_FAILURE) at the first line in
DriverEntry. After that, computer was unable to get IP address and
connect to net. I thought if DriverEntry fails initialization, the
driver will not remain loaded and that’s all… or am I wrong?Thanks,
Petr
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
It is true - after all they are IM drivers by heart 
G
Maxim S. Shatskih wrote:
> When an IM driver is bound to an adapter, the IM driver protocol edge becomes exclusively bound to
> the adapter and a new ‘virtual’ adapter is created by the miniport edge of the IM driver.
>Is this also true for NDIS 6 filters?
It is true of IM drivers in NDIS6. It is not necessarily true of LWF
drivers in NDIS6 which perform an ‘attach’ operation explicitly. IIRC
NDIS6 does have provisions for “optional” and “required” LWF entities - the
distinction being that if a “required” LWF does not successfully attach to
the adapter, the entire stack is considered inoperable. This is leveraged
by the Native WiFi LWF which must interpose itself (successfully) to adapt
from 802.11 framing to 802.3 framing.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, June 05, 2009 2:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DriverEntry of NDIS IM
When an IM driver is bound to an adapter, the IM driver protocol edge
becomes exclusively bound to
the adapter and a new ?virtual? adapter is created by the miniport edge of
the IM driver.
Is this also true for NDIS 6 filters?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Just to be clear, an NDIS6 LWF is *not* an IM driver. It attaches to the
bound miniport with a mechanism that does not introduce additional (virtual)
adapters and modified protocol bindings.
An NDIS6 IM driver is (as you say) an IM driver and thus acts as a protocol
which happens to create virtual miniports.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Soudlenkov
Sent: Friday, June 05, 2009 3:52 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DriverEntry of NDIS IM
It is true - after all they are IM drivers by heart
G
Maxim S. Shatskih wrote:
> When an IM driver is bound to an adapter, the IM driver protocol edge
becomes exclusively bound to
> the adapter and a new ?virtual? adapter is created by the miniport edge
of the IM driver.
>Is this also true for NDIS 6 filters?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
They are not IM in the strict sense but they follow many of the rules of
the IM drivers.
Gene
David R. Cattley wrote:
Just to be clear, an NDIS6 LWF is *not* an IM driver. It attaches to the
bound miniport with a mechanism that does not introduce additional (virtual)
adapters and modified protocol bindings.An NDIS6 IM driver is (as you say) an IM driver and thus acts as a protocol
which happens to create virtual miniports.-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Soudlenkov
Sent: Friday, June 05, 2009 3:52 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DriverEntry of NDIS IMIt is true - after all they are IM drivers by heart
G
Maxim S. Shatskih wrote:
>> When an IM driver is bound to an adapter, the IM driver protocol edge
>>
becomes exclusively bound to>> the adapter and a new ‘virtual’ adapter is created by the miniport edge
>>
of the IM driver.>>
>>
> Is this also true for NDIS 6 filters?
>
>
>
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks David for your clarification!
My NDIS IM driver was not marked as mandatory in INF, so I’m going to attach
network stack in any case and act as a passthru driver if my DriverEntry
initialization routine fails.
Thanks,
Petr
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: 5. ?ervna 2009 18:31
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DriverEntry of NDIS IM
Sure, that is true, the driver will not remain loaded.
What you fail to realize is the consequences of *not* loading that an IM
driver has on the system network stack.
What you have created is a situation where the IM driver is ‘bound’ into the
logical stack of drivers for a network interface. The IM driver is not
starting and you are expecting it to have no effect. That is not how it
works.
When an IM driver is bound to an adapter, the IM driver protocol edge
becomes exclusively bound to the adapter and a new ‘virtual’ adapter is
created by the miniport edge of the IM driver. This new virtual miniport is
where protocols are bound.
If the IM driver does not load that virtual miniport does not ever start and
as far as the system is concerned, the network adapter is not started.
If an IM driver is *bound* to an adapter, the IM driver becomes a critical
component for that logical interface.
That is just the way it works.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Friday, June 05, 2009 11:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DriverEntry of NDIS IM
Hello,
I have modified passthru sample from the latest WDK on WinXP SP2 platfom.
The only change was that I’ve inserted “return STATUS_UNSUCCESSFUL” (=
NDIS_STATUS_FAILURE) at the first line in DriverEntry. After that, computer
was unable to get IP address and connect to net. I thought if DriverEntry
fails initialization, the driver will not remain loaded and that’s all… or
am I wrong?
Thanks,
Petr
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> When an IM driver is bound to an adapter, the IM driver protocol edge becomes exclusively bound
to the adapter and a new ?virtual? adapter is created by the miniport edge of the IM driver.
This new virtual miniport is where protocols are bound.
IIRC, this is true only for filters - they are not supposed to be bypassed by the very definition of filter.However, with MUX you can decide whether underlying adapters should be available to the bound protocol…
Anton Bassov
Yes, thanks for keeping me precise. The exclusive binding behavior is
provided by the default behavior of the NetService class installer for a
‘filter’ style IM driver.
MUX IM drivers or ‘other’ IM drivers that install with explicit NotifyObject
support for manipulating bindings are free to setup whatever mess they
choose for the binding strategy.
I inferred from the OP’s comments that the question was in regards to a
‘filter’ style IM driver.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, June 05, 2009 5:46 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DriverEntry of NDIS IM
When an IM driver is bound to an adapter, the IM driver protocol edge
becomes exclusively bound
to the adapter and a new ?virtual? adapter is created by the miniport
edge of the IM driver.
This new virtual miniport is where protocols are bound.
IIRC, this is true only for filters - they are not supposed to be bypassed
by the very definition of filter.However, with MUX you can decide whether
underlying adapters should be available to the bound protocol…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer