unable to figure out how a windbg extension work

Question

I'm trying to figure out how the below windbg extension works

!ndiskd.nbl  addr  -hexcap(or -data)

kd> !ndiskd.nbl ffffce8c96bde070 -hexcap
# NET_BUFFER_LIST    ffffce8c96bde070
# NET_BUFFER     ffffce8c96bde1f0
# MDL    ffffce8c96bde2c8
00000000       30 39 20 b1 97 42 11 bb 00 00 20 b2 60 12 ff 70
00000010       34 b7 00 00

This looks quite fine because it starts with the header. The address is ffffce8c96bde3f4. But I'm unable to find or compute the value with elements in the structures. So I take a deep look at associated structs.

NET_BUFFER_LIST
   +0x000 Next             : NULL
   +0x008 FirstNetBuffer   : Oxffffce8c'96bde1f0
   +0x000 Link             : _SLIST_HEADER
   +0x000 NetBufferListHeader : _NET_BUFFER_LIST_HEADER
   +0x010 Context          : Oxffffce8c'96bde2a0 _NET_BUFFER_LIST_CONTEXT
   +0x018 ParentNetBufferList : NULL
   +0x020 NdisPoolHandle   : ...
   +0x030 NdisReserved     : ...
   +0x040 ProtocolReserved : ...
   +0x060 MiniportReserved : ...
   +0x070 Scratch          : ...
   +0x078 SourceHandle     : ...
   +0x080 NblFlags         : ...
   +0x084 ChildRefCount    : ...
   +0x088 Flags            : ...
   +0x08c Status           : ...
   +0x08c NdisReserved2    : ...
   +0x090 NetBufferListInfo : ...

FirstNetBuffer. The MDL is where system store data

NET_BUFFER
   +0x000 Next             : NULL
   +0x008 CurrentMdl       : ffffce8c96bde2c8
   +0x010 CurrentMdlOffset : 0xec
   +0x018 DataLength       : 0x14
   +0x018 stDataLength     : 0x14   //The length, in bytes, of the used data space in the MDL chain
   +0x020 MdlChain         : ffffce8c96bde2c8
   +0x028 DataOffset       : 0xec
   +0x000 Link             : _SLIST_HEADER
   +0x000 NetBufferHeader  : _NET_BUFFER_HEADER
   +0x030 ChecksumBias     : ...
   +0x032 Reserved         : ...
   +0x038 NdisPoolHandle   : ...
   +0x040 NdisReserved     : ...
   +0x050 ProtocolReserved : ...
   +0x080 MiniportReserved : ...
   +0x0a0 DataPhysicalAddress : ...
   +0x0a8 SharedMemoryInfo : ...
   +0x0a8 ScatterGatherList : ...

CurrentMdl

MDL 
   +0x000 Next             : NULL
   +0x008 Size             : 0n56
   +0x00a MdlFlags         : 0n4
   +0x00c AllocationProcessorNumber : ...
   +0x00e Reserved         : ...
   +0x010 Process          : Ptr64 _EPROCESS
   +0x018 MappedSystemVa   : Oxffffce8c'96bde308
   +0x020 StartVa          : Oxffffce8c'96bde000
   +0x028 ByteCount        : 0x100
   +0x02c ByteOffset       : 0x308

OK. Now from MDL I know that system allocates 0x100 bytes for the data. And the first around 0x70 are 0s which is normal. Like I said the data starts with ffffce8c96bde3f4, if I use the Mdloffset(ec) and currentMdl(ffffce8c96bde2c8), I get ffffce8c96bde3b4. The difference is 0x40. But with all the values, I don't know where the 0x40 comes from. What might be the problem?

Answer 1

The buffer is printed from CurrentMdl->MappedSystemVa+CurrentMdlOffset upto Size-CurrentOffset

When there is an MDLChain the data is printed for all Next->MappedSystemVa

And when posting output from windbg do not edit and insert your own address in the first dump the address starts from 0 but it should start from 308+ec == 3f4

I could have answered this earlier if i saw 3f4 i was not sure how 00000000 came there so i had to verify before posting

The output from !nbl xxxx -data actually outputs the correct address not some 0x00000000

a sample output

0: kd> .lastevent
Last event: Hit breakpoint 0
  
0: kd> r
ndis!NdisSendNetBufferLists:
fffff802`373b2460 44894c2420      mov     dword ptr [rsp+20h],r9d ss:0018:fffff802`38077048=00000000

0: kd> !nbl @rdx -data
NET_BUFFER ffffcb8dc6f83600
  MDL ffffcb8dc65f1180
    ffffcb8dc65f11e2  33 33 00 00 00 16 00 0c-29 45 de 6c 86 dd 60 00  33······)E·l··`·
    ffffcb8dc65f11f2  00 00 00 24 00 01 fe 80-00 00 00 00 00 00 db 08  ···$············
    ffffcb8dc65f1202  d6 ac 7c b4 bc 33 ff 02-00 00 00 00 00 00 00 00  ··|··3··········
    ffffcb8dc65f1212  00 00 00 00 00 16                                ······
  MDL ffffcb8dc72e9a40
    ffffcb8dc65f10ae  3a 00 05 02 00 00 01 00-8f 00 c9 83 00 00 00 01  :···············
    ffffcb8dc65f10be  04 00 00 00 ff 02 00 00-00 00 00 00 00 00 00 01  ················
    ffffcb8dc65f10ce  ff b4 bc 33                                      ···3

set up a Pseudo Register for ease of use

0: kd> r? $t1 = ((ndis!_NET_BUFFER_LIST *)@rdx)->FirstNetBuffer

address of First Buffer

0: kd> ? @@c++(@$t1->CurrentMdl->MappedSystemVa) + @@c++(@$t1->CurrentMdlOffset)
Evaluate expression: -57665197764126 = ffffcb8d`c65f11e2

address of Second Buffer

0: kd> ? @@c++(@$t1->MdlChain->Next->MappedSystemVa)
Evaluate expression: -57665197764434 = ffffcb8d`c65f10ae