Sporadic access violation in driver

NTDEV
1

I’m guessing memory is getting corrupted, but nailing the problem down is not easy. I am writing a WFP callout driver. It is based heavily on the inspect example from the WDK if anyone is familiar with it.

This is the code that is providing the fault

NTSTATUS  
TLInspectCloneReinjectOutbound(  
 IN TL_INSPECT_PENDED_PACKET\* packet  
 )  
/\* ++  
  
This function clones the outbound net buffer list and reinject it back.  
  
-- \*/  
{  
 NTSTATUS status = STATUS_SUCCESS;  
 NET_BUFFER_LIST\* clonedNetBufferList = NULL;  
 FWPS_TRANSPORT_SEND_PARAMS0 sendArgs = {0};  
  
status = FwpsAllocateCloneNetBufferList0(  
 packet-\>netBufferList,  
 NULL,  
 NULL,  
 0,  
 &clonedNetBufferList  
 );

And the stack trace from windbg looks like

So the memory as 49c9ed3a is borked.

Not sure how as this points to a NetBufferList structure. As I say this is sporadic.

I turned on special pool but it’s not throwing any bugchecks.

Can anyone advice how to probe more deeply into this problem? Are there any windbg commands I could use? Could this be coded more defensively?

TIA

2

>I’m guessing memory is getting corrupted, but nailing the problem down is

not easy.

Definitely looks like a corruption.

ndis!NdisAllocateCloneNetBufferList+0xda:
8469cacc 8b5714 mov edx,dword ptr [edi+14h]
ds:0023:49c9ed3a=???

So, the code here is trying to dereference EDI+14, which evaluates to
49c9ed3a, which is definitely not a valid kernel address. It doesn’t look
like anything obviously meaningful (e,g, ASCII or unicode) so it’s hard to
make a guess as to the nature of the corruption. Looking at several
different crashes might start to show a pattern though.

Usually at this point what I do is switch to the context record (.cxr
0xffffffff8f0f7750), then try to work my way backwards to find out where EDI
came from. If you can identify the containing structure (is it one of the
parameters? What does !pool say?), you might be able to correlate it to one
of your structures, find out that it’s freed memory, etc.

Have you also tried enabling Verifier on NDIS?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

I’m guessing memory is getting corrupted, but nailing the problem down is
not easy. I am writing a WFP callout driver. It is based heavily on the
inspect example from the WDK if anyone is familiar with it.

This is the code that is providing the fault

NTSTATUS  
TLInspectCloneReinjectOutbound(  
 IN TL_INSPECT_PENDED_PACKET\* packet  
 )  
/\* ++  
  
This function clones the outbound net buffer list and reinject it back.  
  
-- \*/  
{  
NTSTATUS status = STATUS_SUCCESS;  
NET_BUFFER_LIST\* clonedNetBufferList = NULL;  
FWPS_TRANSPORT_SEND_PARAMS0 sendArgs = {0};  
  
status = FwpsAllocateCloneNetBufferList0(  
packet-\>netBufferList,  
NULL,  
NULL,  
0,  
&clonedNetBufferList  
);

And the stack trace from windbg looks like

So the memory as 49c9ed3a is borked.

Not sure how as this points to a NetBufferList structure. As I say this is
sporadic.

I turned on special pool but it’s not throwing any bugchecks.

Can anyone advice how to probe more deeply into this problem? Are there any
windbg commands I could use? Could this be coded more defensively?

TIA

3

Ah bummer I was hoping there were some set commands, or an “how to figure out what borked your memory” article. You sound like you know what you are doing, but these incantations in windbg spawn even more jubberish. Let me give you some examples of such.

When entering the command !pool 49c9ed3a I got this

So taking it’s advice I entered the command !poolval 49c9e000

and I got this

What’s so frustrating is that the driver essentially works, this is a sporadic error. The memory “packet” points to has to be ok as the ->direction property is tested first.

So the pointer to the netlistbuffer is what is borked.

Again there is no code that could break this. All linked lists are handled correctly, there are no race conditions, and like I said, verifier has special pool turned on for this driver.

If anyone could advise on how to unravel the gibberish in windbg to get to a root cause I would be grateful.

Really stumped here.

4

>Ah bummer I was hoping there were some set commands, or an "how to figure

out what borked your memory" article

It’s never that easy, is it? Maybe someday my skunkworks project to
implement the, “!fixthebug” command will produce results and make everyone’s
lives easier :slight_smile:

When entering the command !pool 49c9ed3a I got this

49c9ed3a is definitely bogus, no point in trying to make it feel even worse
about itself. The real question here is, “where did 0x49c9ed3a come from?”
In other words, what series of events led us to dereferencing this garbage?
If we can work backwards to a point in time where things worked, we may be
able to follow some clues that give us more hints about the corruption.

So, you’re faulting instruction is:

mov edx,dword ptr [edi+14h] ds:0023:49c9ed3a=???

And we know EDI has a bad value, so where did EDI come from? If we find the
containing structure that was used to retrieve this bad value we may be able
to identify something that makes sense. When we find the containing
register/location is when the !pool command comes in handy.

Again there is no code that could break this.

Best to go into these things assuming that it’s your bug :slight_smile:

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

Ah bummer I was hoping there were some set commands, or an “how to figure
out what borked your memory” article. You sound like you know what you are
doing, but these incantations in windbg spawn even more jubberish. Let me
give you some examples of such.

When entering the command !pool 49c9ed3a I got this

So taking it’s advice I entered the command !poolval 49c9e000

and I got this

What’s so frustrating is that the driver essentially works, this is a
sporadic error. The memory “packet” points to has to be ok as
the ->direction property is tested first.

So the pointer to the netlistbuffer is what is borked.

Again there is no code that could break this. All linked lists are handled
correctly, there are no race conditions, and like I said, verifier has
special pool turned on for this driver.

If anyone could advise on how to unravel the gibberish in windbg to get to a
root cause I would be grateful.

Really stumped here.

5

Hi Scott. Thanks for your reply. I understand I need to work backwards, find the containing structure etc etc.

Here’s the thing. I have no idea how to do this using WinDbg, which is why I came here and asked the question. :slight_smile:

Any chance you could either share some of the WinDbg incantations that I should be using, or point me at an article I could read which would explain the pertinent parts of the puzzle?

Thanks.

6

>Any chance you could either share some of the WinDbg incantations that I

should be using

No real special incantation. You can use the disassembly window to start
trying to work backwards (Alt+7 or View->Disassembly), though the usual
caveats of reading assembly apply in this fashion (i.e. this just represents
the surrounding assembly, not the actual instructions that were executed
prior to the crash).

An alternative would be to disassemble the entire function (uf
ndis!NdisAllocateCloneNetBufferList) and try to follow the path that led you
to the bad instruction.

I usually try to take the easy way and read backwards through the
disassembly, verifying my findings as a I go (to be honest, now that I can
use IDA Pro for kernel analysis I usually use that for this…Makes this
sort of thing much easier.).

If you can get me a copy of the dump somehow I can see if I can provide any
insight (no promises, but I might find something).

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

Hi Scott. Thanks for your reply. I understand I need to work backwards, find
the containing structure etc etc.

Here’s the thing. I have no idea how to do this using WinDbg, which is why I
came here and asked the question. :slight_smile:

Any chance you could either share some of the WinDbg incantations that I
should be using, or point me at an article I could read which would explain
the pertinent parts of the puzzle?

Thanks.

7

Any ideas how to persist this debugging session so I can send it to you? This is a live remote debugging session. I just went through all the menu options, googled and went through all the topics in the windbg help file. None the wiser.

8

Check out the “.dump” command.

Mm
On Aug 10, 2011 1:35 PM, wrote:
> Any ideas how to persist this debugging session so I can send it to you?
This is a live remote debugging session. I just went through all the menu
options, googled and went through all the topics in the windbg help file.
None the wiser.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

Particularly with the /f parameter, mini-dumps are useless.

Another option is .crash if you’ve already configured the target machine to
generate kernel or full memory dumps on crash.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…

Check out the “.dump” command.

Mm

On Aug 10, 2011 1:35 PM, wrote:
> Any ideas how to persist this debugging session so I can send it to you?
> This is a live remote debugging session. I just went through all the menu
> options, googled and went through all the topics in the windbg help file.
> None the wiser.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

10

Scott teaches seminars on debugging and cash dump analysis…

Just sayin’

Peter
OSR

11

to find something out of blue you would need a bit of patience to
decipher what appears to be gibberish :slight_smile:

anyway i dont know if what i post makes any meaning

but tracing back edi in a known function isnt all that difficult

so it crashes here
(ndis!NdisAllocateCloneNetBufferList+0x000000da

lets try dissassembling the whole function

(win7 ent eval output)

you can use this one liner to have a file that could always be open
independent of windbg

its bit of cryptic old dos usage it simply calls a copy file utility
to grab a locked file from temp folder dont ask me why i dont use -o
outfile param it didnt give me a datelinked folder name when i played
with it may be some one could simply and cut out all this dooz

aS resfol “.\scripts\hobocopy %tmp%
.\scriptresults\%DATE:~6,4%%date:~3,2%%date:~0,2%_%TIME:~1,1%Hr%TIME:~3,2%Min%TIME:~6,2%Sec
shl*.tmp”
.block
{
.shell -ci “uf /D ${$arg1}” ${resfol}
}
ad /q resfol

you get a file with control flow disassembly

F:\WINDBG\612WINDBG\SCRIPTRESULTS\2011_08_11_8HR51MIN11SEC
shl1.tmp

F:\windbg\612windbg\scriptresults\2011_08_11_8Hr51Min11Sec>grep -i “edx.*14” sh
l1.tmp
861eb948 8b5514 mov edx,dword ptr [ebp+14h]
861eba10 8b5714 mov edx,dword ptr [edi+14h]

F:\windbg\612windbg\scriptresults\2011_08_11_8Hr51Min11Sec>

so the line seems to be there

it takes a bit of time to look for patterns

if you back track the function

looking for edi a bit above

ndis!NdisAllocateCloneNetBufferList+0xda:
861eba10 8b5714 mov edx,dword ptr [edi+14h]

you can see edi is set up by ebx

861eb9e3 8b7b10 mov edi,dword ptr [ebx+10h]

since it is ebx + 10 we can try assuming ebx can be a pointer to
structure ??? structure ??

so if you go back a bit you can see ebx is initialized here

861eb952 8b5d08 mov ebx,dword ptr [ebp+8]

so it is taking some thing from stack that was passed on by an earlier
calls arguments

so this function takes 4 params

ndis!NdisAllocateCloneNetBufferList =

OffStart: 00004936
ProcSize: 0x28e
Prologue: 0x2b
Params: 0n4 (0x10 bytes)
Locals: 0n26 (0x68 bytes)
Non-FPO

lets google and see if we have a prototype

msdn has it

PNET_BUFFER_LIST NdisAllocateCloneNetBufferList(
in PNET_BUFFER_LIST OriginalNetBufferList,
 in_opt NDIS_HANDLE NetBufferListPoolHandle,
in_opt NDIS_HANDLE NetBufferPoolHandle,
 in ULONG AllocateCloneFlags
);

so ebp+8 is PNET_BUFFER_LIST OriginalNetBufferList,

kd> dt ndis!_NET_BUFFER_LIST
+0x000 Next : Ptr32 _NET_BUFFER_LIST
+0x004 FirstNetBuffer : Ptr32 _NET_BUFFER
+0x000 Link : _SLIST_HEADER
+0x008 Context : Ptr32 _NET_BUFFER_LIST_CONTEXT
+0x00c ParentNetBufferList : Ptr32 _NET_BUFFER_LIST
+0x010 NdisPoolHandle : Ptr32 Void
+0x018 NdisReserved : [2] Ptr32 Void
+0x020 ProtocolReserved : [4] Ptr32 Void
+0x030 MiniportReserved : [2] Ptr32 Void
+0x038 Scratch : Ptr32 Void
+0x03c SourceHandle : Ptr32 Void
+0x040 NblFlags : Uint4B
+0x044 ChildRefCount : Int4B
+0x048 Flags : Uint4B
+0x04c Status : Int4B
+0x050 NetBufferListInfo : [19] Ptr32 Void

ndis!NdisAllocateCloneNetBufferList+0x98:
861eb9ce 8b5b04 mov ebx,dword ptr [ebx+4]

ebx+4 should be

kd> dt ndis!_NET_BUFFER_LIST FirstNetBuffer->*
+0x004 FirstNetBuffer :
+0x000 Next : Ptr32 _NET_BUFFER
+0x004 CurrentMdl : Ptr32 _MDL
+0x008 CurrentMdlOffset : Uint4B
+0x00c DataLength : Uint4B
+0x00c stDataLength : Uint4B
+0x010 MdlChain : Ptr32 _MDL
+0x014 DataOffset : Uint4B
+0x000 Link : _SLIST_HEADER
+0x018 ChecksumBias : Uint2B
+0x01a Reserved : Uint2B
+0x01c NdisPoolHandle : Ptr32 Void
+0x020 NdisReserved : [2] Ptr32 Void
+0x028 ProtocolReserved : [6] Ptr32 Void
+0x040 MiniportReserved : [4] Ptr32 Void
+0x050 DataPhysicalAddress : _LARGE_INTEGER
+0x058 SharedMemoryInfo : Ptr32 _NET_BUFFER_SHARED_MEMORY
+0x058 ScatterGatherList : Ptr32 _SCATTER_GATHER_LIST

861eb9e3 8b7b10 mov edi,dword ptr [ebx+10h]

so edi should hold probably a pointer to

+0x010 MdlChain : Ptr32 _MDL

mdl pointer is corrupt in this crash

btw if you cant find patterns in txt file you can use IdaFree 5.0 to
generate a graph you would need to dump the bytes of this function and
load the raw bytes as bin file in metapc disassemble as 32 bit set up
entry point and then create function

you can use this script to dump the bytes
(dumping like this should normally be safe if uf worked

if uf borked earlier then function isnt contigious so dumping and ida
may not give correct results

here is the one liner to dump function bytes

.foreach /pS 7 /ps 100 (place {.shell -ci ".fnent ${$arg1} " grep -i
offstart} ) { r $t0 = ${$arg2} + place};
.foreach /pS 7 /ps 100 (place {.shell -ci ".fnent ${$arg1} " grep -i
procsize} ) { r $t1 = $t0 + place }
.writemem scriptresults${$arg1}dump.bin $t0 $t1

usage $$>a< scripts\callgraph.txt ndis!NdisAllocateCloneNetBufferList ndis

hope you can follow the methodology i hope my anlysis is correct

if some one finds some thing wrong please correct it so that this
thread doesnt contain
wrong info

On 8/11/11, xxxxx@osr.com wrote:
> Scott teaches seminars on debugging and cash dump analysis…
>
> Just sayin’
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
thanks and regards

raj_r

12

Thanks for all the responses. I read through raj_r’s excellent post with interest and had a go at rifling through the assembly language. I confess my assembly language is rusty at best, and when tracing up into a callout function I found it difficuly to map across the arguments being pushed onto the calling stack.

However I am convinced that the parent object (in this case called packet) is a valid pointer, and it is the nested struct Net_Buffer_List that is borked. When you consider that the code execution examines other properties on the packet object before routing out to the correct function, the packet object ptr must be valid.

So the question remains in my mind as to how the Net_Buffer_List, or rather it’s MDL pointer in this case got corrupted. Is it possible that it was borked to start with when the packet object was created in the callout function? Possibly.

Scott asked me to post the dump and I have here

http://dl.dropbox.com/u/25904236/pknox2.dmp

If you have the time Scott of course I would be greatful for any help.

@Peter : I did not know that Scott leads seminars in WinDBG, and I surely need to go on one. As I live in the UK, are these done online (webinar) or do I have to come to the states? Can someone send me a link to the details / costs?

Thanks

Charlie

13

I was hoping to find more than, “it’s hosed” for you, but my limited NDIS
experience is playing against me here. Maybe one of the NDIS experts will
have an idea.

(I’ll also note that I am officially in love with the NDIS KD
extensions…Why couldn’t all extensions be this pleasant?? Kudos to the
NDIS team.)

Again, the faulting instruction:

1: kd> r
Last set context:
eax=95baba28 ebx=8498808c ecx=b1934fb7 edx=00000000 esi=92740fa0
edi=49c9ed26
eip=84686acc esp=a010ac34 ebp=a010aca8 iopl=0 nv up ei pl nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010202
ndis!NdisAllocateCloneNetBufferList+0xda:
84686acc 8b5714 mov edx,dword ptr [edi+14h]
ds:0023:49c9ed3a=???

As raj pointed out, this value is ultimately coming from
NetBufferList->FirstNetBuffer->MdlChain, where the NetBufferList is the
first parameter passed to the function and located at EBP+8:

1: kd> !ndiskd.nbl poi(@ebp+8) -data
NET_BUFFER 8498808c
Skipping MDL 49c9ed26
[Next link in list is not readable; aborting the list traversal]
NET_BUFFER 886ed58c
NET_BUFFER 88d31ad4
Invalid NET_BUFFER_LIST at 00000002
[Next link in list is not readable; aborting the list traversal]

So, the passed in NetBufferList is toast. More specifically, the NetBuffers
in the NetBufferList are toast. As we see we get that bogus MDL address from
the first in the list:

1: kd> !ndiskd.nb 8498808c
NB 8498808c Next NB 886ed58c
Length 95baba28 Source Pool 00010000
First MDL 49c9ed26 DataOffset b1934fb7
Current MDL 85d6965c Current MDL Offset 0

However, the allocation containing the NetBufferList is a current WFP
allocation:

1: kd> !pool poi(@ebp+8) 2
Pool page 85d69658 region is Nonpaged pool
*85d69650 size: 38 previous size: f8 (Allocated) *Fwpp
Pooltag Fwpp : Windows Filtering Platform export driver., Binary :
fwpkclnt.sys

Thus, the containing allocation is OK but the contents are bad.

Unfortunately there’s not anything else to go on really from here. I scanned
the dump for a potential race condition, but didn’t find anything
interesting. Going back to what’s left of the NetBufferList in the hopes of
finding a clue, the !nbl command interpreted the Flags value without
complaint so it’s *possible* that the flags are real:

1: kd> !ndiskd.nbl poi(@ebp+8)
NBL 85d69658 Next NBL 00000002
First NB 8498808c Source 88d0e640
Flags 0000048f
↑ INDICATED, RETURNED, XLATED_TO_PACKET, UNXLATED,
IS_LOOPBACK_BUFFER,
NBL_CONTEXT_ALLOCATED
NblFlags 890bc138 [Unrecognized flags 890b0038]
↑ HD_SPLIT, SPLIT_AT_PAYLOAD, IS_LOOPBACK
Parent NBL 0000003b ChildRefCount 0n1104

→ Walk the NBL chain
→ Show out-of-band information
→ Dump the full data payload

Note that the NblFlags are bogus, so it’s possible that Flags are bogus too,
but since the extension didn’t complain I’m going to run with it. Knowing
nothing about any of this, the RETURNED flag seemed interesting because it
sounds sort of like it might be freed:

1: kd> !ndiskd.help RETURNED

FLAG
RETURNED

DESCRIPTION
This NBL is being returned to the miniport, or it has already been
returned
to the miniport.

Which might be suspicious. If I were to go further with this, I’d want to
look at some valid NBL structures at various states to see if this is what a
freed NBL actually looks like.

Have you checked the queue from which you removed this packet in your
driver? Are there other messed up NBLs on there or is this the only one?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

14

Hi Scott. Wow that’s really kind of you to look into this. Indeed the containing structure looks ok, and the contents garbage. Which gives me an idea. There is a function that instantiates the packet object which is called from the callout function. If I added a check in there, at the point of instantiation, then if the NBL was borked at that point it means WFP is throwing in some curved balls, and the memory corruption is not happening in the driver itself.

Wishful thinking on my part, but if this could be defensively coded around the packed could be disposed of cleanly, ie memory freed.

Yes this is indeed the only packet from the list that does this. For info, it is an outbound ALE reauth packet. Always, and every time and outbound ALE reauth packet, that contains the bogus MDL.

Perhaps there is some nuance within WFP that says sometimes NBLs for outbound ALE reauth packets sometimes have borked NBLs. Again wishful thinking.

15

Have you asked about this on the MSDN forum for WFP? Generally you get good
answers to WFP-specific questions there.

Thomas F. Divine. Sent from my Droid.
On Aug 12, 2011 12:42 PM, wrote:

16

@Thomas : I know the forum well and have posted in there in the past. Easily time I put something up there. Of course if I conclude something I will come back here with the answer.

17

tx scott for the confirmation

@suityou so let me finish

so back tracking a bit more we see the prior function is
fwpkclnt!FwpsAllocateCloneNetBufferList0

the call is here

fwpkclnt!FwpsAllocateCloneNetBufferList0+0x4d:
869765b6 ff7514 push dword ptr [ebp+14h]
869765b9 ff7510 push dword ptr [ebp+10h]
869765bc ff750c push dword ptr [ebp+0Ch]
869765bf 56 push esi
869765c0 ff152cd09786 call dword ptr
[fwpkclnt!_imp__NdisAllocateCloneNetBufferList (8697d02c)]
869765c6 8bd8 mov ebx,eax

so ebp+8 is esi in this function

if we backtrack we can see
esi i again taken from an earlier calls stack

86976573 8b7508 mov esi,dword ptr [ebp+8]

so lets look at another parent call

your crash shows it is code that you own

8f0f7d0c 94b6edab 94b75048 fffffffe 00000000
PKnox!TLInspectCloneReinjectOutbound+0x3e [c:\pkbuild\inspect.c @
1119]

since you said it was inspect.c lets see it in winddk.…\src

your function is at line 825 it seems in winddk

NTSTATUS
TLInspectCloneReinjectOutbound(
IN TL_INSPECT_PENDED_PACKET* packet
)

so it is TL_INSPECT_PENDED_PACKET

since you compiled it you should have the type info if not you can

or build this to get the type info

#include <ntddk.h>
#include “ndis.h”
#pragma warning(push)
#pragma warning(disable:4201)
#include “fwpsk.h”
#pragma warning(pop)
#include “fwpmk.h”
#include “inspect.h”
#include “utils.h”

TL_INSPECT_PENDED_PACKET tipp;

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING
pRegistryPath)
{
DbgPrint(“Hello World!\n”);
return STATUS_SUCCESS;
}

sources file
TARGETNAME=helloworld
TARGETTYPE=DRIVER
TARGETPATH=obj

INCLUDES=…..\inc

C_DEFINES=$(C_DEFINES) -DBINARY_COMPATIBLE=0 -DNT -DUNICODE -D_UNICODE
-DNDIS60 -DNDIS_SUPPORT_NDIS6

SOURCES = HelloWorld.c

build from win7 prompt
and use osrloader to set teh services to auto

so that you can have the type info

if you have typeinfo then you can set a conditional log breakpoint on
the line to log the packet

and may be you can narrow it down or observe patterns

kd> dt helloworld!TL_
helloworld!TL_INSPECT_PENDED_PACKET
helloworld!TL_INSPECT_PACKET_TYPE
helloworld!TL_INSPECT_PACKET_TYPE_
helloworld!TL_INSPECT_PENDED_PACKET_
kd> dt helloworld!TL_INSPECT_PENDED_PACKET
+0x000 listEntry : LIST_ENTRY
+0x008 addressFamily : Uint2B
+0x00c type : TL_INSPECT_PACKET_TYPE
+0x010 direction : FWP_DIRECTION_
+0x014 authConnectDecision : Uint4B
+0x018 completionContext : Ptr32 Void
+0x01c protocol : UChar
+0x020 netBufferList : Ptr32 NET_BUFFER_LIST
+0x024 compartmentId : COMPARTMENT_ID
+0x028 localAddr : FWP_BYTE_ARRAY16
+0x028 ipv4LocalAddr : Uint4B
+0x038 localPort : Uint2B
+0x038 icmpType : Uint2B
+0x03a remotePort : Uint2B
+0x03a icmpCode : Uint2B
+0x040 endpointHandle : Uint8B
+0x048 remoteAddr : FWP_BYTE_ARRAY16_
+0x048 ipv4RemoteAddr : Uint4B
+0x058 remoteScopeId : SCOPE_ID
+0x05c controlData : Ptr32 cmsghdr
+0x060 controlDataLength : Uint4B
+0x064 ipSecProtected : UChar
+0x068 nblOffset : Uint4B
+0x06c ipHeaderSize : Uint4B
+0x070 transportHeaderSize : Uint4B
+0x074 interfaceIndex : Uint4B
+0x078 subInterfaceIndex : Uint4B
kd> dt helloworld!TL_INSPECT_PENDED_PACKET netBufferList->
+0x020 netBufferList :
+0x000 Next : Ptr32 _NET_BUFFER_LIST
+0x004 FirstNetBuffer : Ptr32 _NET_BUFFER
+0x000 Link : _SLIST_HEADER
+0x008 Context : Ptr32 _NET_BUFFER_LIST_CONTEXT
+0x00c ParentNetBufferList : Ptr32 _NET_BUFFER_LIST
+0x010 NdisPoolHandle : Ptr32 Void
+0x018 NdisReserved : [2] Ptr32 Void
+0x020 ProtocolReserved : [4] Ptr32 Void
+0x030 MiniportReserved : [2] Ptr32 Void
+0x038 Scratch : Ptr32 Void
+0x03c SourceHandle : Ptr32 Void
+0x040 NblFlags : Uint4B
+0x044 ChildRefCount : Int4B
+0x048 Flags : Uint4B
+0x04c Status : Int4B
+0x050 NetBufferListInfo : [11] Ptr32 Void

if the dump would have been small i might have tried to find what is where

On 8/12/11, xxxxx@yahoo.co.uk wrote:
> @Thomas : I know the forum well and have posted in there in the past. Easily
> time I put something up there. Of course if I conclude something I will come
> back here with the answer.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
thanks and regards

raj_r</ntddk.h>