matt_sykes
Tue Feb 06 03:50:23 CST 2007
On 5 Feb, 23:49, "Thomas F. Divine" <tdivine@NOpcausaSPAM> wrote:
> If the behavior you are seeing is correct, then you couldn't do a safe
> remove on any USB-Ethernet device. Right?
>
> I don't think that's the case.
>
> Thomas F. Divine
>
> "matt_sykes" <zzeb...@hotmail.com> wrote in message
>
> news:1170662411.996743.189100@a34g2000cwb.googlegroups.com...
>
>
>
> > On 4 Feb, 03:17, Anton Bassov <AntonBas...@discussions.microsoft.com>
> > wrote:
> >> What makes you believe that the culprit is TCPIP.SYS?????
>
> >> Even if it has outstanding sends, it does not mean that it has to fail
> >> NetEventQueryRemoveDevice query - instead, it can simply stop sending new
> >> packets, return NDIS_STATUS_PENDING() from ProtocolPnPEvent() handler,
> >> and
> >> call NdisCompletePnPEven() after all packets that have been fowarded to
> >> miniport get returned.......
>
> > And those packets dont get returned because the protocl doesnt call
> > cancel packets on the miniport driver.
>
> >> Let's face it - if the culprit was TCPIP.SYS or any other system-provided
> >> driver, this bug would have been discovered long, long ago.
>
> > Sure, along with the two other bugs we discovered on XP.
>
> >> However, if I got
> >> it right, this behaviour has been detected only on your test machine.
>
> >> What about some poorly written third-party NDIS IM in between TCPIP.SYS
> >> and
> >> miniport driver???? What about some poorly written third-party protocol
> >> driver that is bound to NIC???
>
> > Clean machine, MSDN install of XP, no other protocols bound to the Nic
> > than IP4.
>
> >>What if miniport driver in itself is poorly
> >> written, in the first place????
>
> > I wrote it myself. Its not poorly written. In fact, surprise remove
> > does work, because the syatem calls the miniports surprise remove
> > handler and that does return all unsent packets to Ndis.
>
> >> Has it ever occured to you to think this
> >> way???
>
> >> All your diagnostic observations stand as following:
>
> >> [begin quote]
>
> >> .... the device doesnt get unloaded, hanging the PnP manager with device
> >> manager showing the device stil present. (You can tell the PnP manager
> >> is
> >> hung because an
> >> inserted USB stick isnt recognised).
>
> >> [end quote]
>
> > XP has a 'single threaded' PnP manager as you know (Vista hasnt).
> > When you insert a device on XP like a USB stick and it isnt recognised
> > you can bet the PnP manager is in some intermediate state dealing with
> > removal of another device.
>
> >> Even if device doesnt get unloaded, it does not necessarily mean that
> >> MiniportHalt() never got invoked - for example,
>
> > Yes it does, I had it running a debug version with tracing.
> > MiniportHalt just didnt get called.
>
> > >it may get invoked but never
> >> return because of an infinite loop if miniport driver is poorly written.
> >> However, even if MiniportHalt() does not get invoked, it still does not
> >> necessarily mean that it happens because of failed
> >> NetEventQueryRemoveDevice
> >> query - after all, MSDN quotation that you have provided stronly suggests
> >> the
> >> possibility of successfull completion of IRP_MN_QUERY_STOP_DEVICE request
> >> despite NetEventQueryRemoveDevice query's failure.
>
> > A 'possibility' is not a 'will do' and in this case, it doesnt.
>
> >> In any case, even if the
> >> whole thing is all about NetEventQueryRemoveDevice query's failure, it
> >> still
> >> does not mean that it is TCPIP.SYS and not some other driver who failed
> >> it.....
>
> >> In other words, you have to investigate the problem more thoroughly.....
>
> >> Anton Bassov
>
> > Like I wrote, I also have an IOCTL interface to the Ndis driver, which
> > has a DISCONNECT method. When called, this flushes the send queue.
>
> > As soon as this happens, MiniportHalt() gets called.
>
> > So it is clear that outstanding sends cause the MiniportHalt() not to
> > get called, and because cancel packets isnt being called there is no
> > way for the Miniport driver to return them.
>
> > This is either a bug in TcpIp.sys or its a bug in the Ndis
> > framework.
>
> > Either protocols have to call cancel packets on query remove, or
> > Miniport drivers need a query remove sending to them by the frame
> > work.
>
> >> "matt_sykes" wrote:
> >> > So, set up an FTP upload, then do a safe remove.
>
> >> > Result, underlying USB bus driver gets the query remove and retuend
> >> > INVALID_DEVICE_STATE for the Ndis miniport driver writes, but the
> >> > miniport drivers Halt routine doesnt get called and the device doesnt
> >> > get unloaded, hanging the PnP manager with device manager showing the
> >> > device stil present. (You can tell the PnP manager is hung because an
> >> > inserted USB stick isnt recognised).
>
> >> > Via an applet and an IOCTL interface, the Ndis driver can be told to
> >> > stop, whereupon it cancels all its send packets with a status of
> >> > NDIS_STATUS_MEDIA_DISCONNECT. After this has hapened the miniport
> >> > halt function does get called.
>
> >> > So, from looking at the DDK:
>
> >> > The PnP Manager issues an IRP_MN_QUERY_STOP_DEVICE request.
>
> >> > On receiving this IRP, NDIS calls the ProtocolPnPEvent function of all
> >> > protocol drivers that are bound to the adapter. In this call, NDIS
> >> > specifies an event code of NetEventQueryRemoveDevice.
>
> >> > If a protocol driver fails the NetEventQueryRemoveDevice event by
> >> > returning a failure code from ProtocolPnPEvent, the PnP Manager might
> >> > ignore the failure and subsequently succeed the
> >> > IRP_MN_QUERY_STOP_DEVICE request
> >> > (but it looks like it doesnt)
> >> > ....
> >> > After all protocol drivers are unbound from the NIC, NDIS calls the
> >> > miniport driver's MiniportHalt function.
>
> >> > So, it looks like tcpip.sys is failing the NetEventQueryRemoveDevice
> >> > because it still has outstanding sends with the Nic driver, but the
> >> > Nic driver cant complete them till its Halt function is called.
>
> >> > Chicken...egg...chicken...egg.
>
> >> > This is on XP SP2.
>
> >> > I wonder if its 'fixed in Vista', like selective suspend ; )- Hide
> >> > quoted text -
>
> >> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Hi Thomas.
I saw what I saw. Untill my applet does calls a stop IOCTL on the
Ndis driver, which flushes the queue, the Ndis drivers halt doesnt get
called.
Either all protocols must call cancel packets on query remove, or the
Ndis frameworks needs to send a query remove to the Miniport driver.
ATB