Bugcheck after UDP redirection RRS feed

  • Question

  • If I redirect a certain UDP stream to localhost at the CONNECT_REDIRECT layer, a bugcheck happens when I try to perform Windows shutdown or startup. It happens during shutdwon even if my callout driver is stopped manually before
    shutdown. The UDP stream that causes the bugcheck is created by svchost.exe and destined to [FF02::C]:1900. I was unable to reproduce it using a test app. Crash dump follows.

    Microsoft (R) Windows Debugger Version 6.2.9200.16384 X86
    Copyright (c) Microsoft Corporation. All rights reserved.

    Loading Dump File [C:\Users\Administrator\Desktop\110212-17893-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: SRV*c:\symbols_web*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    Windows 8 Kernel Version 9200 UP Free x86 compatible
    Product: WinNt, suite: TerminalServer SingleUserTS
    Built by: 9200.16384.x86fre.win8_rtm.120725-1247
    Machine Name:
    Kernel base = 0x8101d000 PsLoadedModuleList = 0x81207de8
    Debug session time: Fri Nov  2 16:35:19.460 2012 (UTC - 7:00)
    System Uptime: 0 days 0:00:37.113
    Loading Kernel Symbols
    Loading User Symbols
    Loading unloaded module list
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *

    Use !analyze -v to get detailed debugging information.

    BugCheck D1, {130, 2, 1, 823480f5}

    Probably caused by : tcpip.sys ( tcpip! ?? ::FNODOBFM::`string'+20962 )

    Followup: MachineOwner

    kd> !analyze -v
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *

    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.
    Arg1: 00000130, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000001, value 0 = read operation, 1 = write operation
    Arg4: 823480f5, address which referenced memory

    Debugging Details:

    WRITE_ADDRESS: GetPointerFromAddress: unable to read from 81231470
    Unable to read MiSystemVaType memory at 81207000


    tcpip! ?? ::FNODOBFM::`string'+20962
    823480f5 f00fc108        lock xadd dword ptr [eax],ecx




    PROCESS_NAME:  svchost.exe

    TRAP_FRAME:  98c9f0e4 -- (.trap 0xffffffff98c9f0e4)
    ErrCode = 00000002
    eax=00000130 ebx=8681e290 ecx=00000001 edx=98c9f20c esi=00000012 edi=8680cd58
    eip=823480f5 esp=98c9f158 ebp=98c9f234 iopl=0         nv up ei pl nz na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010206
    tcpip! ?? ::FNODOBFM::`string'+0x20962:
    823480f5 f00fc108        lock xadd dword ptr [eax],ecx ds:0023:00000130=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 8118b840 to 81114ccc

    98c9f0c4 8118b840 0000000a 00000130 00000002 nt!KiBugCheck2
    98c9f0c4 823480f5 0000000a 00000130 00000002 nt!KiTrap0E+0x2c8
    98c9f234 822a2301 00000011 00000017 0000fad3 tcpip! ?? ::FNODOBFM::`string'+0x20962
    98c9f39c 822a2b96 00000029 00000011 8680b948 tcpip!IppInspectLocalDatagramsOut+0x658
    98c9f45c 822a9f70 00000004 823762f0 8680b948 tcpip!IppSendDatagramsCommon+0x39c
    98c9f478 822aaa55 853e84e0 98c9f538 00000000 tcpip!IpNlpSendDatagrams+0x42
    98c9f6e8 822aaf04 00000000 00000000 867a08f0 tcpip!UdpSendMessagesOnPathCreation+0x4d4
    98c9f8d8 822ab22a 86828040 98c9f95c 810cd370 tcpip!UdpSendMessages+0x1cd
    98c9f8e4 810cd370 98c9f9a4 4ef7d3f4 00000000 tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x13
    98c9f95c 810ccfcf 822ab217 98c9f9a4 00002400 nt!KeExpandKernelStackAndCalloutInternal+0x38b
    98c9f97c 822aa3fb 822ab217 98c9f9a4 00002400 nt!KeExpandKernelStackAndCalloutEx+0x1f
    98c9f9c0 8c069c8c 867a08f0 98c9f9d8 8680b1a0 tcpip!UdpTlProviderSendMessages+0x55
    98c9fa14 8c069952 8680b1a0 6e1ecb91 7fff0000 afd!AfdTLFastDgramSend+0xc6
    98c9fad0 8c058573 98c9fb90 00000000 00000000 afd!AfdFastDatagramSend+0x1fd
    98c9fc40 812657b2 8680b1a0 00000001 00fff1c8 afd!AfdFastIoDeviceControl+0x56e
    98c9fcf0 812655c9 85954030 00000110 00000000 nt!IopXxxControlFile+0x1cd
    98c9fd24 811882fc 00000178 00000110 00000000 nt!NtDeviceIoControlFile+0x2a
    98c9fd24 77df6954 00000178 00000110 00000000 nt!KiFastCallEntry+0x12c
    WARNING: Frame IP not in any known module. Following frames may be wrong.
    00fff290 00000000 00000000 00000000 00000000 0x77df6954


    tcpip! ?? ::FNODOBFM::`string'+20962
    823480f5 f00fc108        lock xadd dword ptr [eax],ecx


    SYMBOL_NAME:  tcpip! ?? ::FNODOBFM::`string'+20962

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: tcpip

    IMAGE_NAME:  tcpip.sys



    FAILURE_BUCKET_ID:  AV_tcpip!_??_::FNODOBFM::_string_

    BUCKET_ID:  AV_tcpip!_??_::FNODOBFM::_string_

    Followup: MachineOwner

    Sunday, November 4, 2012 1:06 AM

All replies

  • Update: svchost.exe actually opens a number of simultaneous UDP flows destined to [FF02::C]:1900, one for each network interface.

    The client  seems to use the IPV6_MULTICAST_IF socket option to choose the interface. I guess there is a bug in tcpip.sys related to the use of IPV6_MULTICAST_IF.

    • Edited by Sergey982 Sunday, November 4, 2012 10:16 PM
    Sunday, November 4, 2012 10:13 PM
  • The bugcheck can be provoked by installing an ale_connect_redirect callout that redirects all udp to somewhere (even to a non-existent external ip), and then restaring the SSDP Discovery service one or more times.

    I have a hint that the bugcheck originates in 'tcpip!AleRedirectRecordReference' (always at the same location).  According to the function name, it sounds like a Win8 related issue. At least, I couldn't reproduce it on Wi7.
    Wednesday, November 7, 2012 8:12 PM
  • I have performed another test with minimalistic inline UDP redirection, and now I'm 100% sure it is a WFP bug. The crash persists after applying the latest Windows security updates which replace tcpip.sys and fwpkclnt.sys with newer versions.
    Friday, November 9, 2012 3:41 PM
  • I have informed our sustained engineering team about the issue you are seeing.  They will investigate and reply back.


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

    Friday, November 9, 2012 6:28 PM