none
NDIS dll crash during TCP IP communication RRS feed

  • Question

  • Hi,

    I am getting crash in ndis.dll while working with sockets.

    platform: WEC 2013 Update 49(December 2017) , IMX6 Board

    scenario: i have 3 cmdline apps,  [ (1)main_server ->(2)(Bridge_client+ Bridge_server) ] -> (3)Main_Client

    main_server sends data(reads data content from a file) to  bridge_client  via localhost address(127.0.0.1) and port 27015,  bridge_client just forwards the data to main_client through LAN, without any intermediate delay / processing 

    ( ip address is provided to Main_client through cmdline,port 27018).

    main_server and (bridge_client + bridge_server) are running on board, whereas main_client is PC(Windows 7).

    There are no threads within all three apps.

    Also if i add some logs into my clientserver(bridge_client + bridge_server), crash frequency is reduced significantly .

    Crash happens for both synchronous and asynchronous type implementation, i.e. for synchronous we wait for predefined ACK string, from main client and bridge(client+server) before sending next buffer from main server.
    and in case of asynchronous there is no such wait for acknowledgement.
    frequency of crash: 4/5

    kindly suggest.


    BT start:
    --------------------
    0xd849f698 NDIS!ndisMSendCompleteNetBufferListsInternal(void * 0x00000000, _NET_BUFFER_LIST * 0x00000000, unsigned long 0xce9b8780)  line 5293
    0xd849f6c0 NDIS!NdisMSendNetBufferListsComplete(void * 0xce9bbc70, _NET_BUFFER_LIST * 0x00000288, unsigned long 0x00000000)  line 4624
    0xd849f6d8 ENET!MiniportSendNetBufferList(_MP_ADAPTER * 0x00000000, _NET_BUFFER_LIST * 0x00000000, unsigned char 0x00)  line 294
    0xd849f708 ENET!ENETSendNetBufferLists(void * 0xd86ab9d0, _NET_BUFFER_LIST * 0x00000000, unsigned long 0x00000000, unsigned long 0xefaa59dd)  line 1828 + 14 bytes
    0xd849f738 NDIS!ndisMSendNBLToMiniport(void * * 0x00000000, _NET_BUFFER_LIST * 0x00000002, unsigned long 0xd849f7c0, unsigned long 0xef9e1dc9)  line 3632
    0xd849f760 NDIS!NdisSendNetBufferLists(void * 0x00000001, _NET_BUFFER_LIST * 0xcecd0940, unsigned long 0xd86abb16, unsigned long 0xd86ab9d0)  line 3154
    0xd849f770 TCPIP!FlSendPackets(void * 0x00000004, unsigned char 0xc8, _FL_SEND_PACKETS * 0xd849f9c0)  line 1112 + 858 bytes
    0xd849f7c8 TCPIP!IppFragmentPackets(_IP_PROTOCOL * 0xef9ffa78, _IP_REQUEST_CONTROL_DATA * 0x00000000)  line 342
    0xd849f810 TCPIP!IppDispatchSendPacketHelper(_IP_PROTOCOL * 0x00000006, _IP_REQUEST_CONTROL_DATA * 0xd849f88c)  line 1541
    0xd849f868 TCPIP!IppPacketizeDatagrams(_IP_REQUEST_CONTROL_DATA * 0xcec0da70)  line 1422 + 8 bytes
    0xd849f928 TCPIP!IppSendDatagramsCommon(unsigned char 0x00, _NL_CLIENT_DISPATCH_FLAGS {...}, _IP_PROTOCOL * 0xef9ffa78, void * 0xffffffff, _NL_REQUEST_SEND_DATAGRAMS * 0xd849fb70)  line 3408 + 6 bytes
    0xd849fad8 TCPIP!IpNlpSendDatagrams(void * 0x0000fec1, _NL_REQUEST_SEND_DATAGRAMS * 0xcecb05a8)  line 3641
    0xd849faf0 TCPIP!TcpTcbSend(_TCB * 0xceb81d30, unsigned char 0x28)  line 3629 + 272 bytes
    0xd849fc08 TCPIP!TcpEnqueueTcbSendOlmNotifySendComplete(_TCB * 0x00000000, _TCB_REQUEST_SEND * 0x8023ef9f, unsigned char 0x58)  line 1015
    0xd849fc30 TCPIP!TcpEnqueueTcbSend(_TCB * 0x00000000, _TL_REQUEST_SEND * 0x00004000, unsigned char 0x78, unsigned char * 0x0011ba6c)  line 875
    0xd849fc68 AFD!PmSendStream(_Socket * 0x00000000, _WSABUF * 0xd849fdf8, unsigned long 0x00000000, unsigned long * 0xbd867170, unsigned long 0x00000000)  line 632 + 34 bytes
    0xd849fcd0 AFD!PmSend(unsigned int 0x00000000, _WSABUF * 0x00000000, unsigned long 0x00000000, unsigned long * 0x00000000, unsigned long 0x00000000, sockaddr * 0x00000000, unsigned long 0x00000000)  line 778 + 16 bytes
    0xd849fd90 AFD!PMExt_Send(unsigned int 0x00000000, _WSABUF * 0x00000000, unsigned long 0x00000000, unsigned long * 0x00000000, unsigned long 0x00000000)  line 847 + 22 bytes
    0x0011b938 COREDLL!xxx_PMSend(unsigned int 0x00000000, _WSABUF * 0xd849fe58, unsigned long 0x00000001, unsigned long * 0x00124ba0, unsigned long 0x00000000)  line 524 + 12 bytes
    -------------------
    BT End
    Monday, May 6, 2019 12:11 PM

Answers

All replies

  • I don't see any crash in your debug output... Can you define "crash"? Exactly what happens?

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Tuesday, May 7, 2019 7:30 AM
    Moderator
  • Hi Michel,

    Thanks for replying.

    we are getting following data abort message:

    Exception 'Data Abort' (0x4): Thread-Id=06c30002(pth=bd870000), Proc-Id=00400002(pprc=8257dae0) 'NK.EXE', VM-active=06c10002(pprc=bd8a6aa0) 'clientserver.EXE'

    PC=efaa4801(ndis.dll+0x00024801) RA=efaa4495(ndis.dll+0x00024495) SP=cea0f698, BVA=00000000

    Kindly let me know if any other information is required.

    Thanks and Regards,

    Lokesh Kumar

    Tuesday, May 7, 2019 8:13 AM

    • Edited by Rahul Bhatia Tuesday, May 7, 2019 8:35 AM Scenario looks like above image
    Tuesday, May 7, 2019 8:33 AM
  • Look at the NDIS.map file in your FLATRELEASEDIR. Find the function at 0x24395. Having that info may shed some more light on the issue.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Tuesday, May 7, 2019 9:10 PM
    Moderator
  • Hi Michel,

    Thanks for pointing out.

    I am sorry but I could not understand why you asked to check 0x24395, when RA=0x24495.  

    Following is NDIS.map file contents in the range of PC and RA address:

    Please guide.

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

    0001:00022fc8       NdisMTransferDataComplete  10023fc8 f   ndislib:sendm.obj
     0001:0002311c       NdisMWanSendComplete       1002411c f   ndislib:sendm.obj
     0001:000231a4       ndisMCopyFromPacketToBuffer 100241a4 f   ndislib:sendm.obj
     0001:00023244       NdisIMCopySendPerPacketInfo 10024244 f   ndislib:sendm.obj
     0001:00023284       NdisIMCopySendCompletePerPacketInfo 10024284 f   ndislib:sendm.obj
     0001:00023294       ndisMSendCompletePacketToNetBufferLists 10024294 f   ndislib:sendm.obj
     0001:000232dc       ndisMSendNetBufferListsCompleteToNdisPackets 100242dc f   ndislib:sendm.obj
     0001:00023330       ndisSendCompleteWithPause  10024330 f   ndislib:sendm.obj
     0001:000233d0       ndisMSendPacketsToNetBufferLists 100243d0 f   ndislib:sendm.obj
     0001:00023458       NdisMSendNetBufferListsComplete 10024458 f   ndislib:sendm.obj
     0001:00023498       ndisMIsLoopbackNetBuffer   10024498 f   ndislib:sendm.obj
     0001:000237d4       ndisMSendCompleteNetBufferListsInternal 100247d4 f   ndislib:sendm.obj
     0001:00023864       ndisMWanSend               10024864 f   ndislib:sendm.obj
     0001:00023984       ndisMSendPacketsToMiniport 10024984 f   ndislib:sendm.obj
     0001:00023a38       ndisDoLoopbackNetBufferList 10024a38 f   ndislib:sendm.obj
     0001:00023b88       ndisMTransferData          10024b88 f   ndislib:sendm.obj
     0001:00023cac       ndisMSend                  10024cac f   ndislib:sendm.obj
     0001:00023cc8       Log_ndisMSendPackets       10024cc8 f   ndislib:sendm.obj
     0001:00023cf4       ndisSendPacketsWithPause   10024cf4 f   ndislib:sendm.obj
     0001:00023d70       ndisMStartWanSends         10024d70 f   ndislib:sendm.obj
     0001:00023dd0       ndisMIsLoopbackPacket      10024dd0 f   ndislib:sendm.obj
     0001:0002421c       ndisMSendCompleteX         1002521c f   ndislib:sendm.obj
     0001:000243e8       ndisMCompleteSend          100253e8 f   ndislib:sendm.obj
     0001:00024498       ndisMSendNetBufferListsToPackets 10025498 f   ndislib:sendm.obj
     0001:0002450c       Log_ndisMWanSend           1002550c f   ndislib:sendm.obj
     0001:00024548       ndisMLoopbackNetBufferLists 10025548 f   ndislib:sendm.obj
     ---------------------

    Sorry  for dumping more than expected data.

    Regards,

    Lokesh kumar

     


    • Edited by lokeshkumar_r15 Wednesday, May 8, 2019 6:21 AM removed unnecessary logs
    Wednesday, May 8, 2019 6:19 AM
  • Sorry, I mistyped. You need to check for the function at 0x23495. The address of the exception minus 0x1000.

    Looks like the issue occurs close to the return of the NdisMSendNetBufferListsComplete function.

    This is probably due to your network driver sending a net buffer list that is malformed (eg not properly initialized or terminated).

    Debugging this goes outside what we can do in this forum.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Wednesday, May 8, 2019 10:24 AM
    Moderator
  • Hi Michel,

    Thanks a lot for your reply.

    could you please guide me whether I should  share this issue with Microsoft  or discuss with BSP vendor.

    Regards,

    Lokesh Kumar

    Wednesday, May 8, 2019 11:38 AM
  • Most likely with your BSP vendor (or you can switch to a better iMX6 BSP... ;-))

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Wednesday, May 8, 2019 1:01 PM
    Moderator
  • Thanks Michel for your kind support.
    Friday, May 10, 2019 9:49 AM