none
NDIS Miniport on top of WDM - assertions on Ndismindicatereceivenetbufferlist() RRS feed

  • Question

  • We have the NDIS miniport driver loaded on top of PDO created by a WDM driver.  When the NDISMIndicateReceiveNetBuffersList() function is directly called from the DPC that is initialized and scheduled by DPC and that executes code in NDIS miniport, we get assertion as below:

    Is it necessary that we have to complete it in NDIS context by doing it in NDIS Timer or NDIS Work queue item?

    Thanks

    Deva

    Assertion below:

    Debugging Details:

    ------------------

    PROCESS_NAME:  NTttcp.exe

    DPC_TIMEOUT_TYPE:  DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

    DPC_TIME_LIMIT: 784

    FAULTING_IP:

    nt!KeAccumulateTicks+57c

    fffff801`9327f2ec cd2c            int     2Ch

    ERROR_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

    EXCEPTION_CODE: (NTSTATUS) 0xc0000420 - An assertion failure has occurred.

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

    BUGCHECK_STR:  0x133

    CURRENT_IRQL:  d

    ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

    DPC_STACK_BASE:  FFFFF80192440FB0

    LAST_CONTROL_TRANSFER:  from fffff801932b3f11 to fffff8019327f2ec

    STACK_TEXT: 

    fffff801`9243f2b0 fffff801`932b3f11 : 00000000`0000c60e fffff801`93504180 fffff801`9243f460 fffff780`00000320 : nt!KeAccumulateTicks+0x57c

    fffff801`9243f330 fffff801`932b4d98 : ffffffff`ffd0a4c8 fffff801`939a2502 fffff801`9243f460 fffff880`014440df : nt!KeUpdateRunTime+0x51

    fffff801`9243f360 fffff801`93978eba : ffffffff`ffd0a4c8 fffff801`939a2502 fffffa80`155a7870 00000000`00000a7e : nt!KeUpdateTime+0x3f9

    fffff801`9243f550 fffff801`93282bca : 0000000e`dd944296 fffffa80`0c879000 fffff801`939a2580 000007a6`00000000 : hal!HalpTimerClockInterrupt+0x86

    fffff801`9243f580 fffff880`0153e32b : fffff880`015474c9 fffffa80`00000000 fffffa80`00000006 00000000`00002238 : nt!KiInterruptDispatchNoLockNoEtw+0x1aa

    fffff801`9243f718 fffff880`015474c9 : fffffa80`00000000 fffffa80`00000006 00000000`00002238 fffffa80`155a7ae0 : NETIO!memcpy+0xab

    fffff801`9243f720 fffff880`01a7d4a0 : fffff801`9243f888 fffff801`9243f850 fffff801`9243f870 fffff801`9243f838 : NETIO!RtlCopyMdlToMdlIndirect+0xd9

    fffff801`9243f7a0 fffff880`01ab1355 : fffffa80`0c836d80 fffffa80`1526ae68 fffffa80`1526ad10 fffffa80`1526ae68 : tcpip!TcpSatisfyReceiveRequests+0x110

    fffff801`9243f9b0 fffff880`01ab8c60 : 00000000`00000002 fffffa80`155a7870 fffffa80`11f21c70 fffff880`05a01170 : tcpip!TcpDeliverDataToClient+0xd5

    fffff801`9243fb20 fffff880`01aa7f98 : fffff801`9243fe70 00000000`00000000 00000006`00000014 00000000`00000014 : tcpip!TcpDeliverReceive+0xa0

    fffff801`9243fc10 fffff880`01abf1e7 : 00000013`00000001 00000000`00000000 fffffa80`06a5dcc0 fffffa80`15165e40 : tcpip!TcpTcbFastDatagram+0x248

    fffff801`9243fdf0 fffff880`01abf8f3 : fffff801`92440398 fffff801`92440358 fffff801`92440378 00000000`00000000 : tcpip!TcpTcbReceive+0x207

    fffff801`9243ff50 fffff880`01ab9d01 : fffffa80`0c87d032 fffffa80`06ba28c0 00000000`00000000 fffffa80`06982f40 : tcpip!TcpMatchReceive+0x1f3

    fffff801`924400d0 fffff880`01a9de5f : fffffa80`06a5dcc0 fffff801`924403d9 fffff801`92440388 fffffa80`0c618300 : tcpip!TcpPreValidatedReceive+0x381

    fffff801`924401b0 fffff880`01a9d2a8 : 00000000`00063e83 fffff801`932b3f11 ffff7714`62904962 fffff801`93504180 : tcpip!IppDeliverListToProtocol+0x4f

    fffff801`92440260 fffff880`01aa2cb1 : fffff880`01bb7b90 00000000`00000000 41414141`41414141 fffff801`92440378 : tcpip!IppProcessDeliverList+0x68

    fffff801`92440310 fffff880`01a9c4c4 : 00000000`00000001 fffffa80`06a4ea00 00000000`00000000 fffff880`01bb7b90 : tcpip!IppReceiveHeaderBatch+0x211

    fffff801`92440440 fffff880`01aa7b4c : fffffa80`07cd9910 00000000`00000000 fffff801`9320e001 fffff801`93504101 : tcpip!IpFlcReceivePackets+0x8d4

    fffff801`92440660 fffff880`01aa7429 : fffffa80`150aa501 fffff801`0000000a fffff880`01aa7470 fffff801`00000000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x29e

    fffff801`92440730 fffff801`932c9df5 : 00000000`00000000 fffff801`93506f00 00000000`00000000 00000000`0000003a : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x119

    fffff801`92440830 fffff801`932cad85 : fffff880`01aa7310 fffff801`924409a0 00000000`00000010 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xe5

    fffff801`92440930 fffff880`01aa75fe : fffff801`939a2580 41414141`41414141 00000000`0000226e fffff880`07e0f069 : nt!KeExpandKernelStackAndCalloutEx+0x25

    fffff801`92440970 fffff880`0143fe2e : 00000000`00000000 00000000`00000001 00000000`ffffffff 00000000`00000000 : tcpip!FlReceiveNetBufferListChain+0xae

    fffff801`924409f0 fffff880`0143f35d : fffffa80`0c832502 000005ea`00000000 fffffa80`00000000 00000000`0000000a : NDIS!ndisMIndicateNetBufferListsToOpen+0x373

    fffff801`92440a90 fffff880`0143fa05 : fffffa80`150ce1a0 00000000`00000000 00000000`00000001 fffffa80`1546f550 : NDIS!ndisInvokeNextReceiveHandler+0x25d

    fffff801`92440b60 fffff880`07e203e0 : fffff801`93506f00 fffff801`92440e00 fffffa80`066058e0 fffff801`92440f20 : NDIS!NdisMIndicateReceiveNetBufferLists+0xc5

    fffff801`92440be0 fffff880`07e1429d : fffffa80`078e01e8 fffff801`00000000 00000000`00000002 fffffa80`0000000a : liooctmp_W2012!ReceiveIndicate+0x260 [c:\users\rpm\documents\rpm\375\src\windows\liooctmp\octnic_rx.c @ 926]

    fffff801`92440c50 fffff880`07fdf3cc : fffffa80`078d8000 fffff801`00000000 fffffa80`1546f550 00000000`00000000 : liooctmp_W2012!OcteonInterruptDPC+0x1cd [c:\users\rpm\documents\rpm\375\src\windows\liooctmp\octnic_device.c @ 666]

    fffff801`92440cc0 fffff801`9327f498 : fffffa80`066058e0 0000057f`f80d8808 fffffa80`1546f550 00000000`00000000 : liooctvb!VbdPdoDpc+0x4c [c:\users\rpm\documents\rpm\375\src\windows\liooctvb\vbd_device.c @ 545]

    fffff801`92440d00 fffff801`932afd50 : fffff801`93504180 0000000e`607abb34 fffffa80`15117b00 00000000`00000025 : nt!KiExecuteAllDpcs+0x198

    fffff801`92440e40 fffff801`932af745 : 00000000`00000000 fffff801`93504180 fffff880`0fa7f050 000067ef`2aedbceb : nt!KiRetireDpcList+0xd0

    fffff801`92440fb0 fffff801`932af549 : 80000001`32f64963 fffff801`9334a398 00000000`00000000 00000000`00000000 : nt!KxRetireDpcList+0x5

    fffff880`0fa7efa0 fffff801`9334a398 : 00000000`00000000 00001f80`00000000 80000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue

    fffff880`0fa7efd0 fffff801`932d9276 : 00000580`00000000 00000000`00000001 fffffa80`155ab010 00000000`00000000 : nt!KiDpcInterrupt+0xc8

    fffff880`0fa7f160 fffff801`9347c763 : 00000000`00000000 fffff880`0fa7f239 00000000`00000000 fffffa80`0631db50 : nt!ExpFindAndRemoveTagBigPages+0x116

    fffff880`0fa7f1c0 fffff880`01ab3772 : fffffa80`154f5000 00000000`00000000 fffff880`00000000 fffff801`4d446354 : nt!ExFreePoolWithTag+0x753

    fffff880`0fa7f2a0 fffff880`01a55c41 : fffffa80`06a03180 fffff801`9334a398 fffff880`0fa7f7f0 fffffa80`15210b80 : tcpip!PplGenericFreeFunction+0x46

    fffff880`0fa7f2d0 fffff880`01539291 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : tcpip!TcpDelayedDeliveryCompletionRoutine+0x95

    fffff880`0fa7f310 fffff880`01a8447e : 00000000`00000000 00000000`00000000 fffffa80`08001700 fffff801`932d8446 : NETIO!NetioDereferenceNetBufferListChain+0x121

    fffff880`0fa7f3e0 fffff880`05d54305 : 00000000`00000000 fffffa80`1556a020 fffffa80`15359980 fffffa80`07f2d5d0 : tcpip!TcpTlProviderReleaseIndicationList+0x8e

    fffff880`0fa7f410 fffff880`05d924ef : 00000000`00000020 fffffa80`15721010 fffffa80`15457db8 00000000`00000000 : afd!AfdTLReleaseIndications+0x35

    fffff880`0fa7f460 fffff880`05d97cae : 00000000`00000000 fffffa80`07f2d5d0 fffff880`0fa7f5a0 fffffa80`07f2d5d0 : afd!AfdReturnBuffer+0xff

    fffff880`0fa7f4a0 fffff880`05d982f1 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`15721010 : afd!AfdBReceive+0x616

    fffff880`0fa7f6d0 fffff880`05d92320 : fffffa80`15457c10 fffffa80`15721010 00000580`00010000 fffff880`00000020 : afd!AfdReceive+0x301

    fffff880`0fa7f7e0 fffff801`936549e8 : 00000000`00000000 fffff880`0fa7f8c1 fffffa80`1509bf20 fffff880`0fa7f8a9 : afd!AfdDispatch+0xf0

    fffff880`0fa7f840 fffff801`935f9c13 : fffff880`05d76100 00000000`00000001 fffffa80`1509bf20 fffffa80`1509bf20 : nt!IopSynchronousServiceTail+0x158

    fffff880`0fa7f910 fffff801`93288053 : fffffa80`07cf5a40 00000000`000001b0 00000000`00000000 00000052`2d0880b0 : nt!NtReadFile+0x661

    fffff880`0fa7fa10 000007fc`33872c0a : 000007fc`30bfebb6 00000000`00000088 000007fc`321f26b4 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13

    00000052`2f77f6d8 000007fc`30bfebb6 : 00000000`00000088 000007fc`321f26b4 00000000`00000000 00000000`00000000 : 0x000007fc`33872c0a

    00000052`2f77f6e0 00000000`00000088 : 000007fc`321f26b4 00000000`00000000 00000000`00000000 00000052`2d0880b0 : 0x000007fc`30bfebb6

    00000052`2f77f6e8 000007fc`321f26b4 : 00000000`00000000 00000000`00000000 00000052`2d0880b0 00000052`2d8803b0 : 0x88

    00000052`2f77f6f0 00000000`00000000 : 00000000`00000000 00000052`2d0880b0 00000052`2d8803b0 00000052`00010000 : 0x000007fc`321f26b4

     

    STACK_COMMAND:  kb

    FOLLOWUP_IP:

    NETIO!memcpy+ab

    fffff880`0153e32b 4883c120        add     rcx,20h

    SYMBOL_STACK_INDEX:  5

    SYMBOL_NAME:  NETIO!memcpy+ab

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: NETIO

    IMAGE_NAME:  NETIO.SYS

    DEBUG_FLR_IMAGE_TIMESTAMP:  5010aa77

    BUCKET_ID_FUNC_OFFSET:  ab

    FAILURE_BUCKET_ID:  0x133_NETIO!memcpy

    BUCKET_ID:  0x133_NETIO!memcpy

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:0x133_netio!memcpy

    FAILURE_ID_HASH:  {917e6ce9-ee70-56c4-568f-37d2c398bb07}

    Followup: MachineOwner

    ---------

    0: kd> g

    Continuing an assertion failure can result in the debuggee

    being terminated (bugchecking for kernel debuggees).

    If you want to ignore this assertion, use 'ahi'.

    If you want to force continuation, use 'gh' or 'gn'.

    0: kd> gh

    Trying to disable physical device not enabled in this session.

    Tuesday, April 28, 2015 1:22 AM

All replies

  • Hi ,

    Thanks a lot.  

    We have modified the code to indicate the packets through work item by scheduling it from DPC that processes the packet. It works,. However, in HCK test for 1c_RSSBVT Test and 1c_RSSSendReceive , we get error stating that the packet with same header is being completed from different CPUs. This is because the work item scheduled from RSS CPU1 may get completed in CPU 3 and the next packet completed for the same RSS CPU1 be completed in CPU2, as the queued work item is arbitrary.

    Any ideas to avoid?

    Thanks

    Deva

    Tuesday, April 28, 2015 2:19 PM