NDISTest ndprot683.sys validation failure.

Question

NDISTest ndprot683.sys validation failure.

Owen Smith 0

When running the HLK test on our network driver (and the in-box Intel driver) on Windows 11, using the latest HLK kits, a lot of networking tests fail (the same tests do not fail on previous releases of the HLK)

Catching the failure in the debugger results in the following details.

Corruption detected in the NetBuffer received Corrupt MDL = FFFFCE8ECCCFC5B0 , Net Buffer List = FFFFCE8ED3A94DD0 Byte Offset of corruption within MDL = 0x00000014 Expected Byte Value = 0xf2 Actual Byte Value = 0x81 Break instruction exception - code 80000003 (first chance) nt!DbgBreakPointWithStatus: fffff801d88a6c90 cc int 3 0: kd> !ndiskd.nbl FFFFCE8ED3A94DD0 NBL ffffce8ed3a94dd0 Next NBL NULL First NB ffffce8ed3a94f50 Source ffffce8eccd251a0 - XenServer PV Network Device #1 Unable to load image xennet.sys, Win32 error 0n2 Pool ffffce8ecce62c80 - Flags INDICATED, NBL_ALLOCATED Walk the NBL chain Dump data payload Show out-of-band information Display as Wireshark hex dump 0: kd> !ndiskd.nbl ffffce8ed3a94dd0 -data NET_BUFFER ffffce8ed3a94f50 MDL ffffce8ecccfc5b0 ffffb901cebe0000 fe 73 40 51 e6 da 9a 87-40 9f e0 7e 05 dc aa aa ·s@Q····@··~···· ffffb901cebe0010 03 00 00 00 81 37 4e 44-49 53 01 f2 c0 05 a0 94 ·····7NDIS······ ffffb901cebe0020 bd db 34 00 00 00 14 00-00 00 f2 f3 f4 f5 f6 f7 ··4············· ffffb901cebe0030 f8 f9 fa fb fc fd fe ff-00 01 02 03 04 05 06 07 ················ ffffb901cebe0040 08 09 0a 0b 0c 0d 0e 0f-10 11 12 13 14 15 16 17 ················ (truncated) 0: kd> dt _NET_BUFFER_LIST ffffce8ed3a94dd0 ndis!_NET_BUFFER_LIST _NET_BUFFER_LIST +0x000 Next : (null) +0x008 FirstNetBuffer : 0xffffce8ed3a94f50 _NET_BUFFER +0x000 Link : _SLIST_HEADER +0x000 NetBufferListHeader : _NET_BUFFER_LIST_HEADER +0x010 Context : (null) +0x018 ParentNetBufferList : (null) +0x020 NdisPoolHandle : 0xffffce8ecce62c80 Void +0x030 NdisReserved : [2] (null) +0x040 ProtocolReserved : [4] (null) +0x060 MiniportReserved : [2] 0xffffce8ecccfc538 Void +0x070 Scratch : (null) +0x078 SourceHandle : 0xffffce8eccd251a0 Void +0x080 NblFlags : 0 +0x084 ChildRefCount : 0n0 +0x088 Flags : 0x104 +0x08c Status : 0n0 +0x08c NdisReserved2 : 0 +0x090 NetBufferListInfo : [29] (null) 0: kd> !ndiskd.nbl ffffce8ed3a94dd0 -info NET_BUFFER_LIST_INFO TcpIpChecksumNetBufferListInfo 0 TcpOffloadBytesTransferred 0 IPsecOffloadV1NetBufferListInfo 0 IPsecOffloadV2NetBufferListInfo 0 TcpLargeSendNetBufferListInfo 0 TcpReceiveNoPush 0 ClassificationHandleNetBufferListInfo NULL Ieee8021QNetBufferListInfo 0 NetBufferListCancelId NULL MediaSpecificInformation 0 NetBufferListFrameType NDIS_PROTOCOL_ID_DEFAULT NetBufferListHashValue 0 NetBufferListHashInfo 0 WfpNetBufferListInfo ffffce8ed0baa010 IPsecOffloadV2TunnelNetBufferListInfo 0 IPsecOffloadV2HeaderNetBufferListInfo 0 NetBufferListCorrelationId NULL NetBufferListFilteringInfo 0 MediaSpecificInformationEx NULL NblOriginalInterfaceIfIndex 0 NblReAuthWfpFlowContext NULL TcpReceiveBytesTransferred 0 UdpRecvSegCoalesceOffloadInfo 0 TcpRecvSegCoalesceInfo 0 UdpSegmentationOffloadInfo 0 RscTcpTimestampDelta 0 TcpSendOffloadsSupplementalNetBufferListInfo 0 IMReserved NULL SwitchForwardingReserved NULL SwitchForwardingDetail NULL VirtualSubnetInfo 0 GftOffloadInformation 0 GftFlowEntryId 0 NetBufferListInfoReserved3 0 NblCurrentOwner ffffce8ed3a7efb3 Info[0n28] NULL : kd> !ndiskd.nb ffffce8ed3a94f50 NB ffffce8ed3a94f50 Next NB NULL Length 0n1514 Source pool ffffce8ecce62c80 First MDL ffffce8ecccfc5b0 DataOffset 0 Current MDL [First MDL] Current MDL offset 0 View associated NBL 0: kd> dx -id 0,0,ffffce8ec5714040 -r1 ((ndis!_NET_BUFFER *)0xffffce8ed3a94f50) ((ndis!_NET_BUFFER *)0xffffce8ed3a94f50) : 0xffffce8ed3a94f50 [Type: _NET_BUFFER *] [+0x000] Next : 0x0 [Type: _NET_BUFFER *] [+0x008] CurrentMdl : 0xffffce8ecccfc5b0 [Type: _MDL *] [+0x010] CurrentMdlOffset : 0x0 [Type: unsigned long] [+0x018] DataLength : 0x5ea [Type: unsigned long] [+0x018] stDataLength : 0x5ea [Type: unsigned __int64] [+0x020] MdlChain : 0xffffce8ecccfc5b0 [Type: _MDL *] [+0x028] DataOffset : 0x0 [Type: unsigned long] [+0x000] Link [Type: _SLIST_HEADER] [+0x000] NetBufferHeader [Type: _NET_BUFFER_HEADER] [+0x030] ChecksumBias : 0x0 [Type: unsigned short] [+0x032] Reserved : 0x0 [Type: unsigned short] [+0x038] NdisPoolHandle : 0xffffce8ecce62c80 [Type: void *] [+0x040] NdisReserved [Type: void * [2]] [+0x050] ProtocolReserved [Type: void * [6]] [+0x080] MiniportReserved [Type: void * [4]] [+0x0a0] DataPhysicalAddress : {0} [Type: _LARGE_INTEGER] [+0x0a8] SharedMemoryInfo : 0x0 [Type: _NET_BUFFER_SHARED_MEMORY *] [+0x0a8] ScatterGatherList : 0x0 [Type: _SCATTER_GATHER_LIST *] 0: kd> dx -id 0,0,ffffce8ec5714040 -r1 (*((ndis!void * (*)[2])0xffffce8ed3a94f90)) (*((ndis!void * (*)[2])0xffffce8ed3a94f90)) [Type: void * [2]] [0] : 0x0 [Type: void *] [1] : 0x0 [Type: void *] 0: kd> dx -id 0,0,ffffce8ec5714040 -r1 (*((ndis!void * (*)[6])0xffffce8ed3a94fa0)) (*((ndis!void * (*)[6])0xffffce8ed3a94fa0)) [Type: void * [6]] [0] : 0x0 [Type: void *] [1] : 0x0 [Type: void *] [2] : 0x0 [Type: void *] [3] : 0x0 [Type: void *] [4] : 0x0 [Type: void *] [5] : 0x0 [Type: void *] 0: kd> dx -id 0,0,ffffce8ec5714040 -r1 (*((ndis!void * (*)[4])0xffffce8ed3a94fd0)) (*((ndis!void * (*)[4])0xffffce8ed3a94fd0)) [Type: void * [4]] [0] : 0x0 [Type: void *] [1] : 0x0 [Type: void *] [2] : 0x0 [Type: void *] [3] : 0x0 [Type: void *] 0: kd> dx -id 0,0,ffffce8ec5714040 -r1 ((ndis!_MDL *)0xffffce8ecccfc5b0) ((ndis!_MDL *)0xffffce8ecccfc5b0) : 0xffffce8ecccfc5b0 [Type: _MDL *] [+0x000] Next : 0x0 [Type: _MDL *] [+0x008] Size : 56 [Type: short] [+0x00a] MdlFlags : 3 [Type: short] [+0x00c] AllocationProcessorNumber : 0x0 [Type: unsigned short] [+0x00e] Reserved : 0x0 [Type: unsigned short] [+0x010] Process : 0x0 [Type: _EPROCESS *] [+0x018] MappedSystemVa : 0xffffb901cebe0000 [Type: void *] [+0x020] StartVa : 0xffffb901cebe0000 [Type: void *] [+0x028] ByteCount : 0x5ea [Type: unsigned long] [+0x02c] ByteOffset : 0x0 [Type: unsigned long] 0: kd> db 0xffffb901cebe0000 L30 ffffb901cebe0000 fe 73 40 51 e6 da 9a 87-40 9f e0 7e 05 dc aa aa .s@Q....@..~.... ffffb901cebe0010 03 00 00 00 81 37 4e 44-49 53 01 f2 c0 05 a0 94 .....7NDIS...... ffffb901cebe0020 bd db 34 00 00 00 14 00-00 00 f2 f3 f4 f5 f6 f7 ..4............. (truncated)

Note how NDISTest is checking byte offset 0x14 - which is the offset of a LLC/SNAP header, not the expected test data, which is at offset 0x14 into the NDIS test data block (i.e. after the Ethernet header, and LLC/SNAP header, and starts with "NDIS". This is a single `NET_BUFFER_LIST` which contains a single NET_BUFFER` `` which references a single MDL` `` all offsets/lengths and current MDL/offsets are correctly pointing to the start of the Ethernet header.
Is there anything that is incorrect in the NET_BUFFER_LIST or NET_BUFFER structures?
Should ndprot683.sys be validating absolute offset 0x14, or should it validate offset 0x14 relative to the NDIS test buffers?

0 comments

1 answer

Your answer

Answer 1

The NET_BUFFER_LIST / NET_BUFFER layout in the debugger output is consistent with NDIS expectations and does not show any structural error based on the available information:

The NET_BUFFER_LIST has a single NET_BUFFER in FirstNetBuffer.
The NET_BUFFER’s MdlChain, CurrentMdl, CurrentMdlOffset, DataOffset, and DataLength are all coherent and point to the start of the Ethernet header in a single MDL.
The MDL’s MappedSystemVa, StartVa, ByteCount, and ByteOffset correctly describe a contiguous buffer that contains the Ethernet header, LLC/SNAP header, and the NDIS test payload.

The context material describes how NET_BUFFER and NET_BUFFER_LIST data is organized, and how offsets are interpreted:

NET_BUFFER_DATA.DataOffset is defined as:

The offset, in bytes, from the beginning of the MDL chain to the beginning of the network data in the MDL chain. This offset is also the size, in bytes, of the unused data space. In the dump, DataOffset is 0, so the network data starts at the first byte of the MDL (0xffffb901cebe0000).
The NET_BUFFER_LIST contains a linked list of NET_BUFFER structures, and each NET_BUFFER’s DataOffset and MDL chain define where the packet data begins and how it is laid out in memory.

Given that:

The Ethernet header and LLC/SNAP header are at the start of the MDL (as expected for a normal Ethernet frame).
The NDIS test payload (starting with "NDIS") appears later in the buffer (after the headers).
NDISTest is checking byte offset 0x14 from the beginning of the MDL (absolute offset into the MDL), which falls inside the LLC/SNAP header rather than inside the NDIS test payload.

This means the validation logic in ndprot683.sys is using an absolute offset into the MDL buffer rather than an offset relative to the start of the NDIS test payload within the frame. The NDIS buffer structures themselves (NET_BUFFER_LIST / NET_BUFFER / MDL) are not incorrect based on the provided dump; the discrepancy is in how the test driver interprets the offset.

From the NDIS buffer model described in the context:

Offsets such as DataOffset are defined relative to the MDL chain, not to higher-level protocol payloads.
Any validation that wants to inspect a specific test payload region must account for the protocol headers (Ethernet, LLC/SNAP, IP, etc.) and compute an offset relative to the start of the payload, not a fixed absolute offset from the MDL base.

Therefore, for a frame that contains an Ethernet header and LLC/SNAP header before the NDIS test payload, ndprot683.sys should validate the test bytes at an offset that is relative to the start of the NDIS test buffer (i.e., after the headers), not at absolute offset 0x14 from the beginning of the MDL. The behavior observed (checking 0x14 absolute and expecting the test pattern there) is inconsistent with the actual layout of the frame and leads to the reported “corruption” even though the NET_BUFFER/MDL layout is valid.

References: