locked
EXCEPTION_DOUBLE_FAULT, who's to blame? RRS feed

  • Question

  • Hi,
    I have seen several BSODs with kernel network stack overflow, but I'm not really sure how to fix them. Please look at this callstack from 64-bit Win7 and tell me what you see...

    Thanks a lot!
    Petr Kurtin

     



    3: kd> kf L 200
     Memory Child-SP     RetAddr      Call Site
         fffff880`02fdace8 fffff800`02cd0c69 nt!KeBugCheckEx
        8 fffff880`02fdacf0 fffff800`02ccf132 nt!KiBugCheckDispatch+0x69
       140 fffff880`02fdae30 fffff800`02cdbb04 nt!KiDoubleFaultAbort+0xb2
     66a5170 fffff880`0967ffa0 fffff800`02cd6da7 nt!SepMandatoryIntegrityCheck+0x14
        80 fffff880`09680020 fffff800`02c99f32 nt!SeAccessCheckWithHint+0x317
        e0 fffff880`09680100 fffff880`01736c5a nt!SeAccessCheckFromState+0x102
       6f0 fffff880`096807f0 fffff880`0173494f NETIO!CompareSecurityContexts+0x6a
        70 fffff880`09680860 fffff880`017369b5 NETIO!MatchValues+0xef
        50 fffff880`096808b0 fffff880`01736845 NETIO!FilterMatch+0x95
        50 fffff880`09680900 fffff880`01737ccb NETIO!IndexListClassify+0x69
        80 fffff880`09680980 fffff880`0183d3a7 NETIO!KfdClassify+0xa4e
       370 fffff880`09680cf0 fffff880`018367ee tcpip!WfpAleClassify+0x57
        40 fffff880`09680d30 fffff880`01835c85 tcpip!WfpAlepAuthorizeSend+0x94e
       710 fffff880`09681440 fffff880`01839826 tcpip!WfpAleAuthorizeSend+0x325
       2d0 fffff880`09681710 fffff880`0183c574 tcpip!WfpAleConnectAcceptIndicate+0x106
        f0 fffff880`09681800 fffff880`01834fc9 tcpip!ProcessALEForTransportPacket+0x664
       270 fffff880`09681a70 fffff880`01863e76 tcpip!WfpProcessOutTransportStackIndication+0x329
       1d0 fffff880`09681c40 fffff880`0186916e tcpip!IppSendDatagramsCommon+0x526
       2d0 fffff880`09681f10 fffff880`01833d68 tcpip!IpNlpSendDatagrams+0x3e
        40 fffff880`09681f50 fffff880`018342dd tcpip!UdpSendMessagesOnPathCreation+0x688
       380 fffff880`096822d0 fffff880`01833f65 tcpip!UdpSendMessages+0x35d
       3f0 fffff880`096826c0 fffff800`02ce0e5a tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
        30 fffff880`096826f0 fffff880`01834528 nt!KeExpandKernelStackAndCalloutEx+0xda
        e0 fffff880`096827d0 fffff880`02d8ff45 tcpip!UdpTlProviderSendMessages+0x78
        80 fffff880`09682850 fffff880`02d8fff2 tdx!TdxSendDatagramTransportAddress+0x2f5
        e0 fffff880`09682930 fffff880`02db91a8 tdx!TdxTdiDispatchInternalDeviceControl+0x52
        30 fffff880`09682960 fffff880`02db9607 aswTdi!TDIH_TdiSendDatagram+0x1a0
        70 fffff880`096829d0 fffff880`02c02542 aswTdi!TDIH_DispatchInternalDeviceControl+0x127
        40 fffff880`09682a10 fffff880`02c02f61 netbt!TdiSendDatagram+0x187
        70 fffff880`09682a80 fffff880`02c0f329 netbt!UdpSendDatagram+0x1b1
        90 fffff880`09682b10 fffff880`02c0f0e6 netbt!UdpSendResponse+0x4e0
        80 fffff880`09682b90 fffff880`02c03be7 netbt!QueryFromNet+0xb11
       130 fffff880`09682cc0 fffff880`02c01b47 netbt!NameSrvHndlrNotOs+0xca
        40 fffff880`09682d00 fffff880`02d8e325 netbt!TdiRcvNameSrvHandler+0x367
        a0 fffff880`09682da0 fffff880`0183f325 tdx!TdxEventReceiveMessagesTransportAddress+0x315
       1f0 fffff880`09682f90 fffff880`0183f834 tcpip!UdpDeliverDatagrams+0x155
       190 fffff880`09683120 fffff880`0185d6a7 tcpip!UdpReceiveDatagrams+0x324
        f0 fffff880`09683210 fffff880`0185d719 tcpip!IppDeliverListToProtocol+0xf7
        c0 fffff880`096832d0 fffff880`0185dc10 tcpip!IppProcessDeliverList+0x59
        70 fffff880`09683340 fffff880`0185caa1 tcpip!IppReceiveHeaderBatch+0x231
        e0 fffff880`09683420 fffff880`019344a2 tcpip!IpFlcReceivePackets+0x651
       200 fffff880`09683620 fffff880`015a9afa tcpip!IppInspectInjectReceive+0xf2
        40 fffff880`09683660 fffff880`03a15863 fwpkclnt!FwpsInjectTransportReceiveAsync0+0x256
        b0 fffff880`09683710 fffff880`03a14a86 vsdatant+0x15863
        90 fffff880`096837a0 fffff880`03a0e651 vsdatant+0x14a86
       100 fffff880`096838a0 fffff880`0174d57f vsdatant+0xe651
       130 fffff880`096839d0 fffff880`017374db NETIO! ?? ::FNODOBFM::`string'+0x7267
       120 fffff880`09683af0 fffff880`018fef1b NETIO!KfdClassify+0x24b
       370 fffff880`09683e60 fffff880`01802d20 tcpip!WFPDatagramDataShimV4+0x49b
       360 fffff880`096841c0 fffff880`0187e69d tcpip! ?? ::FNODOBFM::`string'+0x2b43f
       270 fffff880`09684430 fffff880`0183dfe0 tcpip!ProcessAleForNonTcpIn+0x1ad
       120 fffff880`09684550 fffff880`0186ef51 tcpip!WfpProcessInTransportStackIndication+0xb10
       370 fffff880`096848c0 fffff880`0183eef3 tcpip!InetInspectReceiveDatagram+0x121
        a0 fffff880`09684960 fffff880`0183f2a5 tcpip!UdpBeginMessageIndication+0x83
       150 fffff880`09684ab0 fffff880`0183f834 tcpip!UdpDeliverDatagrams+0xd5
       190 fffff880`09684c40 fffff880`0185d6a7 tcpip!UdpReceiveDatagrams+0x324
        f0 fffff880`09684d30 fffff880`0185d719 tcpip!IppDeliverListToProtocol+0xf7
        c0 fffff880`09684df0 fffff880`0185dc10 tcpip!IppProcessDeliverList+0x59
        70 fffff880`09684e60 fffff880`0185caa1 tcpip!IppReceiveHeaderBatch+0x231
        e0 fffff880`09684f40 fffff880`0185b512 tcpip!IpFlcReceivePackets+0x651
       200 fffff880`09685140 fffff880`01874dba tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
        e0 fffff880`09685220 fffff800`02ce0e5a tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xda
        50 fffff880`09685270 fffff880`018747e2 nt!KeExpandKernelStackAndCalloutEx+0xda
        e0 fffff880`09685350 fffff880`016fc0eb tcpip!FlReceiveNetBufferListChain+0xb2
        70 fffff880`096853c0 fffff880`016c5fc6 ndis!ndisMIndicateNetBufferListsToOpen+0xdb
        70 fffff880`09685430 fffff880`01648a24 ndis!ndisMDispatchReceiveNetBufferLists+0x1d6
       480 fffff880`096858b0 fffff880`016489e9 ndis!ndisMTopReceiveNetBufferLists+0x24
        40 fffff880`096858f0 fffff880`01648980 ndis!ndisFilterIndicateReceiveNetBufferLists+0x29
        40 fffff880`09685930 fffff880`03a1864d ndis!NdisFIndicateReceiveNetBufferLists+0x50
        40 fffff880`09685970 fffff880`016602b7 vsdatant+0x1864d
        a0 fffff880`09685a10 fffff880`04257af7 ndis! ?? ::FNODOBFM::`string'+0xccef
        50 fffff880`09685a60 fffff880`0424ac08 Rt64win7!MpHandleRecvIntPriVLanJumbo+0xaa3
        f0 fffff880`09685b50 fffff880`016cae4b Rt64win7!MPHandleInterrupt+0x244
        50 fffff880`09685ba0 fffff880`01650bfd ndis! ?? ::DKGKHJNI::`string'+0x1597
        70 fffff880`09685c10 fffff880`01677b0c ndis!ndisQueuedMiniportDpcWorkItem+0xcd
        a0 fffff880`09685cb0 fffff800`02f74bc6 ndis!ndisReceiveWorkerThread+0x12c
        90 fffff880`09685d40 fffff800`02cafbc6 nt!PspSystemThreadStartup+0x5a
        40 fffff880`09685d80 00000000`00000000 nt!KxStartSystemThread+0x16
    
    


    Tuesday, July 19, 2011 7:25 PM

Answers

  • The solution to this is to call KeExpandKernelStackAndCalloutEx().  http://msdn.microsoft.com/en-us/library/ff552036(VS.85).aspx (Or get rid of the TDI driver which consumes alot of the stack by default)

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, July 20, 2011 11:11 PM
    Moderator

All replies

  • There is a TDI driver in the stack making this an unsupported scenario.  The TDI filter will cause you to use more stack space (it reserves 8K by default).  Can you repro with the TDI filter removed?

    Hope this helps, 


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Tuesday, July 19, 2011 11:29 PM
    Moderator
  • Thanks, this is customer's memory dump. The TDI driver in the callstack is a passthru driver, it should just call next lower driver (aswTdi!TDIH_TdiSendDatagram is a very simple function). What do you mean by "unsupported scenario"?

    Yes, we're going to rewrite our TDI drivers to WFP, but right now I'd like to understand this bsod. Can _any other_ TDI driver cause this stack overflow so simple and uncontrollably? As I know, TDI will be still supported in next Win version.

    Thank you,
    Petr

    Tuesday, July 19, 2011 11:42 PM
  • Can you supply me with the memory dump?  What does the filter look like (in the KfdClassify)?

    There is a difference between available and supported.  We have been saying not to use TDI for years now.  While it is still available to use we are not condoning it's use nor readily supporting it.

    please e-mail me the location for the memory dump and I'll see if I can provide any insight.

    Thanks,

     

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, July 20, 2011 4:14 AM
    Moderator
  • The solution to this is to call KeExpandKernelStackAndCalloutEx().  http://msdn.microsoft.com/en-us/library/ff552036(VS.85).aspx (Or get rid of the TDI driver which consumes alot of the stack by default)

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, July 20, 2011 11:11 PM
    Moderator