locked
WFP callout driver and Teredo interface issue. RRS feed

  • Question

  • I have wfp callout driver registered for FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4, FWPM_LAYER_ALE_RESOURCE_RELEASE_V4, FWPM_LAYER_STREAM_V4, FWPM_LAYER_DATAGRAM_DATA_V4 and FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4. nothing for V6 layer.

    On windows 8 and above it is giving dump and in windbg it shows,

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    An attempt was made to access a pageable (or completely invalid) address at an
    interrupt request level (IRQL) that is too high.  This is usually
    caused by drivers using improper addresses.
    If kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: 00000014, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: 8cf252a9, address which referenced memory

    Debugging Details:
    ------------------


    READ_ADDRESS:  00000014

    CURRENT_IRQL:  2

    FAULTING_IP:
    NETIO!RtlCopyBufferToMdl+1b
    8cf252a9 394614          cmp     dword ptr [esi+14h],eax

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

    BUGCHECK_STR:  AV

    PROCESS_NAME:  System

    TRAP_FRAME:  82dbf13c -- (.trap 0xffffffff82dbf13c)
    ErrCode = 00000000
    eax=82dbf1b8 ebx=82dbf1e8 ecx=00000000 edx=ffffffbc esi=00000000 edi=00000044
    eip=8cf252a9 esp=82dbf1b0 ebp=82dbf1bc iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0000  es=0023  fs=0030  gs=0023             efl=00010246
    NETIO!RtlCopyBufferToMdl+0x1b:
    8cf252a9 394614          cmp     dword ptr [esi+14h],eax   ds:00000014=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 81973c73 to 8195f5a0

    STACK_TEXT: 
    82dbf090 81973c73 0000000a 00000014 00000002 nt!KiBugCheck2
    82dbf090 8cf252a9 0000000a 00000014 00000002 nt!KiTrap0E+0x1cf
    82dbf1bc 8d24b356 88c7d148 00000000 ffffffbc NETIO!RtlCopyBufferToMdl+0x1b
    82dbf200 8d271ac3 82dbf238 2ee5b892 2ee5b893 tcpip!TcpTcbReassemblyRetrieveSegments+0x17e
    82dbf3c4 8d26cbca 82dbf3e8 82dbf42c 85bd14b0 tcpip!TcpTcbCarefulDatagram+0xd13
    82dbf458 8d26c633 82dbf4d4 00000000 85bd14b0 tcpip!TcpTcbReceive+0x23e
    82dbf4e4 8d26bb90 00000000 85bd14b0 00001759 tcpip!TcpMatchReceive+0x1c1
    82dbf56c 8d26aa2b 00000002 82dbf65c 8d37b3a0 tcpip!TcpPreValidatedReceive+0x38a
    82dbf58c 8d288e2f 82dbf5a4 8d37b2c8 8d37b3a0 tcpip!TcpNlClientReceiveDatagrams+0x41
    82dbf5c0 8d286a89 00000006 00000000 8d37b2c8 tcpip!IppDeliverListToProtocol+0x41
    82dbf608 8d286007 82dbf65c 82dbf654 82dbf668 tcpip!IppProcessDeliverList+0x60
    82dbf690 8d2877c8 88c26008 00000006 82dbf800 tcpip!IppReceiveHeaderBatch+0x1cd
    82dbf7a4 8d283c69 82dbf800 00000000 894f28d8 tcpip!IppFlcReceivePacketsCore+0x776
    82dbf814 8d283ee0 8d284476 84e16c70 0010a48c tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x28c
    82dbf8d4 818ecea5 82dbf9a4 1cf111ef 00000006 tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xc4
    82dbf964 818ecb09 00002400 00000002 00000000 nt!KeExpandKernelStackAndCalloutInternal+0x385
    82dbf97c 8d2845b3 8d283e1c 82dbf9a4 00002400 nt!KeExpandKernelStackAndCalloutEx+0x1f
    82dbf9c4 8ce4005f 00c26008 894f2801 00000000 tcpip!FlReceiveNetBufferListChain+0x98
    82dbfa2c 8ce44afb 00000000 00000002 00000100 ndis!ndisMIndicateNetBufferListsToOpen+0x21b
    82dbfa7c 8ce3c166 88f610e8 894f28d8 00000000 ndis!ndisMTopReceiveNetBufferLists+0x237
    82dbfb6c b06ff7ef 88f610e8 894f28d8 00000000 ndis!NdisMIndicateReceiveNetBufferLists+0x578
    82dbfb8c b06fbad8 88ee69a0 894f28d8 b06fbac6 tunnel!TeredoWfpIndicationWorker+0x54
    82dbfba0 8188ec76 88ee69a0 b070b758 8188ec0e tunnel!LwWorker+0x12
    82dbfbe4 8188e4f9 889fdd18 00000000 89056900 nt!IopProcessWorkItem+0x68
    82dbfc30 8190f1d4 00000000 1cf114fb 00000000 nt!ExpWorkerThread+0xff
    82dbfc70 81974fb1 8188e3fa 00000000 00000000 nt!PspSystemThreadStartup+0x58
    82dbfc84 818b3382 86d14b28 0000001b 00000000 nt!KiThreadStartup+0x15
    82dbfcd8 00000000 00000000 00000000 00000000 nt!ExpWaitForResource+0xf2


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    NETIO!RtlCopyBufferToMdl+1b
    8cf252a9 394614          cmp     dword ptr [esi+14h],eax

    SYMBOL_STACK_INDEX:  2

    SYMBOL_NAME:  NETIO!RtlCopyBufferToMdl+1b

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: NETIO

    IMAGE_NAME:  NETIO.SYS

    DEBUG_FLR_IMAGE_TIMESTAMP:  52158eda

    BUCKET_ID_FUNC_OFFSET:  1b

    FAILURE_BUCKET_ID:  AV_NETIO!RtlCopyBufferToMdl

    BUCKET_ID:  AV_NETIO!RtlCopyBufferToMdl

    Followup: MachineOwner
    ---------

    It does not point to my driver. but if I run command "netsh interface teredo set state disabled", the crashing stops and everything works fine.

    So what does this mean? what could be issue in my driver?


    • Edited by W8Lover Thursday, January 2, 2014 6:24 AM
    Thursday, January 2, 2014 6:23 AM

All replies

  • I had many reports with the same dump from users. It looks like a bug in Teredo implementation, and one of the reasons why it is disabled by default. I found no other solution except disabling Teredo. It is possible to use netsh as above or disable it completely in system registry (set DWORD value DisabledComponents to 0x8e in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters).
    Friday, January 3, 2014 9:28 PM
  • Please send a link to a memory dump to DHarper @AT@ Microsoft .DOT. com.

    Thanks


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

    Tuesday, January 21, 2014 2:20 AM
    Moderator
  • Teredo packets come into the interface initially as UDPv4.

    Can you explain what your DATAGRAM_DATA callout does?

    Can you please provide a memory dump with the following enabled in the repro:

    Driver Verifer:

    Verifier.exe /standard /driver afd.sys fwpkclnt.sys ndis.sys netio.sys tcpip.sys tunnel.sys YOUR_DRIVER.sys

    NBL Tracking:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS\Parameters]
    "TrackNblOwner"=dword:00000004

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
    “VerifierPoolTracesLength”=dword:100000

    Thanks,


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

    Thursday, January 30, 2014 7:49 PM
    Moderator
  • Dusty,

    I have sent you the dump file. But it is not with verifier enabled.

    Regarding DATAGRAM_DATA, we check if the packet is tunneled. If not tunneled we inspect these packets in usermode app.

    Wednesday, February 5, 2014 6:31 AM
  • I have received the dump. In order to fully investigate, I will need another with verifier and NBL tracking enabled.

    Thanks,


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

    Wednesday, February 5, 2014 5:31 PM
    Moderator
  • Same issue seems to be reported for every other WFP filter driver. Is there anything that we are doing wrong and causing this issue?

    or is it WFP's issue?

    Friday, October 31, 2014 6:34 AM