locked
I want to know the final solutions to the crash with inspect sample in Win7. RRS feed

  • Question

  • I want to know the final solutions to the crash with inspect sample in Win7.
                     thanks!
    Thursday, December 2, 2010 2:21 AM

Answers

  • The answer is in the thread:

    <sic>
       We believe we had root-caused the issue behind the Inspect sample crashing on Win7 machines. In a nutshell it is a Tcpip/WFP interaction bug 
       manifested by some raw socket listener changes made in Win7.

       As a workaround you can modify the sample such that packet is cloned from within classifyFn instead of referenced and clone outside of
       classifyFn.

       The sample's the approach (calling FwpsReferenceNetBufferList0 from classifyFn and then cloning it from the worker thread) makes it susceptible to the subtle changes introduced in Win7.

       If workaround is not desirable, you could also contact MSFT PSS for a hotfix.

       Thanks,
       Biao.W.
    </sic>

    In addition, please do not spam your posts in unrelated threads (Thanks).

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, January 5, 2011 6:59 PM
    Moderator

All replies

  • Can you please be more specific as to what you are asking and what the exact problem is. Thanks,
    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Friday, December 3, 2010 9:25 PM
    Moderator
  • OK!  The problem is:

    Crash with inspect sample

    • Tuesday, August 11, 2009 7:47 AMsmilish Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       
      Vote As Helpful

      Hi. I am facing a crash caused by NETIO.SYS with Windows7 (RTM) and inspect sample. My question is: What went wrong and how to avoid this crash?

      Environment:

      - Windows7 RTM
      - Inspect sample from newest WDK (7600.16385.0)

      Full dump is available. Crash analysis:


      Loading Dump File [C:\Users\Frank\Desktop\MEMORY.DMP]
      Kernel Complete Dump File: Full address space is available

      Symbol search path is: SRV*p:\websymbols*http://msdl.microsoft.com/download/symbols;SRV*p:\websymbols*\\pegasus\download\symbols;M:\Symbols
      Executable search path is:
      Windows 7 Kernel Version 7600 MP (4 procs) Free x86 compatible
      Product: WinNt, suite: TerminalServer SingleUserTS
      Built by: 7600.16385.x86fre.win7_rtm.090713-1255
      Machine Name:
      Kernel base = 0x8280d000 PsLoadedModuleList = 0x82955810
      Debug session time: Mon Aug 10 20:55:57.934 2009 (GMT+2)
      System Uptime: 0 days 5:25:53.323
      Loading Kernel Symbols
      ...............................................................
      ................................................................
      ..........
      Loading User Symbols

      Loading unloaded module list
      ..................................................
      *******************************************************************************
      *                                                                             *
      *                        Bugcheck Analysis                                    *
      *                                                                             *
      *******************************************************************************

      Use !analyze -v to get detailed debugging information.

      BugCheck D1, {0, 2, 0, 88c95dad}

      Probably caused by : NETIO.SYS ( NETIO!NetioDereferenceNetBufferList+a2 )

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

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

      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: 00000000, memory referenced
      Arg2: 00000002, IRQL
      Arg3: 00000000, value 0 = read operation, 1 = write operation
      Arg4: 88c95dad, address which referenced memory

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


      READ_ADDRESS:  00000000

      CURRENT_IRQL:  2

      FAULTING_IP:
      tcpip!FlpReturnNetBufferListChain+35
      88c95dad 8b08            mov     ecx,dword ptr [eax]

      DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO

      BUGCHECK_STR:  0xD1

      PROCESS_NAME:  System

      TRAP_FRAME:  942d1ab0 -- (.trap 0xffffffff942d1ab0)
      ErrCode = 00000000
      eax=00000000 ebx=861fee30 ecx=856ad918 edx=829429c0 esi=861feed0 edi=ffffffac
      eip=88c95dad esp=942d1b24 ebp=942d1b38 iopl=0         nv up ei ng nz na pe nc
      cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286
      tcpip!FlpReturnNetBufferListChain+0x35:
      88c95dad 8b08            mov     ecx,dword ptr [eax]  ds:0023:00000000=????????
      Resetting default scope

      LAST_CONTROL_TRANSFER:  from 88c95dad to 828537eb

      STACK_TEXT: 
      942d1ab0 88c95dad badb0d00 829429c0 829428c0 nt!KiTrap0E+0x2cf
      942d1b38 88abfb48 861fee30 00000001 00000000 tcpip!FlpReturnNetBufferListChain+0x35
      942d1b58 88ac121c 84a83d70 00000000 00000000 NETIO!NetioDereferenceNetBufferList+0xa2
      942d1b88 88c97b40 00000000 00000000 00000000 NETIO!NetioDereferenceNetBufferListChain+0x3a
      942d1ba8 88c98fc0 8567e000 00000000 85647670 tcpip!IppCompleteAndFreePacketList+0xd7
      942d1bec 88c96b64 88cf8d98 00000011 84a83d70 tcpip!IppReceiveHeaderBatch+0x28c
      942d1c80 88cd3fad 861250f8 00000000 00000001 tcpip!IpFlcReceivePackets+0xbe5
      942d1ca0 88d60197 02000000 00000001 0000000b tcpip!IppInspectInjectReceive+0xca
      942d1cd8 931151b0 860be740 00000000 00000000 fwpkclnt!FwpsInjectTransportReceiveAsync0+0x1bc
      942d1d1c 931152fa 00000000 00000000 84cd8d48 inspect!TLInspectCloneReinjectInbound+0xc2 [p:\winddk\7600.16385.0\src\network\trans\inspect\sys\inspect.c @ 1033]
      942d1d50 82a1b66d 00000000 b388620e 00000000 inspect!TLInspectWorker+0xd2 [p:\winddk\7600.16385.0\src\network\trans\inspect\sys\inspect.c @ 1216]
      942d1d90 828cd0d9 93115228 00000000 00000000 nt!PspSystemThreadStartup+0x9e
      00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


      STACK_COMMAND:  kb

      FOLLOWUP_IP:
      NETIO!NetioDereferenceNetBufferList+a2
      88abfb48 85ff            test    edi,edi

      SYMBOL_STACK_INDEX:  2

      SYMBOL_NAME:  NETIO!NetioDereferenceNetBufferList+a2

      FOLLOWUP_NAME:  MachineOwner

      MODULE_NAME: NETIO

      IMAGE_NAME:  NETIO.SYS

      DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf63

      FAILURE_BUCKET_ID:  0xD1_NETIO!NetioDereferenceNetBufferList+a2

      BUCKET_ID:  0xD1_NETIO!NetioDereferenceNetBufferList+a2

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



    Answers

    • Thursday, February 25, 2010 8:02 PMBiao Wang [MSFT]<abbr class="affil">Microsoft</abbr><abbr class="affil">, Owner</abbr>Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       Answer
      Vote As Helpful
      Hi This is an update --

      We believe we had root-caused the issue behind the Inspect sample crashing on Win7 machines. In a nutshell it is a Tcpip/WFP interaction bug manifested by some raw socket listener changes made in Win7.

      As a workaround you can modify the sample such that packet is cloned from within classifyFn instead of referenced and clone outside of classifyFn.


      The sample's the approach (calling FwpsReferenceNetBufferList0 from classifyFn and then cloning it from the worker thread) makes it susceptible to the subtle changes introduced in Win7.

      If workaround is not desirable, you could also contact MSFT PSS for a hotfix.

      Thanks,
      Biao.W.

    All Replies

    • Friday, August 14, 2009 5:40 PMBiao Wang [MSFT]<abbr class="affil">Microsoft</abbr><abbr class="affil">, Owner</abbr>Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       
      Vote As Helpful
      Had the sample been modified?

      thanks,
      Biao.W.
    • Saturday, August 15, 2009 12:19 AMsmilish Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       
      Vote As Helpful
      No, the sample is unmodified. It's just the sample on a clean Windows 7. No third party software installed. 

      I can offer you to download the dump.

      Regards
      Frank
    • Saturday, August 15, 2009 1:12 AMBiao Wang [MSFT]<abbr class="affil">Microsoft</abbr><abbr class="affil">, Owner</abbr>Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       Proposed Answer
      Vote As Helpful

      Yes please send a email to wfp@microsoft.com with instructions on how to download the memory dmp.

      Thanks!
      Biao.W.

      • Proposed As Answer byshuishangxin Thursday, November 25, 2010 10:34 AM
      •  
    • Friday, August 28, 2009 6:39 AMxiaolin Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       Proposed Answer
      Vote As Helpful

      Any progress? My driver is working fine in Vista, but same problem happened in Windows 7. The call stack is the same as above. I can offer the kernel memory dump.

      Thanks
      xiaolin

      • Proposed As Answer byshuishangxin Thursday, November 25, 2010 10:34 AM
      •  
    • Wednesday, September 02, 2009 4:38 AMBiao Wang [MSFT]<abbr class="affil">Microsoft</abbr><abbr class="affil">, Owner</abbr>Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       
      Vote As Helpful
      is your driver re-using the same logic below? Does the ASSERT fire prior to the bugcheck?

         //

         // The TCP/IP stack could have retreated the net buffer list by the

         // transportHeaderSize amount; detect the condition here to avoid

         // retreating twice.

         //

         if (nblOffset != packet->nblOffset)

         {

            ASSERT(packet->nblOffset - nblOffset == packet->transportHeaderSize);

            packet->transportHeaderSize = 0;

         }

    • Thursday, February 25, 2010 8:02 PMBiao Wang [MSFT]<abbr class="affil">Microsoft</abbr><abbr class="affil">, Owner</abbr>Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
       Answer
      Vote As Helpful
      Hi This is an update --

      We believe we had root-caused the issue behind the Inspect sample crashing on Win7 machines. In a nutshell it is a Tcpip/WFP interaction bug manifested by some raw socket listener changes made in Win7.

      As a workaround you can modify the sample such that packet is cloned from within classifyFn instead of referenced and clone outside of classifyFn.


      The sample's the approach (calling FwpsReferenceNetBufferList0 from classifyFn and then cloning it from the worker thread) makes it susceptible to the subtle changes introduced in Win7.

      If workaround is not desirable, you could also contact MSFT PSS for a hotfix.

      Thanks,
      Biao.W.

    Monday, December 6, 2010 3:34 AM
  • no man can answer? Microsoft? Ameriacan?
    Monday, December 13, 2010 1:30 AM
  • The answer is in the thread:

    <sic>
       We believe we had root-caused the issue behind the Inspect sample crashing on Win7 machines. In a nutshell it is a Tcpip/WFP interaction bug 
       manifested by some raw socket listener changes made in Win7.

       As a workaround you can modify the sample such that packet is cloned from within classifyFn instead of referenced and clone outside of
       classifyFn.

       The sample's the approach (calling FwpsReferenceNetBufferList0 from classifyFn and then cloning it from the worker thread) makes it susceptible to the subtle changes introduced in Win7.

       If workaround is not desirable, you could also contact MSFT PSS for a hotfix.

       Thanks,
       Biao.W.
    </sic>

    In addition, please do not spam your posts in unrelated threads (Thanks).

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, January 5, 2011 6:59 PM
    Moderator
  • Hello,

    I believe that is not the fix for the bug in the inspect sample.

    If you want I can provide you with a stack trace and/or a dump.

    I believe there is a race condition somewhere between the classifyFn (reauth ACCEPT_RECV) and worker thread as the packet gets freed by one access later by the other and trying to get freed again. This is the way I get it reproduce time and time again.

    The supplied fix does not help. The bug still persists.

    If you want a memory dump with symbols please see this link:

    https://gamitech-eu-source-code-bucket.s3.amazonaws.com/Microsoft%20Inspect%20Sample%20crash/MicrosoftInspectSampleCrash2.zip

    or

    https://gamitech-eu-source-code-bucket.s3.amazonaws.com/Microsoft%20Inspect%20Sample%20crash/MicrosoftInspectSamplecrash.zip

     

    I would like to post a fix, patch anything myself but I started learning WFP a week ago. I am familiar with kernel code but never made NDIS driver or WFP filter.

    I would appreciate some support in providing a stable solution for this sample.

    Thank you.


    B.Gabriel
    Thursday, March 31, 2011 3:36 PM
  • Hi All,

    Has anyone got this working in Windows7 ?

    If this is solved, could you please point towards the solution?

    Thanks,

    Krishnanand

    Wednesday, June 29, 2011 12:22 PM
  • I believe Biao had the answer earlier.  Gabriel's stack looked like pool corruption, probably due to a double-free.  We did not have the opportunity to review his modified sources.

    Friday, September 30, 2011 10:01 PM
    Moderator