ASSERT is triggered at connect layer coded in wdk sample RRS feed

  • Question

  • // // If we reach here it means this is a policy change triggered re-auth // for an pre-existing connection. For such a packet (inbound or // outbound) we queue it to the packet queue and inspect it just like // other regular data packets from TRANSPORT layers. // ASSERT(layerData != NULL);

    kd> k
    ChildEBP RetAddr  
    a057321c 8d1d8beb nt!RtlAssert+0xca
    a05732f4 81b00e4e bnbasex!InspectALEConnectClassify+0x67b
    a0573398 81b02ffb NETIO!ProcessCallout+0x4a0
    a0573470 81b01801 NETIO!ArbitrateAndEnforce+0x533
    a05736a0 82689a73 NETIO!KfdClassify+0x2f1
    a057378c 82676ecc tcpip!WfpAlepReauthorizeOutboundConnection+0x9b2
    a0573834 8269c901 tcpip!WfpAleReauthorizeOutboundConnection+0xd6
    a0573924 826cf155 tcpip!WfpAleReauthorizeConnection+0x1cd
    a05739dc 82654eb2 tcpip!WfpAleStreamLayerChanged+0x1b9
    a05739e8 81b14f5e tcpip!WfpAlepOnLayerChange+0x25
    a0573a10 81b14e99 NETIO!KfdNotifyLayerEventToClientNoLock+0x7b
    a0573a38 81b15761 NETIO!KfdNotifyLayerEvent+0x1e8
    a0573a60 82654dee NETIO!IoctlKfdCommitTransaction+0x140
    a0573a90 82654ee6 tcpip!KfdDispatchDevCtl+0xab
    a0573aa0 8144da7c tcpip!NlDispatchDeviceControl+0x29
    a0573abc 8165df1c nt!IofCallDriver+0x3f
    a0573b10 8165d991 nt!IopSynchronousServiceTail+0x121
    a0573bb0 8165d5c9 nt!IopXxxControlFile+0x3ac
    a0573be4 815802fc nt!NtDeviceIoControlFile+0x2a
    a0573be4 770d6954 nt!KiFastCallEntry+0x12c
    0165f264 770d59ea ntdll!KiFastSystemCallRet
    0165f268 6f31ee68 ntdll!ZwDeviceIoControlFile+0xa

    kd> dt inFixedValues
    Local var @ 0xa05732fc Type FWPS_INCOMING_VALUES0_*
       +0x000 layerId          : 0x30
       +0x004 valueCount       : 0x22
       +0x008 incomingValue    : 0x8625def0 FWPS_INCOMING_VALUE0_
    kd> dt inMetaValues
    Local var @ 0xa0573300 Type FWPS_INCOMING_METADATA_VALUES0_*
       +0x000 currentMetadataValues : 0x404ccbe
       +0x004 flags            : 0
       +0x008 reserved         : 0xa057372c
       +0x010 discardMetadata  : FWPS_DISCARD_METADATA0_
       +0x020 flowHandle       : 0x22
       +0x028 ipHeaderSize     : 0
       +0x02c transportHeaderSize : 0
       +0x030 processPath      : 0xa0573738 FWP_BYTE_BLOB_
       +0x038 token            : 0xffffffff`80001318
       +0x040 processId        : 0x4b8
       +0x048 sourceInterfaceIndex : 0
       +0x04c destinationInterfaceIndex : 0
       +0x050 compartmentId    : 1
       +0x054 fragmentMetadata : FWPS_INBOUND_FRAGMENT_METADATA0_
       +0x060 pathMtu          : 0
       +0x064 completionHandle : 0x85275c00 Void
       +0x068 transportEndpointHandle : 0x27
       +0x070 remoteScopeId    : SCOPE_ID
       +0x074 controlData      : (null) 
       +0x078 controlDataLength : 0
       +0x07c packetDirection  : 0 ( FWP_DIRECTION_OUTBOUND )
       +0x080 headerIncludeHeader : (null) 
       +0x084 headerIncludeHeaderLength : 0
       +0x088 destinationPrefix : _IP_ADDRESS_PREFIX
       +0x0a8 frameLength      : 0
       +0x0b0 parentEndpointHandle : 0x26
       +0x0b8 icmpIdAndSequence : 0
       +0x0bc localRedirectTargetPID : 0
       +0x0c0 originalDestination : (null) 

    is it a known bug ??

    Friday, October 25, 2013 7:41 AM


  • Is this for a TCP connection? That is the only time when the layerData could possibly be NULL, and even in that case, the connection would have to be mid handshake.

    Hope this helps,

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

    Wednesday, October 30, 2013 7:17 PM