none
Minport Driver stuck after return from MiniportHalt RRS feed

  • Question

  • Hi,

    I am debugging an NDIS Miniport driver.

    During disable process of said driver, the Device Manager gets stuck for 30 sec. after the driver finishes MiniportHalt and before MiniportUnload is called (I got this from DbgView which I am using to gather the driver logs).

    What could be the reason for this?

     Thanks,

                  Uriel

    Monday, December 23, 2013 2:19 PM

All replies

  • A typical reason for a delay like this in any sort of driver not just NDIS, is that there is outstanding I/O's.   Since MiniportHalt is supposed to release any receive buffers, you may need to look at whether there was a transmit outstanding at the time of the halt.  Also, check your halt routine to be sure it is doing all the cleanup it can of the driver, i.e. review http://msdn.microsoft.com/en-us/library/windows/hardware/ff549451(v=vs.85).aspx to be sure you are doing everything it reccomends.

    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, December 23, 2013 3:11 PM
  • Check if there are any outstanding refcounts on the miniport.  In the kernel debugger, use "!ndiskd.miniport" to find your miniport, and look for the "References" line.  If it's non-zero, then the miniport is being pinned by a reference.

    Using Windows 8 or later, you can actually figure out the specific source of that refcount.  Use "!ndiskd.miniport -ref <yourminiporthandle>".  !ndiskd will print out a table of all refcounts.  Use "!ndiskd.help <refcountname>" to get a short explanation of what that refcount is from.

    Monday, December 23, 2013 8:51 PM
  • Hi Jeffrey,

    Thank you for your answer. I did what you suggested, so maybe you can give me a little bit of additional help with the results. I see that I have 2 references from PNP:

    MINIPORT REFERENCE COUNT


        Tag                                    Number of references                 
        PNP_INITIALIZED                        1
        PNP_REMOVING                           1

    The help on this 2 references is not very informative:

    CONSTANT

        PNP_INITIALIZED


    DESCRIPTION

        This reference is acquired during initialization (just before
        MiniportInitialize or MiniportInitializeEx is invoked), and released during
        halt (just after MiniportHalt or MiniportHaltEx is invoked).

     

    and

    CONSTANT

        PNP_REMOVING


    DESCRIPTION

        NDIS is in the process of removing this miniport (IRP_MN_REMOVE_DEVICE).

    Is there something additional that I can learn from the BSOD dump?

    TIA,

               Uriel

    Tuesday, December 24, 2013 8:23 AM
  • The "PNP_REMOVING" count is held temporarily while a thread in NDIS does some cleanup and calls your MiniportHaltEx handler. If PNP_REMOVING is still there, that means the NDIS cleanup thread is still there.  See if you can locate the thread using "!stacks 2 ndis!".  From the callstack, we should be able to determine what that thread is stuck on.
    Friday, December 27, 2013 7:27 PM
  • Hi Jeffrey,

    Thank you so much for all your help.

    I got the stacks as you suggested. The 1st one is, of course, the one that calls MiniportHalt and caused the BSOD that I issued from there:

    4.000050  848d0d40 0000001 RUNNING    nt!KeBugCheckEx
                                            NETwen02!miniportHalt+0x24c
                                            NETwen02!oscMiniportHalt+0x68
                                            ndis!ndisMInvokeHalt+0x35
                                            ndis!ndisMCommonHaltMiniport+0x3f0
                                            ndis!ndisMHaltMiniport+0x46
                                            ndis!ndisPnPRemoveDevice+0x1f6
                                            ndis!ndisPnPRemoveDeviceEx+0x67
                                            ndis!ndisPnPIrpRemoveDevice+0xa6
                                            ndis!ndisPnPDispatch+0x25a3f
                                            nt!IofCallDriver+0x3f
                                            Wdf01000!FxPkgFdo::ProcessRemoveDeviceOverload+0x53
                                            Wdf01000!FxPkgPnp::_PnpRemoveDevice+0xcd
                                            Wdf01000!FxPkgPnp::Dispatch+0x1ad
                                            Wdf01000!FxDevice::Dispatch+0x155
                                            Wdf01000!FxDevice::DispatchWithLock+0x77
                                            nt!IofCallDriver+0x3f
                                            nt!IopSynchronousCall+0x9c
                                            nt!IopRemoveDevice+0xc3
                                            nt!PnpRemoveLockedDeviceNode+0x1b3
                                            nt!PnpDeleteLockedDeviceNode+0x65
                                            nt!PnpDeleteLockedDeviceNodes+0x66
                                            nt! ?? ::NNGAKEGL::`string'+0x220c6
                                            nt!PnpProcessTargetDeviceEvent+0x75
                                            nt!PnpDeviceEventWorker+0x241
                                            nt!ExpWorkerThread+0x111
                                            nt!PspSystemThreadStartup+0x4a
                                            nt!KiThreadStartup+0x19

    The other ones seem to be just from worker threads, but I couldn't get nothing from their stacks:

       4.0000e0  8535fd40 0007dec Blocked    nt!KiSwapContext+0x19
                                            nt!KiCommitThreadWait+0x280
                                            nt!KeWaitForSingleObject+0x269
                                            ndis!ndisThreadPoolTimerHandler+0x19
                                            nt!PspSystemThreadStartup+0x4a
                                            nt!KiThreadStartup+0x19

       4.0000e4  8535fa00 0000026 Blocked    nt!KiSwapContext+0x19
                                            nt!KiCommitThreadWait+0x280
                                            nt!KeRemoveQueueEx+0x28b
                                            nt!KeRemoveQueue+0x1c
                                            ndis!ndisWorkerThread+0x46
                                            nt!PspSystemThreadStartup+0x4a
                                            nt!KiThreadStartup+0x19

       4.000184  86417680 0000026 Blocked    nt!KiSwapContext+0x19
                                            nt!KiCommitThreadWait+0x280
                                            nt!KeRemoveQueueEx+0x28b
                                            nt!KeRemoveQueue+0x1c
                                            ndis!ndisWorkerThread+0x46
                                            nt!PspSystemThreadStartup+0x4a
                                            nt!KiThreadStartup+0x19

       4.000188  864e5d40 0000015 Blocked    nt!KiSwapContext+0x19
                                            nt!KiCommitThreadWait+0x280
                                            nt!KeRemoveQueueEx+0x28b
                                            nt!KeRemoveQueue+0x1c
                                            ndis!ndisWorkerThread+0x46
                                            nt!PspSystemThreadStartup+0x4a
                                            nt!KiThreadStartup+0x19

    Can you get some additional info from these stacks?

    TIA,

            Uriel

    Sunday, December 29, 2013 9:18 AM
  • Well it looks like your MiniportHaltEx routine is still in-progress.  NDIS called into your miniport's MiniportHaltEx routine through ndis!ndisMInvokeHalt.  Halt can't complete until your MiniportHaltEx routine returns.
    Monday, December 30, 2013 8:04 PM
  • Hi Jeffrey,

    You are right since I issued the BSOD at the end of my MiniportHalt handler routine.

    However, I just tried doing it at the start of my MiniportDriverUnload routine. Once I do that and use "!ndiskd.miniports" on WinDbg, I don't see my Miniport in the list of drivers.

    Any idea what else I can do to resolve this issue?

    TIA,

              Uriel

    Tuesday, December 31, 2013 8:08 AM