none
NDIS 6.30/6.40 LWF & NDIS_MINIPORT_ATTRIBUTES_NO_PAUSE_ON_SUSPEND RRS feed

Answers

  • The real problem here is that you've stumbled across a bug in the documentation.  The documentation should not say "If the miniport has set this flag, then, ...".  Instead, the documentation should simply say "Avoid waiting for packets in your filter driver's NetEventSetPower handler."

    In practice, some drivers (mostly protocols, but some LWFs) have code that looks like this:

    switch (NetEventCode)
    {
        . . .
        case NetEventSetPower:
            while (My->NumberOfOutstandingPackets > 0)
                Sleep(100);
            break;
        . . .
    }
    
    Starting with NDIS 6.30, you can just delete that Sleep.  That's really all we're trying to say.  Nothing fancy.

    I'll get this documentation cleaned up.  Thanks for calling this out.

    • Marked as answer by Hao Zhuang Friday, February 7, 2014 5:13 AM
    Friday, February 7, 2014 2:37 AM

All replies

  • The real problem here is that you've stumbled across a bug in the documentation.  The documentation should not say "If the miniport has set this flag, then, ...".  Instead, the documentation should simply say "Avoid waiting for packets in your filter driver's NetEventSetPower handler."

    In practice, some drivers (mostly protocols, but some LWFs) have code that looks like this:

    switch (NetEventCode)
    {
        . . .
        case NetEventSetPower:
            while (My->NumberOfOutstandingPackets > 0)
                Sleep(100);
            break;
        . . .
    }
    
    Starting with NDIS 6.30, you can just delete that Sleep.  That's really all we're trying to say.  Nothing fancy.

    I'll get this documentation cleaned up.  Thanks for calling this out.

    • Marked as answer by Hao Zhuang Friday, February 7, 2014 5:13 AM
    Friday, February 7, 2014 2:37 AM
  • got it. thanks much for the quick reply, Jeffrey !
    Friday, February 7, 2014 5:13 AM
  • Are there any changes in NDIS 6.50 (Windows 10) ? Interestingly we've observed BugCheck 133 in our sleep stress with Win 10 TP Build 9926. The crash was not really in our LWF driver, but in the underlying Miniport Rt630x86 or Rt630x64, which appeared to be blocked by a SpinLock:

    1: kd> kn
     # ChildEBP RetAddr  
    00 b67135cc 815c48eb nt!KeBugCheckEx
    01 b6713638 814ff2f6 nt! ?? ::FNODOBFM::`string'+0x26151
    02 b67136fc 81423a70 nt!KeClockInterruptNotify+0x3b6
    03 b6713700 81432fc7 hal!HalpTimerClockIpiRoutineCommon+0x6
    04 b6713700 8150209f hal!HalpTimerClockIpiRoutine+0x1f7
    05 b6713810 8153f1da nt!KxWaitForSpinLockAndAcquire+0x1f
    06 b671381c 96d10f2f nt!KfAcquireSpinLock+0x2a
    07 b671385c 96d04431 Rt630x86!MiniportSendNetBufferList+0x42f
    08 b6713888 96d0409c Rt630x86!MPSendNetBufferListsNPQ+0x16f
    09 b67138bc 85a0629d Rt630x86!MPSendNetBufferLists+0x9e
    0a b6713914 85a0600a ndis!ndisMSendNBLToMiniport+0x21d
    0b b6713970 85a065ad ndis!ndisInvokeNextSendHandler+0x22
    0c b67139b0 85db153d ndis!NdisFSendNetBufferLists+0x27d
    0d b6713a48 85a049ad wfplwfs!LwfLowerSendNetBufferLists+0x12d
    0e b6713a90 85a03e37 ndis!ndisCallSendHandler+0x2d
    0f b6713ab4 8150d8f5 ndis!ndisDataPathExpandStackCallback+0x27
    10 b6713b14 8150d7cf nt!KeExpandKernelStackAndCalloutInternal+0x115
    11 b6713b2c 85a0bbed nt!KeExpandKernelStackAndCalloutEx+0x1f
    12 b6713b44 85a06064 ndis!ndisExpandStack+0x11
    13 b6713b94 85a065ad ndis!ndisInvokeNextSendHandler+0x7c
    14 b6713bd4 82268607 ndis!NdisFSendNetBufferLists+0x27d
    

    The Miniport was in NetDeviceStateD3 where we were calling NdisFSendNetBufferLists() to pass in the NBL. My suspicion was that the power state was probably what was blocking the SpinLock but not sure since we don't know the Rt630 code. Both the Miniport and the LWF stack were in RUNNING state. So I'm wondering if the behavior of the old NDIS has come back to 6.50 and we need to wait for NBLs to be returned/completed when receiving NetEventSetPower ?

    Thank you very much !

    - hao

    Wednesday, March 25, 2015 12:40 AM
  • We've not (intentionally) changed any of this behavior in Windows 10.  This would need to get investigated as any bug.  Certainly the miniport is looking suspicious here, since he shouldn't be forever spinning on a spinlock acquire. But that doesn't prove guilt; it could be some complicated cause-and-effect chain.
    Wednesday, March 25, 2015 3:07 AM