1. #1

    FwpsStreamInjectAsync0 bug/leak - Bitdefender (0x4A)

    We've all seen it, Bitdefender's protection process involved in an otherwise blank 0x4A bug check. After all this time of still seeing it, I investigated it to see what the issue really is as I knew it couldn't have just been the user's fault as it was consistent, and the crashes stopped after removing Bitdefender.

    First off, taking a look at a non-verifier enabled kernel dump, here's our bug check as discussed:

    10: kd> .bugcheck  
    Bugcheck code 0000004A  
    Arguments 00000000`77a1dc2a 00000000`00000002 00000000`00000000 fffff880`13695b60
    0x4A bug check, essentially implying that the thread which was previously involved in a system call attempted to return to user mode at an IRQL higher than PASSIVE_LEVEL (zero [0] on x86 and x64).

    10: kd> !irql  
    Debugger saved IRQL for processor 0xa -- 2 (DISPATCH_LEVEL)
    In this case, at the time of the crash, the IRQL was DISPATCH_LEVEL (Two [2] on x86 and x64).

    The process involved in the IRQL raise was vsserv.exe, Bitdefender's main active protection process.

    Let's also go further and dump the address of the system function involved:

    10: kd> !address 0000000077a1dc2a  
    Usage:         VAD  
    Base Address:      00000000`779d0000  
    End Address:      00000000`77b79000  
    Region Size:      00000000`001a9000  
    VA Type:        UserRange  
    VAD Address:      0xfffffa8020d1f830  
    Commit Charge:     0xd  
    Protection:       0x7 [ReadWriteCopyExecute]  
    Memory Usage:      Section [\Windows\System32\ntdll.dll]  
    No Change:       no  
    More info:       !vad 0x779d0000
    We can see its VA type is UserRange, its protection is 0x7 which implies it's R/W/X (or E).

    If we run !vad on the VAD Address field, we can see frequent mention of Bitdefender:

    10: kd> !vad 0xfffffa8020d1f830  
    fffffa8018c95a70 ( 2)  7fee7980 7fee79c8     6 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\mimepack.dll  
    fffffa802278cb70 ( 3)  7fee79d0 7fee7aa2    69 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\asregex.dll  
    fffffa8018c944e0 ( 0)  7fee7ab0 7fee7bb9     9 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\asmcocr.dll  
    fffffa804d4baa50 ( 2)  7fee7bc0 7fee7dea    259 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\asunicode.dll  
    fffffa8022f25450 ( 3)  7fee7df0 7fee810b    89 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\asemlthin.mdl  
    fffffa8050690e60 ( 1)  7fee8110 7fee8333    86 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\asemlrtr.mdl  
    fffffa8018c0b1e0 ( 2)  7fee8340 7fee8442    81 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\asengines_00015_008\ascore.dll  
    fffffa804f4f7970 ( 3)  7fee8550 7fee8622    69 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\asregex.dll  
    fffffa804e14ff80 (-1)  7fee8630 7fee885a    259 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\asunicode.dll  
    fffffa804f509640 ( 2)  7fee8860 7fee89ef    82 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\ashttprbl.mdl  
    fffffa804f4bfc80 ( 3)  7fee89f0 7fee8cc9    88 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\ashttpph.mdl  
    fffffa80232c0460 ( 1)  7fee8cd0 7fee8dca    82 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\ashttpdsp.mdl  
    fffffa804ce69120 ( 3)  7fee8dd0 7fee8edb    81 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\ashttpbr.mdl  
    fffffa804ce52bb0 ( 2)  7fee8ee0 7fee8fe2    81 Mapped Exe EXECUTE_WRITECOPY \Program Files\Bitdefender\Bitdefender 2015\otengines_00350_006\otcore.dll  
    Let's use !address and -v together to get nice verbose PTE/PFN/VAD information:

    10: kd> !address -v -map 0x779d0000  
    PXE:  fffff6fb7dbed000 [contains 02e0000763d62867]  
        Page Frame Number: 763d62, at address: fffffa80162b8260  
        Page Location:   6 (ActiveAndValid)  
        PTE Frame:     0000000000763e3c  
        Attributes:     M:Modified,Cached  
        Usage:       PPEs Process fffffa8020d96b10 [vsserv.exe], Entries:5  
    PPE:  fffff6fb7da00008 [contains 18700007641ad867]  
        Page Frame Number: 7641ad, at address: fffffa80162c5070  
        Page Location:   6 (ActiveAndValid)  
        PTE Frame:     0000000000763d62  
        Attributes:     M:Modified,Cached  
        Usage:       PDEs Process fffffa8020d96b10 [vsserv.exe], Entries:31  
    PDE:  fffff6fb40001de0 [contains 0370000764ab6867]  
        Page Frame Number: 764ab6, at address: fffffa80162e0220  
        Page Location:   6 (ActiveAndValid)  
        PTE Frame:     00000000007641ad  
        Attributes:     M:Modified,Cached  
        Usage:       PTEs Process fffffa8020d96b10 [vsserv.exe], Entries:159  
    PTE:  fffff680003bce80 [contains 82a000079e2d4025]  
        Page Frame Number: 79e2d4, at address: fffffa8016da87c0  
        Page Location:   6 (ActiveAndValid)  
        PTE Frame:     000000000079ec0c  
        Attributes:     P:Prototype,Cached  
        Usage:       MappedFile CA:fffffa801f3a3010 [\Windows\System32\ntdll.dll]  
    Type:  Valid  
    Attrs: Private,NormalPage,NotDirty,NotDirty1,Accessed,User,NotWritable,NotWriteThrough  
    PFN:  79e2d4
    Overall, we can see vsserv.exe is listed as active and valid within the page regarding its location, as well as ntdll being involved with memory usage:

    10: kd> !vad 0x779d0000  
    VAD       level   start   end  commit  
    fffffa8020d1f830 (-1)    779d0   77b78    13 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll
    Throughout all of the 0x4A Bitdefender related crashes, the NT kernel was labeled as the fault:

    Probably caused by : ntkrnlmp.exe
    Given we're seeing ntdll, we can likely imagine the reason for the NT kernel being blamed as being the fault of the crash is because most of the API from ntdll is implemented in the NT kernel variants, with this being ntkrnlmp.exe because this system has a multi-processor without physical address extension configuration.

    10: kd> vertarget  
    Windows 7 Kernel Version 7601 (Service Pack 1) MP (12 procs) Free x64  
    Product: WinNt, suite: TerminalServer SingleUserTS  
    Built by: 7601.18839.amd64fre.win7sp1_gdr.150427-0707  
    Machine Name:  
    Kernel base = 0xfffff800`03064000 PsLoadedModuleList = 0xfffff800`032ab730  
    Debug session time: Fri May 15 09:00:27.644 2015 (UTC - 4:00)  
    System Uptime: 0 days 16:20:00.892
    So regarding processor #10, that's probably as far as we're going to go considering it's the bug check thread and there's no information really whatsoever:

    10: kd> k  
    Child-SP     RetAddr      Call Site  
    fffff880`13695928 fffff800`030d7e69 nt!KeBugCheckEx  
    fffff880`13695930 fffff800`030d7da0 nt!KiBugCheckDispatch+0x69  
    fffff880`13695a70 00000000`77a1dc2a nt!KiSystemServiceExit+0x245  
    00000000`2798f908 00000000`00000000 0x77a1dc2a
    All we can see if we're exiting user-mode code using the KiSystemServiceExit function, and we go off the rails right there - KiSystemServiceExit+0x245. This function is in charge of handling the various call-styles used to enter kernel-mode, and then returning to user-mode.

    With that said, let's switch to the other processor within the system that was involved and see what's going on at the time of the crash. To find out the active processors on the specific system, we'll use !running:

    10: kd> !running  
    System Processors: (0000000000000fff)  
     Idle Processors: (00000000000003ff) (0000000000000000) (0000000000000000) (0000000000000000)  
        Prcbs       Current     (pri) Next      (pri) Idle  
     10  fffff880038c9180 fffffa8021c85b50 ( 9)            fffff880038d41c0 ................  
     11  fffff8800393b180 fffffa8021c91060 ( 9)            fffff880039461c0 ................
    We can see our processors are #10 and #11. We've explored #10, so let's check #11. The reason 0-9 aren't listed is because they're idle.

    11: kd> knL
     # Child-SP          RetAddr           Call Site
    00 fffff880`03969e20 fffff880`0584f75e e1c62x64+0x558e
    01 fffff880`03969e50 fffff880`0584ff1f e1c62x64+0x2075e
    02 fffff880`03969ec0 fffff880`0584fb43 e1c62x64+0x20f1f
    03 fffff880`03969f70 fffff880`0584fa49 e1c62x64+0x20b43
    04 fffff880`03969fa0 fffff800`0301f62f e1c62x64+0x20a49
    05 fffff880`03969fe0 fffff880`01a0c600 hal!HalBuildScatterGatherList+0x203
    06 fffff880`0396a050 fffff880`0584ffb2 ndis!NdisMAllocateNetBufferSGList+0x110
    07 fffff880`0396a0f0 fffff880`05850649 e1c62x64+0x20fb2
    08 fffff880`0396a150 fffff880`0585028e e1c62x64+0x21649
    09 fffff880`0396a1b0 fffff880`01ac84f1 e1c62x64+0x2128e
    0a fffff880`0396a1f0 fffff880`01a0c4d4 ndis!ndisMSendNBLToMiniport+0xb1
    0b fffff880`0396a250 fffff880`05c6d6b8 ndis!NdisFSendNetBufferLists+0x64
    0c fffff880`0396a290 fffff880`05c6d92c bdfndisf6+0x16b8
    0d fffff880`0396a2f0 fffff880`05c6df4b bdfndisf6+0x192c
    0e fffff880`0396a380 fffff880`01a0c4d4 bdfndisf6+0x1f4b
    0f fffff880`0396a480 fffff880`00c16199 ndis!NdisFSendNetBufferLists+0x64
    10 fffff880`0396a4c0 fffff880`01a0c419 pacer!PcFilterSendNetBufferLists+0x29
    11 fffff880`0396a5c0 fffff880`01ac85d5 ndis!ndisSendNBLToFilter+0x69
    12 fffff880`0396a620 fffff880`01c60eb6 ndis!NdisSendNetBufferLists+0x85
    13 fffff880`0396a680 fffff880`01c67895 tcpip!IpNlpFastSendDatagram+0x496
    14 fffff880`0396aa30 fffff880`01c68450 tcpip!TcpTcbSend+0x495
    15 fffff880`0396acb0 fffff880`01c671a8 tcpip!TcpEnqueueTcbSendOlmNotifySendComplete+0xa0
    16 fffff880`0396ace0 fffff880`01b30267 tcpip!TcpEnqueueTcbSend+0x258
    17 fffff880`0396ad90 fffff880`01b35f5d NETIO!StreamInjectRequestsToStack+0x287
    18 fffff880`0396ae60 fffff880`01b376b4 NETIO!StreamPermitDataHelper+0x5d
    19 fffff880`0396ae90 fffff800`030e41dc NETIO!StreamPermitRemoveDataDpc+0x84
    1a fffff880`0396af00 fffff800`030db335 nt!KiRetireDpcList+0x1bc
    1b fffff880`0396afb0 fffff800`030db14c nt!KyRetireDpcList+0x5
    1c fffff880`13abf190 fffff800`0312371c nt!KiDispatchInterruptContinue
    1d fffff880`13abf1c0 fffff800`030c2aec nt!KiDpcInterrupt+0xcc
    1e fffff880`13abf350 fffff880`01b383aa nt!KeInsertQueueDpc+0x1dc
    1f fffff880`13abf3e0 fffff880`01b3b468 NETIO!StreamPermitData+0x13a
    20 fffff880`13abf450 fffff880`01b3b99a NETIO!StreamInternalClassify+0x1a8
    21 fffff880`13abf520 fffff880`01b3bd8e NETIO!StreamInject+0x1ca
    22 fffff880`13abf5f0 fffff880`01b91df3 NETIO!FwppStreamInject+0x12e
    23 fffff880`13abf680 fffff880`05c9aaf1 fwpkclnt!FwpsStreamInjectAsync0+0xcf
    24 fffff880`13abf6e0 fffff880`05c9bce3 bdfwfpf+0x2af1
    25 fffff880`13abf780 fffff880`05ca469c bdfwfpf+0x3ce3
    26 fffff880`13abf7c0 fffff880`05ca4d0a bdfwfpf+0xc69c
    27 fffff880`13abf840 fffff880`05c9ebb3 bdfwfpf+0xcd0a
    28 fffff880`13abf8a0 fffff800`033f3e47 bdfwfpf+0x6bb3
    29 fffff880`13abf8d0 fffff800`033f46a6 nt!IopXxxControlFile+0x607
    2a fffff880`13abfa00 fffff800`030d7b53 nt!NtDeviceIoControlFile+0x56
    2b fffff880`13abfa70 00000000`77a1dc2a nt!KiSystemServiceCopyEnd+0x13
    2c 00000000`27a9f928 00000000`00000000 0x77a1dc2a
    I used knL as opposed to the other stack dump commands as I wanted to get the frame # feature for reference reasons.

    Starting at frame # 2a, we can see the NtDeviceIoControlFile function calls IopXxxControlFile. The latter function appears to be undocumented, so I'm unsure as to what it does. What I do know is, the NtDeviceIoControlFile function is ultimately used to build descriptors for a driver. I imagine it's using the IopXxxControlFile function to aid in passing such to the driver.

    Also, for what it's worth, although NtDeviceIoControlFile has since been superseded by DeviceIoControl, the former native function provides more information that may be beneficial to the caller (especially for debugging purposes). This is likely why Bitdefender chose to use the former function instead.

    11: kd> ln nt!IopXxxControlFile  
    (fffff800`033f3840)  nt!IopXxxControlFile   
    (fffff800`033f4650)  nt!NtDeviceIoControlFile  
    Exact matches:  
      nt!IopXxxControlFile (<no parameter info>)
    If we disassemble this function, we can wade through some of the stuff and find some of the interesting tidbits:

    11: kd> u fffff800`033f3840 fffff800`033f4650  
    fffff800`033f3956 e845c5ffff   call  nt!ProbeForWrite (fffff800`033efea0)  
    fffff800`033f39b7 e81498fdff   call  nt!ObReferenceObjectByHandleWithTag (fffff800`033cd1d0)  
    fffff800`033f3b05 e84688cfff   call  nt!IoGetRelatedDeviceObject (fffff800`030ec350)  
    fffff800`033f402a e8d130cdff   call  nt!IoGetAttachedDevice (fffff800`030c7100)  
    fffff800`033f3c01 e88a7bcfff   call  nt!IoAllocateIrp (fffff800`030eb790)  
    fffff800`033f40d1 e82af9cfff   call  nt!IoAllocateMdl (fffff800`030f3a00)
    So after neatly putting together this disassembly of sorts, we can see that this is indeed how the NtDeviceIoControlFile function is passing on the buffer and such to the driver.

    The IoAllocateMdl function in this specific case is used to ultimately associate the MDL with an IRP, which is why we call into the IoAllocateIrp function, to of course assign the IRP. IoGetAttachedDevice is called likely to return a pointer to the devobj, with help from the IoGetRelatedDeviceObject function to probably obtain the devobj from the file system driver stack.

    ObReferenceObjectByHandleWithTag is called to increment the reference count of the object, and to write a four-byte value known as a "tag" so it can support object reference tracing for debugging purposes. Finally, the ProbeForWrite function is called to ensure that a user-mode buffer meets the following:

    • Resides in the user-mode portion of the address space.

    • Is writeable.

    • Is correctly aligned.

    As all appears to have went well, we can see the driver we were ultimately building and passing descriptors to/for was bdfwfpf.sys, which is Bitdefender's firewall filter driver. As it's a driver in charge of a firewall, it of course uses the WFP API (Windows Filtering Platform) to achieve its goals (not just filtering and monitoring).

    We can confirm this easily by looking at the very first driver/function call after Bitdefender's firewall, which is fwpkclnt.sys. Specifically, Bitdefender's firewall driver called it to inject new/cloned data to the data stream. Directly afterwords we have calls from the Network I/O Subsystem to continue the injecting, which is because fwpkclnt.sys exports kernel-mode functions, as opposed to fwpuclnt.dll which exports and handles the user-mode side.

    To handle and/or continue the injection into the data stream, it looks like DPC(s) are used to handle it by calling KeInsertQueueDpc to create a queued DPC for execution.

    11: kd> !dpcs
    CPU Type      KDPC       Function
    10: Normal  : 0xfffffa806a7b7cb0 0xfffff88001b37630 NETIO!StreamPermitRemoveDataDpc
    After discussion with Jared, we also thought that the IRQL was possibly DISPATCH_LEVEL due to the multiple injections, etc, therefore Windows deferred it to a DPC. Given this possibly being the case, when the DPC was to be worked on, the system service finished but the IRQL is still DISPATCH_LEVEL. Since that was the case, we get a bug check.

    We continue through netio.sys' functions regarding the data stream injection, ultimately injecting the request to the stack and going through a few tcpip.sys functions.

    To continue sending the data along, NDIS' NdisSendNetBufferLists function is called, and NDIS' filter driver (which I believe is pacer.sys), called NdisFSendNetBufferLists to send the list of network data buffers back to Bitdefender's firewall driver.

    Bitdefender's firewall driver then calls into NDIS' network data buffer sending functions to send the list to the user's network miniport driver, e1c62x64.sys (Intel(R) 82579V Gigabit Network Connection). The network miniport driver then calls NDIS' NdisMAllocateNetBufferSGList function to obtain a scatter/gather list for the network data for the associated NET_BUFFER structure.

    In order to do so, NDIS needs to call the HAL, which we can see through the function HalBuildScatterGatherList. What is supposed to happen next is, the HAL builds the scatter/gather list, and we go on through various registered miniport functions. However, this did not happen, and we go off the rails on frame #00 with a call to the miniport driver.

    So, where's our problem? Frame #23:

    23 fffff880`13abf680 fffff880`05c9aaf1 fwpkclnt!FwpsStreamInjectAsync0+0xcf
    FwpsStreamInjectAsync0, the function in charge of injecting TCP data segments into a TCP data stream, is the issue. How so? Well, let's get dirty once again.

    Using the NDIS debugging extension (!ndiskd), we can get a lot of information to help us here. On its lonesome, !ndiskd isn't too special. However, when we use !ndiskd.miniport, it gets fun.

    11: kd> !ndiskd.miniport  
      MiniDriver     Miniport      Name                   
      fffffa8020c71cd0  fffffa8018c281a0  RAS Async Adapter  
      fffffa801f844cd0  fffffa801f8771a0  SonicWALL NetExtender Adapter  
      fffffa801f862840  fffffa801f86b1a0  WAN Miniport (SSTP)  
      fffffa801f84bb70  fffffa801f8671a0  WAN Miniport (PPTP)  
      fffffa801f837c30  fffffa801f8631a0  WAN Miniport (PPPOE)  
      fffffa801f8409b0  fffffa801f85e1a0  WAN Miniport (IPv6)  
      fffffa801f8409b0  fffffa801f85a1a0  WAN Miniport (IP)  
      fffffa801f8409b0  fffffa801f8561a0  WAN Miniport (Network Monitor)  
      fffffa801f835cd0  fffffa801f8411a0  WAN Miniport (L2TP)  
      fffffa801f82f820  fffffa801f83d1a0  WAN Miniport (IKEv2)  
      fffffa801f664020  fffffa801f7b81a0  Intel(R) 82579V Gigabit Network Connection  
      fffffa801f5cb9e0  fffffa801f5e61a0  Teredo Tunneling Pseudo-Interface  
      fffffa801f5cb9e0  fffffa801f5e21a0  Microsoft ISATAP Adapter #2  
      fffffa801f5cb9e0  fffffa801f5de1a0  Microsoft ISATAP Adapter  
      fffffa801f5cb9e0  fffffa801f5d61a0  Microsoft 6to4 Adapter
    So we know that our miniport involved in all of this was the Intel Gigabit, so let's look at that one:

    11: kd> !ndiskd.minidriver fffffa801f664020  
      Ndis handle    fffffa801f664020  
      Driver Context   NULL  
      DRIVER_OBJECT   fffffa801f7b6e70  
      Driver image    e1c62x64.sys  
      Registry path   \REGISTRY\MACHINE\SYSTEM\ControlSet001\services\e1cexpress  
      Reference Count  2  
      Flags       [No flags set]  
      fffffa801f7b81a0 - Intel(R) 82579V Gigabit Network Connection
    If we take a look at the miniport address:

    11: kd> !ndiskd.miniport fffffa801f7b81a0  
      Intel(R) 82579V Gigabit Network Connection  
      Ndis handle    fffffa801f7b81a0  
      Ndis API version  v6.20  
      Adapter context  fffffa801f990000  
      Miniport driver  fffffa801f664020 - e1cexpress v12.6  
      Network interface fffffa8019c8c870  
      Media type     802.3  
      Device instance  PCI\VEN_8086&DEV_1503&SUBSYS_849C1043&REV_06\3&11583659&0&C8  
      Device object   fffffa801f7b8050  More information  
      MAC address    e0-3f-49-78-a1-dd
      Miniport      Running  
      Device PnP     Started  
      Datapath      Normal  
      Interface     Up  
      Media       Connected  
      Power       D0  
      References     0n10  
      Total resets    0  
      Pending OID    None  
      Protocol list   Driver       Open        Context        
      RSPNDR       fffffa8021b39cf0  fffffa8021b608d0  fffffa8021b62010  
      LLTDIO       fffffa8021b1a8f0  fffffa8021b528d0  fffffa8021b361b0  
      TCPIP6       fffffa801d05c2c0  fffffa801fb13010  fffffa801fb0b010  
      TCPIP       fffffa8019c7b890  fffffa801fb08580  fffffa801fb03ba0  
      Filter list    Driver       Module       Context        
      WFP LightWeight Filter-0000  
                fffffa801f59f010  fffffa801faff660  fffffa801faff400  
      QoS Packet Scheduler-0000  
                fffffa801f5ab930  fffffa801fb00780  fffffa801f9d3010  
      BitDefender Firewall NDIS6 Filter Driver-0000  
                fffffa801f574d40  fffffa801fb04c80  fffffa801fb04850
    We get a lot of good information, and can see that Bitdefender's firewall filter driver is/was involved with this miniport. We know this, because we saw it all happening in the stack, but this just confirms it.

    Anyway, what's next? Well, let's check for any pending NBLs (NET_BUFFER_LISTS):

    11: kd> !ndiskd.pendingnbls fffffa801f7b81a0  
    PHASE 1/3: Found 23 NBL pool(s).           
    PHASE 2/3: Found 512 freed NBL(s).                    
      Pending Nbl    Currently held by                      
      fffffa80593c82c0  fffffa801f7b81a0 - Intel(R) 82579V Gigabit Network Connection [Miniport]            
    PHASE 3/3: Found 1 pending NBL(s) of 789 total NBL(s).             
    Search complete.
    Ah ha, we have one held by the miniport driver that was involved in passing data to Bitdefender's firewall filter driver. Let's look at the pending NBL:

    11: kd> !ndiskd.nbl fffffa80593c82c0  
      NBL        fffffa80593c82c0  Next NBL      NULL  
      First NB      fffffa80593c83f0  Source       fffffa801fb08580 - TCPIP
    From here we can take a direct look at the NBL:

    11: kd> dt _NET_BUFFER_LIST fffffa80593c82c0  
      +0x000 Next       : (null)   
      +0x008 FirstNetBuffer  : 0xfffffa80`593c83f0 _NET_BUFFER  
      +0x000 Link       : _SLIST_HEADER  
      +0x010 Context     : 0xfffffa80`593c84a0 _NET_BUFFER_LIST_CONTEXT  
      +0x018 ParentNetBufferList : (null)   
      +0x020 NdisPoolHandle  : 0xfffffa80`1cfe6080 Void  
      +0x030 NdisReserved   : [2] (null)   
      +0x040 ProtocolReserved : [4] 0x746c6100`00000001 Void  
      +0x060 MiniportReserved : [2] 0xfffffa80`1f990000 Void  
      +0x070 Scratch     : (null)   
      +0x078 SourceHandle   : 0xfffffa80`1fb08580 Void  
      +0x080 NblFlags     : 0  
      +0x084 ChildRefCount  : 0n0  
      +0x088 Flags      : 0x100  
      +0x08c Status      : 0n0  
      +0x090 NetBufferListInfo : [19] 0x00000000`00220015 Void
    What appears to be happening here is multiple NBLs in a chain are being passed, the FwpsStreamInjectAsync0 function is called to pass Bitdefender's data, and then the chain is broken as the call goes on (see the NBL next member is zeroed out/null).

    Possibly a fix (in Bitdefender's case) is to avoid multiple injections inside the stream callout routine, possibly taking NBLs in a chain and calling the FwpsStreamInjectAsync0 function just ONCE for each callout routine execution. Unsure, kernel development isn't my strong point : ) It's not Bitdefender's fault as this is a Windows bug apparently, anyway.

    A fix for user's is to install this hotfix and hope it works, as it should. Overall, maybe Bitdefender instead of making any developmental changes could just raise awareness for this issue, like creating a well explained documentation page with a link to the hotfix.
    Last edited by Patrick; 05-24-2015 at 07:45 PM.
    niemiro, x BlueRobot, Gi0 and 2 others say thanks for this.

    • Ad Bot



Similar Threads

  1. Im getting BSOD after installing bitdefender 2015 suite? Windows 7 x64
    By thelaughingman in forum BSOD, Crashes, Kernel Debugging
    Replies: 4
    Last Post: 05-17-2015, 10:47 AM
  2. Replies: 0
    Last Post: 03-02-2015, 02:28 AM
  3. 0x7F memory leak
    By Jared in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 9
    Last Post: 07-10-2014, 09:13 AM
  4. Replies: 0
    Last Post: 06-26-2012, 04:44 PM
  5. Replies: 1
    Last Post: 06-24-2012, 07:09 PM

Log in

Log in