The device gets stuck when running "Surprise Removal" test with "Run Tests with I/O" option selected in a NDIS 6.2 WWAN driver for DTM.


·         When Run Tests with I/O option is disabled, the test passes.


·         This issue can be specific to a Win 7 NDIS 6.2 WWAN driver only.


·         Compiling the same driver as NDIS 6.0 or NDIS 5.1 does not reproduce the issue.


·         We may not see any pending IRPs or reference in the miniport.


·         We may get the UserModeOpenReferences > 0.


·         We have confirmed no User mode application is doing network communication still above symptoms shows up.


·         We may get the following callstack in the dump.


 


                   nt!KiSwapContext+0x26


                   nt!KiSwapThread+0x266


                   nt!KiCommitThreadWait+0x1df


                   nt!KeWaitForSingleObject+0x393


                   ndis!ndisPnPRemoveDeviceEx+0xe3


                   ndis!ndisPnPDispatch+0x814


                   nt!IovCallDriver+0x258


                   nt!IofCallDriver+0x1b


                   nt!ViFilterDispatchPnp+0x120


                   nt!IovCallDriver+0x258


                   nt!IofCallDriver+0x1b


                   pnpfiltr!FilterPassIrp+0x2d


                   pnpfiltr!FilterSurpriseRemove+0x69


                   pnpfiltr!FilterDispatchPnp+0xcd


                   nt!IovCallDriver+0x258


                   nt!IofCallDriver+0x1b


                   nt!IopSynchronousCall+0xc2


                   nt!IopRemoveDevice+0xd4


                   nt!PnpSurpriseRemoveLockedDeviceNode+0x101


                   nt!PnpDeleteLockedDeviceNode+0x21


                   nt!PnpDeleteLockedDeviceNodes+0x4c


                   nt!PnpProcessQueryRemoveAndEject+0x586


                   nt!PnpProcessTargetDeviceEvent+0x38


                   nt!PnpDeviceEventWorker+0x216


                   nt!ExpWorkerThread+0x10d


                   nt!PspSystemThreadStartup+0x9e


                   nt!KiThreadStartup+0x19


Potential root cause. ( not verified )

·         In ndisPnPRemoveDevice function we clean up a bunch of state (notify WMI, Close bindings, detach filters...). 


·         We call Miniport->DriverHandle->RemoveDeviceHandler if it is declared in ndisPnPRemoveDevice.


·         So if Miniport->DriverHandle->RemoveDeviceHandler is NULL this issue may happen as in that case for a SurpriseRemove, we will NOT call driver HaltHandler.


 


Skip to main content