NdisIMInitializeDeviceInstance fails with code NDIS_STATUS_NOT_ACCEPTED

NTDEV
1

Hello,

I have a NDIS Intermediate Driver based on the PassThru sample. The driver works fine on most systems, except on a Vista SP1 x64 with a Nvidia Nforce network card. After install, the network adapter is initialized successfully, but after restart the adapter initialization sometimes fails.

The sequence of events is this:

-Driver starts, ProtocolBindAdapter is called for the Nvidia adapter, NDISWANIP and NDISWANIP6
-ProtocolUnbindAdapter is called for the Nvidia adapter, NdisIMCancelInitializeDeviceInstance returns success.
-ProtocolBindAdapter is called again for the Nvidia adapter. Here NdisIMInitializeDeviceInstance fails in about 50% of cases with code NDIS_STATUS_NOT_ACCEPTED.

I tried the PassThru driver and it doesn’t have this issue. I have look closely at both drivers and all the important parts coincide. I suspect a race condition somewhere, but I don’t know where to look. I’m grateful for any pointers.

Thank you.

2

I suggest that you add some tracing to show prove to yourself that in the
case where the cancel succeeds that your MiniportInitialize() /
MiniportHalt() are not being called as expected and that the other rather
delicate synchronization in PASSTHRU has not been disturbed by your changes.
Be sure to log the CPU# and Thread to assist in understanding if a race is
occurring, how it happens.

I have look closely at both drivers and all the important parts coincide.

I suggest then you look at the unimportant parts. Can you disable the
processing that you customizations perform and actually let your IM driver
run as a PASSTHRU clone? Perhaps they are not unimportant.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, March 25, 2009 4:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NdisIMInitializeDeviceInstance fails with code
NDIS_STATUS_NOT_ACCEPTED

Hello,

I have a NDIS Intermediate Driver based on the PassThru sample. The driver
works fine on most systems, except on a Vista SP1 x64 with a Nvidia Nforce
network card. After install, the network adapter is initialized
successfully, but after restart the adapter initialization sometimes fails.

The sequence of events is this:

-Driver starts, ProtocolBindAdapter is called for the Nvidia adapter,
NDISWANIP and NDISWANIP6
-ProtocolUnbindAdapter is called for the Nvidia adapter,
NdisIMCancelInitializeDeviceInstance returns success.
-ProtocolBindAdapter is called again for the Nvidia adapter. Here
NdisIMInitializeDeviceInstance fails in about 50% of cases with code
NDIS_STATUS_NOT_ACCEPTED.

I tried the PassThru driver and it doesn’t have this issue. I have look
closely at both drivers and all the important parts coincide. I suspect a
race condition somewhere, but I don’t know where to look. I’m grateful for
any pointers.

Thank you.

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

3

Hello and thank you for replying.

I did put traces in the driver. After NdisIMInitializeDeviceInstance fails, no more MiniportInitialize / MiniportHalt calls are made. The system is uni-processor, but I will add the thread information in the traces.

The rest of the application is not installed. My driver is running as a PassThru clone.

What bothers me is that NdisIMInitializeDeviceInstance is called after ProtocolUnbindAdapter returns. In MSDN is specified that NDIS_STATUS_NOT_ACCEPTED means “NdisIMInitializeDeviceInstance failed because the device specified by DriverHandle has already been initialized.” So I haveno ideea why this is happening.

4

The thread IDs are important - even on UP machines - because all of this
runs at PASSIVE_LEVEL.


What bothers me is that NdisIMInitializeDeviceInstance is called after
ProtocolUnbindAdapter returns.

This statement does not make sense as you have written it. Of course it is
called *after* ProtocolUnbindAdapter() returns. It is called in the context
of the *next* ProtocolBindAdapter() invocation, right?

What is going on is that NDIS is binding your IM driver. Then, because your
IM driver is NDIS5, it is unbinding your IM driver because some other
component in the network stack has ‘paused’ the stack. Perhaps an LWF
driver is being inserted. Whatever. Since NDIS5 emulation in NDIS6 cannot
ask an NDIS5 Protocol to ‘pause’, it unbinds it while the remainder of the
stack below does whatever it is it is doing. When the stack is ‘resumed’,
the NDIS5 elements are bound back in.

Or something like that :slight_smile:

The point being is that during boot up the sequence of bind operations
occurs in such a way that for this NIC, you get bound, unbound, and bound
again pretty quickly. You will probably note that if you disabled your IM
driver binding with BindView, booted the system, and then enabled the
binding for you IM driver, that you would only get one ProtocolBindAdapter()
and all would be wonderful in the world.

To simulate what happens at boot time without having all of the unimportant
things happening at boot time, try disabling the adapter. You can still
enable the ‘binding’ (installation of your IM driver) on the adapter even
though it is disabled. When you enable the adapter, NDIS will bring up the
bindings.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, March 25, 2009 6:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NdisIMInitializeDeviceInstance fails with code
NDIS_STATUS_NOT_ACCEPTED

Hello and thank you for replying.

I did put traces in the driver. After NdisIMInitializeDeviceInstance fails,
no more MiniportInitialize / MiniportHalt calls are made. The system is
uni-processor, but I will add the thread information in the traces.

The rest of the application is not installed. My driver is running as a
PassThru clone.

What bothers me is that NdisIMInitializeDeviceInstance is called after
ProtocolUnbindAdapter returns. In MSDN is specified that
NDIS_STATUS_NOT_ACCEPTED means “NdisIMInitializeDeviceInstance failed
because the device specified by DriverHandle has already been initialized.”
So I haveno ideea why this is happening.

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

5

I forgot to ask in my first response:

What is the FilterClass you are using?

What other NetService ‘filters’ (IM or LWF) are bound to the NIC?

What are the relative ‘altitudes’ of your IM and any other LWF or IM
drivers? (This will take some work to figure out from the registry and/or
using !ndiskd)

When you ‘tested’ with PASSTHRU, what altitude did PASSTHRU get installed
at? The same as you IM driver?

The reason I ask all of this is to point out that if your driver and
PASSTHRU do not get installed at the same altitude, then, they might well
see quite different binding behavior. I would not assume that PASSTHRU
does *not* have a race condition just because it does not have this symptom.
[note: I don’t know that it *does* have a race condition on rapid rebind.
I am just exercising caution.] PASSTHRU might be faster or slower or more
lucky than your driver.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, March 25, 2009 6:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NdisIMInitializeDeviceInstance fails with code
NDIS_STATUS_NOT_ACCEPTED

Hello and thank you for replying.

I did put traces in the driver. After NdisIMInitializeDeviceInstance fails,
no more MiniportInitialize / MiniportHalt calls are made. The system is
uni-processor, but I will add the thread information in the traces.

The rest of the application is not installed. My driver is running as a
PassThru clone.

What bothers me is that NdisIMInitializeDeviceInstance is called after
ProtocolUnbindAdapter returns. In MSDN is specified that
NDIS_STATUS_NOT_ACCEPTED means “NdisIMInitializeDeviceInstance failed
because the device specified by DriverHandle has already been initialized.”
So I haveno ideea why this is happening.

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

6

I was trying to say that I don’t understand why NdisIMInitializeDeviceInstance fails. From the documentation I concluded that it will fail only if it is called a second time for the same adapter, without NdisIMCancelInitializeDeviceInstance being called first, but this is not happening.

Thank you for the explication of the sequence of NDIS events.

7

Actually, NdisIMInitializeDeviceInstance() can fail because the target
device object is starting, already started, or stopping. It only will
succeed when the DO is stopped. So the reason it is failing must be
because (perhaps) your unbind operation returned before the upper miniport
was really stopped. But I believe your statement that MiniportInitialize
was not called.

One thing you might try doing is to actually eliminate the IM driver states
that allow for cancelling the NdisIMInitializeDeviceInstance() (note the
WIN9X code in PASSTHRU). Basically, wait in ProtocolBindAdapter() until the
Miniport is initialized (or fails). In ProtcolUnbindAdapter(), wait until
the Miniport halts. Sure, you slow things down a bit but by running in that
‘lock step’ you prevent returning control to NDIS during the Bind/Unbind
until you are sure the upper Miniport is stable in either the initialized or
halted state.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Wednesday, March 25, 2009 7:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NdisIMInitializeDeviceInstance fails with code
NDIS_STATUS_NOT_ACCEPTED

I was trying to say that I don’t understand why
NdisIMInitializeDeviceInstance fails. From the documentation I concluded
that it will fail only if it is called a second time for the same adapter,
without NdisIMCancelInitializeDeviceInstance being called first, but this is
not happening.

Thank you for the explication of the sequence of NDIS events.

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