NDIS hanging during Init

I am trying to get an NDIS driver working on our system. During
bootup, Device.exe loads the PCI bus driver, which enumerates our
network card. It then loads ndis and points it to that card's instance.
So far so good. NDIS calls the driverentry in the card's driver, and
then calls MiniportInitialize. Both of those complete fine.
However, at this point things don't progress any more. My driver
continues to get MiniportSetInformation calls periodically and it
handles them. But NDIS_Init never completes, which doesn't allow
device.exe to load any more devices or complete. Any already
initialized devices continue to run, so it isn't a system hang,
interrupt issue, exception, or complete device.exe hang. I can use
kernel tracker and see that most time is in the idle thread.
What can cause NDIS_Init to hang while initializing a card after
MiniportInitialize is complete?

Thanks,
Bryan

stjong
Wed Jun 29 13:20:16 CDT 2005

You can use thread dump to see where it's hanging. I'm assuming if you
remove your hardware the system boots up successfully.
-- Soemin ---
Windows CE CoreOS/Networking
This posting is provided "AS IS" with no warranties, and confers no rights.

Bryan
Tue Jul 05 12:34:31 CDT 2005

Yes, if I remove the card, the system boots. Also, if I modify
MiniportInitialize to return failure, the system finishes the boot. The
problem occurs when NDIS tries to load my driver and appears to not ever
finish. Like I said, MiniportInitialize returns success, but NDIS is
periodically calling MiniportSetInformation and MiniportQueryInformation
with various OIDs. I assume that NDIS is not getting satisfactory
results from these calls, and therefore continues calling them
indefinitely.
I forgot to mention that it is a wireless card.
What OIDs can cause this? Which OIDs does NDIS require getting
particular answers for before it will complete the initialization for
the card and return execution to device.exe?

Bryan


Soemin Tjong [MSFT] wrote:
> You can use thread dump to see where it's hanging. I'm assuming if you
> remove your hardware the system boots up successfully.
> -- Soemin ---
> Windows CE CoreOS/Networking
> This posting is provided "AS IS" with no warranties, and confers no rights.
>

Paul
Tue Jul 05 12:42:28 CDT 2005

I see the same OIDs being sent to the Cisco card, too, and it works fine. I
don't think that you should assume that, just because you get the same OID
twice, that's the cause of the problem. Do you have entry and exit messages
from each routine in you miniport driver, so that you can look at the debug
output messages and verify that, when things stop, they're stopping, not in
your code, but in NDIS? The most likely problem is something with your
driver, of course.

Paul T.

"Bryan Bassett" <bbassett> wrote in message
news:%238gAVfYgFHA.2632@TK2MSFTNGP09.phx.gbl...
> Yes, if I remove the card, the system boots. Also, if I modify
> MiniportInitialize to return failure, the system finishes the boot. The
> problem occurs when NDIS tries to load my driver and appears to not ever
> finish. Like I said, MiniportInitialize returns success, but NDIS is
> periodically calling MiniportSetInformation and MiniportQueryInformation
> with various OIDs. I assume that NDIS is not getting satisfactory results
> from these calls, and therefore continues calling them indefinitely.
> I forgot to mention that it is a wireless card.
> What OIDs can cause this? Which OIDs does NDIS require getting
> particular answers for before it will complete the initialization for the
> card and return execution to device.exe?
>
> Bryan
>
>
> Soemin Tjong [MSFT] wrote:
>> You can use thread dump to see where it's hanging. I'm assuming if you
>> remove your hardware the system boots up successfully.
>> -- Soemin ---
>> Windows CE CoreOS/Networking This posting is provided "AS IS" with no
>> warranties, and confers no rights.
>>

Bryan
Wed Jul 06 19:13:29 CDT 2005

I figured it out. I had DHCP disabled and no IP info in the registry
for that adapter. So the main NDIS thread was hanging waiting to bind
to a protocol. In the background, other services (wireless zero config
maybe) were polling the driver for OIDs. Device.exe runs before
gwes.exe, so there is no way for ndisui to tell me it doesn't have an
IP. Oh well.

Bryan



Paul G. Tobey [eMVP] wrote:
> I see the same OIDs being sent to the Cisco card, too, and it works fine. I
> don't think that you should assume that, just because you get the same OID
> twice, that's the cause of the problem. Do you have entry and exit messages
> from each routine in you miniport driver, so that you can look at the debug
> output messages and verify that, when things stop, they're stopping, not in
> your code, but in NDIS? The most likely problem is something with your
> driver, of course.
>
> Paul T.
>
> "Bryan Bassett" <bbassett> wrote in message
> news:%238gAVfYgFHA.2632@TK2MSFTNGP09.phx.gbl...
>
>> Yes, if I remove the card, the system boots. Also, if I modify
>>MiniportInitialize to return failure, the system finishes the boot. The
>>problem occurs when NDIS tries to load my driver and appears to not ever
>>finish. Like I said, MiniportInitialize returns success, but NDIS is
>>periodically calling MiniportSetInformation and MiniportQueryInformation
>>with various OIDs. I assume that NDIS is not getting satisfactory results
>>from these calls, and therefore continues calling them indefinitely.
>> I forgot to mention that it is a wireless card.
>> What OIDs can cause this? Which OIDs does NDIS require getting
>>particular answers for before it will complete the initialization for the
>>card and return execution to device.exe?
>>
>>Bryan
>>
>>
>>Soemin Tjong [MSFT] wrote:
>>
>>>You can use thread dump to see where it's hanging. I'm assuming if you
>>>remove your hardware the system boots up successfully.
>>>-- Soemin ---
>>>Windows CE CoreOS/Networking This posting is provided "AS IS" with no
>>>warranties, and confers no rights.
>>>
>
>
>