NDIS6 Miniport not unloaded

Hi everyone:

I am running an ndis 6 + KMDF Ethernet miniport driver. The miniport
controls a USB NIC .
I bridged miniport through bridgeMP to another Ethernet NIC.

When I am suprisingly remove my device I my MiniportPause is not
called and the miniport remains active(checkforhang is keep being
called).

When I do !stacks 2 ndis I see the following:

nt!KiSwapThread+0x36d:
nt!KeWaitForSingleObject+0x414
ndis!NdisWaitEvent+0x55
bridge+0xb1d7
bridge+0xb221
bridge+0x1a92
ndis!ndisUnbindProtocol+0x24b
ndis!ndisPnPNotifyAllTransports
+0x1c8
ndis!ndisCloseMiniportBindings
+0x17a
ndis!ndisPnPRemoveDevice+0x1ab
ndis!ndisPnPDispatch+0x85e
nt!IovCallDriver+0x252
nt!IofCallDriver+0x1b
nt!ViFilterDispatchPnp+0x120
nt!IovCallDriver+0x252
nt!IofCallDriver+0x1b
nt!IopSynchronousCall+0xce
nt!IopRemoveDevice+0xd5
nt!
PnpSurpriseRemoveLockedDeviceNode+0xbd
nt!PnpDeleteLockedDeviceNode
+0x1f
nt!PnpDeleteLockedDeviceNodes
+0x4c
nt!
PnpProcessQueryRemoveAndEject+0x572
nt!PnpProcessTargetDeviceEvent
+0x38
nt!PnpDeviceEventWorker+0x201
nt!ExpWorkerThread+0xfd
nt!PspSystemThreadStartup+0x9d
nt!KiThreadStartup+0x16


It seems that the bridge is hang on some Event and due to that the
miniport is unloaded.

Does anyone has any idea how can I further debug it?

Thanks
Miki

Calvin
Wed Apr 18 12:13:04 CDT 2007

Look at all ndis opens to see if there is outstanding refs. It won't unbind
until all tx packets and OIDs are cleared.

--
Calvin Guan
Broadcom Corporation
Connecting Everything(r)

"miki" <michael.waksman@gmail.com> wrote in message
news:1176881714.064876.82430@b58g2000hsg.googlegroups.com...
> Hi everyone:
>
> I am running an ndis 6 + KMDF Ethernet miniport driver. The miniport
> controls a USB NIC .
> I bridged miniport through bridgeMP to another Ethernet NIC.
>
> When I am suprisingly remove my device I my MiniportPause is not
> called and the miniport remains active(checkforhang is keep being
> called).
>
> When I do !stacks 2 ndis I see the following:
>
> nt!KiSwapThread+0x36d:
> nt!KeWaitForSingleObject+0x414
> ndis!NdisWaitEvent+0x55
> bridge+0xb1d7
> bridge+0xb221
> bridge+0x1a92
> ndis!ndisUnbindProtocol+0x24b
> ndis!ndisPnPNotifyAllTransports
> +0x1c8
> ndis!ndisCloseMiniportBindings
> +0x17a
> ndis!ndisPnPRemoveDevice+0x1ab
> ndis!ndisPnPDispatch+0x85e
> nt!IovCallDriver+0x252
> nt!IofCallDriver+0x1b
> nt!ViFilterDispatchPnp+0x120
> nt!IovCallDriver+0x252
> nt!IofCallDriver+0x1b
> nt!IopSynchronousCall+0xce
> nt!IopRemoveDevice+0xd5
> nt!
> PnpSurpriseRemoveLockedDeviceNode+0xbd
> nt!PnpDeleteLockedDeviceNode
> +0x1f
> nt!PnpDeleteLockedDeviceNodes
> +0x4c
> nt!
> PnpProcessQueryRemoveAndEject+0x572
> nt!PnpProcessTargetDeviceEvent
> +0x38
> nt!PnpDeviceEventWorker+0x201
> nt!ExpWorkerThread+0xfd
> nt!PspSystemThreadStartup+0x9d
> nt!KiThreadStartup+0x16
>
>
> It seems that the bridge is hang on some Event and due to that the
> miniport is unloaded.
>
> Does anyone has any idea how can I further debug it?
>
> Thanks
> Miki
>

miki
Thu Apr 19 02:18:30 CDT 2007

On Apr 18, 8:13 pm, "Calvin Guan" <h...@nospam.broadcom.com> wrote:
> Look at all ndis opens to see if there is outstanding refs. It won't unbind
> until all tx packets and OIDs are cleared.
>
> --
> Calvin Guan
> Broadcom Corporation
> Connecting Everything(r)
>
> "miki" <michael.waks...@gmail.com> wrote in message
>
> news:1176881714.064876.82430@b58g2000hsg.googlegroups.com...
>
>
>
> > Hi everyone:
>
> > I am running an ndis 6 + KMDF Ethernet miniport driver. The miniport
> > controls a USB NIC .
> > I bridged miniport through bridgeMP to another Ethernet NIC.
>
> > When I am suprisingly remove my device I my MiniportPause is not
> > called and the miniport remains active(checkforhang is keep being
> > called).
>
> > When I do !stacks 2 ndis I see the following:
>
> > nt!KiSwapThread+0x36d:
> > nt!KeWaitForSingleObject+0x414
> > ndis!NdisWaitEvent+0x55
> > bridge+0xb1d7
> > bridge+0xb221
> > bridge+0x1a92
> > ndis!ndisUnbindProtocol+0x24b
> > ndis!ndisPnPNotifyAllTransports
> > +0x1c8
> > ndis!ndisCloseMiniportBindings
> > +0x17a
> > ndis!ndisPnPRemoveDevice+0x1ab
> > ndis!ndisPnPDispatch+0x85e
> > nt!IovCallDriver+0x252
> > nt!IofCallDriver+0x1b
> > nt!ViFilterDispatchPnp+0x120
> > nt!IovCallDriver+0x252
> > nt!IofCallDriver+0x1b
> > nt!IopSynchronousCall+0xce
> > nt!IopRemoveDevice+0xd5
> > nt!
> > PnpSurpriseRemoveLockedDeviceNode+0xbd
> > nt!PnpDeleteLockedDeviceNode
> > +0x1f
> > nt!PnpDeleteLockedDeviceNodes
> > +0x4c
> > nt!
> > PnpProcessQueryRemoveAndEject+0x572
> > nt!PnpProcessTargetDeviceEvent
> > +0x38
> > nt!PnpDeviceEventWorker+0x201
> > nt!ExpWorkerThread+0xfd
> > nt!PspSystemThreadStartup+0x9d
> > nt!KiThreadStartup+0x16
>
> > It seems that the bridge is hang on some Event and due to that the
> > miniport is unloaded.
>
> > Does anyone has any idea how can I further debug it?
>
> > Thanks
> > Miki- Hide quoted text -
>
> - Show quoted text -

Thanks
I found the problem,
I thought that when device is surprised removed NDIS will call my
MiniportPause even though there are pending sends requests. It turns
out that I need to complete those requests if I want ndis to call the
miniportpause.

Miki

Alireza
Thu Apr 19 03:33:32 CDT 2007

I found the problem,
> I thought that when device is surprised removed NDIS will call my
> MiniportPause even though there are pending sends requests. It turns
> out that I need to complete those requests if I want ndis to call the
> miniportpause.

Well,.. not quite. Usually we pause the stack from top (protocols) to down
(miniports). So we first ask protocols to pause and -they are required to
wait for all outstanding sends to complete- before completing the pause.
Thus in most cases NDIS does not pause the miniport until all bound
protocols have been paused. (although in this case since Bridge is an NDIS
5.x driver, we unbind the protocol instead of pausing it). So your
conclusion that NDIS does not call MiniportPause unless it has completed all
the send requests is not accurate.

I mention this because there could be cases that we call MiniportPause even
if there are outstanding send requests. In order to complete a pause
request, drivers are required to wait for completion for what they initiated
themselves (receive indications for miniports and send requests for
protocols) and not something initiated by other components.

-thanks, ali

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


"miki" <michael.waksman@gmail.com> wrote in message
news:1176967110.120103.225760@d57g2000hsg.googlegroups.com...
> On Apr 18, 8:13 pm, "Calvin Guan" <h...@nospam.broadcom.com> wrote:
>> Look at all ndis opens to see if there is outstanding refs. It won't
>> unbind
>> until all tx packets and OIDs are cleared.
>>
>> --
>> Calvin Guan
>> Broadcom Corporation
>> Connecting Everything(r)
>>
>> "miki" <michael.waks...@gmail.com> wrote in message
>>
>> news:1176881714.064876.82430@b58g2000hsg.googlegroups.com...
>>
>>
>>
>> > Hi everyone:
>>
>> > I am running an ndis 6 + KMDF Ethernet miniport driver. The miniport
>> > controls a USB NIC .
>> > I bridged miniport through bridgeMP to another Ethernet NIC.
>>
>> > When I am suprisingly remove my device I my MiniportPause is not
>> > called and the miniport remains active(checkforhang is keep being
>> > called).
>>
>> > When I do !stacks 2 ndis I see the following:
>>
>> > nt!KiSwapThread+0x36d:
>> > nt!KeWaitForSingleObject+0x414
>> > ndis!NdisWaitEvent+0x55
>> > bridge+0xb1d7
>> > bridge+0xb221
>> > bridge+0x1a92
>> > ndis!ndisUnbindProtocol+0x24b
>> > ndis!ndisPnPNotifyAllTransports
>> > +0x1c8
>> > ndis!ndisCloseMiniportBindings
>> > +0x17a
>> > ndis!ndisPnPRemoveDevice+0x1ab
>> > ndis!ndisPnPDispatch+0x85e
>> > nt!IovCallDriver+0x252
>> > nt!IofCallDriver+0x1b
>> > nt!ViFilterDispatchPnp+0x120
>> > nt!IovCallDriver+0x252
>> > nt!IofCallDriver+0x1b
>> > nt!IopSynchronousCall+0xce
>> > nt!IopRemoveDevice+0xd5
>> > nt!
>> > PnpSurpriseRemoveLockedDeviceNode+0xbd
>> > nt!PnpDeleteLockedDeviceNode
>> > +0x1f
>> > nt!PnpDeleteLockedDeviceNodes
>> > +0x4c
>> > nt!
>> > PnpProcessQueryRemoveAndEject+0x572
>> > nt!PnpProcessTargetDeviceEvent
>> > +0x38
>> > nt!PnpDeviceEventWorker+0x201
>> > nt!ExpWorkerThread+0xfd
>> > nt!PspSystemThreadStartup+0x9d
>> > nt!KiThreadStartup+0x16
>>
>> > It seems that the bridge is hang on some Event and due to that the
>> > miniport is unloaded.
>>
>> > Does anyone has any idea how can I further debug it?
>>
>> > Thanks
>> > Miki- Hide quoted text -
>>
>> - Show quoted text -
>
> Thanks
> I found the problem,
> I thought that when device is surprised removed NDIS will call my
> MiniportPause even though there are pending sends requests. It turns
> out that I need to complete those requests if I want ndis to call the
> miniportpause.
>
> Miki
>
>
>
>

miki
Sun Apr 29 08:13:09 CDT 2007

On Apr 19, 11:33 am, "Alireza Dabagh [MS]" <a...@online.microsoft.com>
wrote:
> I found the problem,
>
> > I thought that when device is surprised removed NDIS will call my
> > MiniportPause even though there are pending sends requests. It turns
> > out that I need to complete those requests if I want ndis to call the
> > miniportpause.
>
> Well,.. not quite. Usually we pause the stack from top (protocols) to down
> (miniports). So we first ask protocols to pause and -they are required to
> wait for all outstanding sends to complete- before completing the pause.
> Thus in most cases NDIS does not pause the miniport until all bound
> protocols have been paused. (although in this case since Bridge is an NDIS
> 5.x driver, we unbind the protocol instead of pausing it). So your
> conclusion that NDIS does not call MiniportPause unless it has completed all
> the send requests is not accurate.
>
> I mention this because there could be cases that we call MiniportPause even
> if there are outstanding send requests. In order to complete a pause
> request, drivers are required to wait for completion for what they initiated
> themselves (receive indications for miniports and send requests for
> protocols) and not something initiated by other components.
>
> -thanks, ali
>
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "miki" <michael.waks...@gmail.com> wrote in message
>
> news:1176967110.120103.225760@d57g2000hsg.googlegroups.com...
>
>
>
> > On Apr 18, 8:13 pm, "Calvin Guan" <h...@nospam.broadcom.com> wrote:
> >> Look at all ndis opens to see if there is outstanding refs. It won't
> >> unbind
> >> until all tx packets and OIDs are cleared.
>
> >> --
> >> Calvin Guan
> >> Broadcom Corporation
> >> Connecting Everything(r)
>
> >> "miki" <michael.waks...@gmail.com> wrote in message
>
> >>news:1176881714.064876.82430@b58g2000hsg.googlegroups.com...
>
> >> > Hi everyone:
>
> >> > I am running an ndis 6 + KMDF Ethernet miniport driver. The miniport
> >> > controls a USB NIC .
> >> > I bridged miniport through bridgeMP to another Ethernet NIC.
>
> >> > When I am suprisingly remove my device I my MiniportPause is not
> >> > called and the miniport remains active(checkforhang is keep being
> >> > called).
>
> >> > When I do !stacks 2 ndis I see the following:
>
> >> > nt!KiSwapThread+0x36d:
> >> > nt!KeWaitForSingleObject+0x414
> >> > ndis!NdisWaitEvent+0x55
> >> > bridge+0xb1d7
> >> > bridge+0xb221
> >> > bridge+0x1a92
> >> > ndis!ndisUnbindProtocol+0x24b
> >> > ndis!ndisPnPNotifyAllTransports
> >> > +0x1c8
> >> > ndis!ndisCloseMiniportBindings
> >> > +0x17a
> >> > ndis!ndisPnPRemoveDevice+0x1ab
> >> > ndis!ndisPnPDispatch+0x85e
> >> > nt!IovCallDriver+0x252
> >> > nt!IofCallDriver+0x1b
> >> > nt!ViFilterDispatchPnp+0x120
> >> > nt!IovCallDriver+0x252
> >> > nt!IofCallDriver+0x1b
> >> > nt!IopSynchronousCall+0xce
> >> > nt!IopRemoveDevice+0xd5
> >> > nt!
> >> > PnpSurpriseRemoveLockedDeviceNode+0xbd
> >> > nt!PnpDeleteLockedDeviceNode
> >> > +0x1f
> >> > nt!PnpDeleteLockedDeviceNodes
> >> > +0x4c
> >> > nt!
> >> > PnpProcessQueryRemoveAndEject+0x572
> >> > nt!PnpProcessTargetDeviceEvent
> >> > +0x38
> >> > nt!PnpDeviceEventWorker+0x201
> >> > nt!ExpWorkerThread+0xfd
> >> > nt!PspSystemThreadStartup+0x9d
> >> > nt!KiThreadStartup+0x16
>
> >> > It seems that the bridge is hang on some Event and due to that the
> >> > miniport is unloaded.
>
> >> > Does anyone has any idea how can I further debug it?
>
> >> > Thanks
> >> > Miki- Hide quoted text -
>
> >> - Show quoted text -
>
> > Thanks
> > I found the problem,
> > I thought that when device is surprised removed NDIS will call my
> > MiniportPause even though there are pending sends requests. It turns
> > out that I need to complete those requests if I want ndis to call the
> > miniportpause.
>
> > Miki- Hide quoted text -
>
> - Show quoted text -

Hi Ali,

I am sorry but I think I don't understand the meaning of your answer:

"Thus in most cases NDIS does not pause the miniport until all bound
protocols have been paused ... In order to complete a pause
request, drivers are required to wait for completion for what they
initiated
themselves (receive indications for miniports and send requests for
protocols) and not something initiated by other components."

According to what you wrote I understand that
MiniportPause will not be called until upper protocols are paused, and
upper protocols will not be paused
until their sent requests will be completed.
So when the device is surprised removed who should complete those
requests which the protocols are waiting for?
Isn't that the miniport's role?
It seems to me that if the miniport will not do that we will be in a
dead lock - protocols will not be paused
because of those sent will never be completed (the device is removed).

What do I miss?

Thanks
Miki