Windows server 2012 standard R2 crash due to stack overflow in tcpip module when acts as iscsi initiator

[Jianchao Wang]

As the title, when we take a windows hosts as an iscsi initiator, it will crash in tcpip module due to stack overflow. Please refer to the backtrace from the memory dump,



STACK_

STACKUSAGE_IMAGE: The module at base 0xFFFFF80000ECE000 was blamed for the stack overflow. It is using 17600 bytes of stack.


STACK_TEXT:
fffff800`3faaefb0 : NETIO!WfpWriteNeteventToUnifiedTrace+0x1b7
fffff800`3faaf3e0 : NETIO!KfdDiagnoseEventExpandStack+0x34e
fffff800`3faaf7a0 : NETIO!KfdDiagnoseEvent+0x38
fffff800`3faaf7f0 : tcpip!IndicateDropAudit+0x4e1
fffff800`3faafb90 : tcpip!WfpAlepAuthorizeReceive+0xd8f
fffff800`3fab01f0 : tcpip!WfpAleAuthorizeReceive+0x4a8
fffff800`3fab0560 : tcpip!ProcessALEForTransportPacket+0x520
fffff800`3fab07a0 : tcpip!WfpProcessInTransportStackIndication+0x950
fffff800`3fab0e60 : tcpip!InetInspectReceiveDatagram+0x264
fffff800`3fab0f90 : tcpip!RawBeginMessageIndication+0x59
fffff800`3fab1060 : tcpip!RawDeliverDatagrams+0x10b
fffff800`3fab1220 : tcpip!RawReceiveDatagrams+0x22d
fffff800`3fab1320 : tcpip!IppDeliverListToProtocol+0x4f
fffff800`3fab13e0 : tcpip!IppProcessDeliverList+0x63
fffff800`3fab1480 : tcpip!IppReceiveHeaderBatch+0x647
fffff800`3fab15b0 : tcpip!IppLoopbackIndicatePackets+0x330
fffff800`3fab1690 : tcpip!IppLoopbackEnqueue+0x3be
fffff800`3fab1dd0 : tcpip!IppFragmentPackets+0xbec
fffff800`3fab1f20 : tcpip!IppDispatchSendPacketHelper+0x94
fffff800`3fab20b0 : tcpip!IppPacketizeDatagrams+0x2dd
fffff800`3fab2250 : tcpip!IppSendDatagramsCommon+0x4a2
fffff800`3fab2430 : tcpip!IpNlpSendDatagrams+0x42
fffff800`3fab2470 : tcpip!IpNlpFastSendDatagram+0x399
fffff800`3fab2550 : tcpip!TcpTcbHeaderSend+0x6c5
fffff800`3fab27f0 : tcpip!TcpDeliverInput+0x443
fffff800`3fab2a70 : tcpip!TcpRequestReceive+0x18f
fffff800`3fab2b30 : afd!WskProIRPReceive+0xc6
fffff800`3fab2ba0 : msiscsi!iScsiWskSocketReceiveData+0x84
fffff800`3fab2bd0 : msiscsi!iSpBuildIrpToReadData+0x59a
fffff800`3fab2c40 : msiscsi!iSpProcessData+0x6f1
fffff800`3fab2cf0 : msiscsi!iSpProcessHeader+0x3c1
fffff800`3fab2d70 : msiscsi!iSpReceiveHandler+0xd2
fffff800`3fab2dc0 : msiscsi!iScsiWskSocketReceiveEvent+0x182
fffff800`3fab2e20 : afd!WskProTLEVENTReceive+0xdc
fffff800`3fab2ef0 : tcpip!TcpIndicateData+0x15a
fffff800`3fab3010 : tcpip!TcpDeliverDataToClient+0x2ba
fffff800`3fab3190 : tcpip!TcpDeliverReceive+0xab
fffff800`3fab3290 : tcpip!TcpTcbFastDatagram+0x245
fffff800`3fab34e0 : tcpip!TcpTcbReceive+0x160
fffff800`3fab3630 : tcpip!TcpMatchReceive+0x1e7
fffff800`3fab37c0 : tcpip!TcpPreValidatedReceive+0x385
fffff800`3fab38c0 : tcpip!IppDeliverListToProtocol+0x4f
fffff800`3fab3980 : tcpip!IppProcessDeliverList+0x63
fffff800`3fab3a20 : tcpip!IppReceiveHeaderBatch+0x1fc
fffff800`3fab3b50 : tcpip!IppFlcReceivePacketsCore+0x69a
fffff800`3fab3ee0 : tcpip!IpFlcReceivePreValidatedPackets+0x7cd
fffff800`3fab4070 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x15d
fffff800`3fab41a0 : nt!KeExpandKernelStackAndCalloutInternal+0xe9
fffff800`3fab42f0 : tcpip!FlReceiveNetBufferListChain+0xbe
fffff800`3fab4370 : NDIS!ndisMIndicateNetBufferListsToOpen+0x11e
fffff800`3fab4430 : NDIS!ndisMTopReceiveNetBufferLists+0x228
fffff800`3fab44c0 : NDIS!NdisMIndicateReceiveNetBufferLists+0xba7
fffff800`3fab46b0 : ixn64x64+0x295fa
fffff800`3fab4700 : ixn64x64+0x2a088
fffff800`3fab4780 : ixn64x64+0xc607
fffff800`3fab47f0 : ixn64x64+0xca01
fffff800`3fab4860 : ixn64x64+0xbec8
fffff800`3fab48a0 : NDIS!ndisInterruptDpc+0x1b2
fffff800`3fab49d0 : nt!KiExecuteAllDpcs+0x1b0
fffff800`3fab4b20 : nt!KiRetireDpcList+0xe1
fffff800`3fab4da0 : nt!KiIdleLoop+0x5a



Is this an existing issue in windows server 2012 r2?

Has it been fixed ?

Continue reading...