NDISTest CheckConnectivity fails with "Corruption detected in the NetBuffer received" on HLK 10.1.26100.8328, also with 3rd party adapters

The available Microsoft material does not identify HLK/NDISTest 10.1.26100.8328 as having a confirmed erratum or name a fixed build, so install the latest HLK filters, reapply them to these results, and—if no matching erratum appears—open one HLK Support case per failing test with your cross-adapter reproducer and debugger evidence.

What your results establish

Your evidence strongly isolates the failure to the NDISTest receive-validation path rather than to your NetAdapterCx miniport:

• Captured frames are identical at both endpoints.
• NDISTest accepts every packet at its header layer but rejects every payload.
• The reported byte is the first byte of the SNAP EtherType at frame offset 20, while the generated payload begins at frame offset 42.
• The same deterministic result occurs with an unrelated TP-LINK adapter replacing your virtual adapter.

That is persuasive evidence for Microsoft’s test owners, but it is not by itself an official erratum. Similar reports exist for ndprot683.sys and the same corruption diagnostic, but neither matching Q&A report currently has an accepted or recommended resolution ^1^ ^2^.

Check for an erratum before rerunning

Microsoft publishes an HLK filter when an HLK or OS defect incorrectly fails certification. An errata filter can convert the affected result to pass; a contingency is case-specific; autotriage only adds diagnostic information ^3^.

On the HLK controller:

1. Download the latest HCKFilterUpdates.cab.
2. Extract UpdateFilters.sql.
3. Copy it into the applicable
   %ProgramFiles(x86)%\Windows Kits\<version>\Hardware Lab Kit\Controller directory.
4. Close every HLK Studio instance.
5. Run UpdateFilters.exe from that directory.
6. Reopen the project.
7. On Results, select Apply Filters for the existing failures.

New results receive installed filters automatically, but existing results require Apply Filters. Microsoft’s prescribed HLK failure workflow starts with current updates and filters ^4^.

If no applicable filter appears, there is no publicly documented basis here for selecting another NDISTest build or claiming that a particular later kit fixes this signature. Use the HLK/playlist combination required by the current compatibility program rather than substituting NDISTest binaries independently ^5^.

Payload offset and frame dumping

Public NDISTest documentation describes CheckConnectivity as a bidirectional send/receive stress test, but does not document:

• its LLC/SNAP payload-offset calculation;
• why the validator uses MDL offset 0x14;
• a switch that dumps complete expected and actual frames.

The test can vary packet size, send IRQL, and packet-list composition ^6^.

Do not equate MDL offset 0x14 automatically with frame offset 20. A NET_BUFFER identifies its active bytes through CurrentMdl, CurrentMdlOffset, DataOffset, and DataLength; these values must remain mutually consistent with the MDL chain ^7^ ^8^.

At the breakpoint, preserve these for both adapters:

• NET_BUFFER_FIRST_MDL
• NET_BUFFER_CURRENT_MDL
• NET_BUFFER_CURRENT_MDL_OFFSET
• NET_BUFFER_DATA_OFFSET
• NET_BUFFER_DATA_LENGTH
• MDL byte count and mapped contents
• parsed Ethernet, LLC/SNAP, NDISTest-header, and payload boundaries

Also retain the exact expected seed and actual comparison pointer. This lets Microsoft determine whether the problem is an NDISTest parser error or inconsistent receive NET_BUFFER metadata that packet capture would not expose.

For complete test artifacts, use Results → failed task → Additional files and collect ndistest.wtl, checkconnectivity.htm, and ndistest.htm from the Client folder ^9^.

Support-adapter requirements

The published LAN prerequisites require the role/topology rather than naming a certified-NIC allowlist:

• support NIC connected directly back-to-back to the test NIC;
• separate message NICs for controller connectivity;
• support interface alias SupportDevice0 when explicit naming is needed;
• message interfaces named MessageDevice;
• unrelated Ethernet ports disabled or disconnected if they interfere with automatic selection ^10^.

Your direct cable already satisfies the relevant connection requirement, and successful receipt of all 250 packets in both directions makes device-autodetection or basic connectivity an unlikely explanation. The public prerequisites do not establish that either the Marvell or TP-LINK adapter is unsupported merely because of its model or certification status.

Submission and escalation

If no errata filter applies, do not package the raw failures as though they were waived. Open separate HLK Support issues for CheckConnectivity, MultiCast Address, and PacketFilters. Microsoft requests the exact test name, .hlkx package, relevant dumps/logs, and all additional debugging evidence ^11^.

Attach:

1. Both pktmon captures and a byte-offset annotation.
2. The TP-LINK control run.
3. All WTL/HTML/additional files.
4. Breakpoint details and NET_BUFFER/MDL metadata.
5. Exact OS, HLK, NDISTest, and ndprot683.sys versions.
6. A minimal table showing expected payload start 42, observed comparison offset 20, and delta 22.
7. The unmodified failing .hlkx.

If Microsoft confirms a test defect, the normal resolution is a published errata filter or a case-specific contingency. A supplemental folder can later be added to the submission package for an errata, contingency message, or manual filter when Microsoft supplies one ^12^.

References

1. NDISTest ndprot683.sys validation failure. - Microsoft Q&A
2. Windows 11 HLK NDISTest6.5: Multiple 2-Machine tests failing with ...
3. Windows Hardware Lab Kit Filters
4. Troubleshooting Windows HLK Test Failures
5. Windows Hardware Lab Kit
6. NDISTest 6.5 - [2 Machine] - CheckConnectivity
7. NET_BUFFER structure (ndis/nbl.h)
8. NdisAllocateNetBuffer function (ndis/nblapi.h)
9. Troubleshooting LAN Testing | Microsoft Learn
10. LAN Testing Prerequisites
11. Windows HLK Support
12. Step 8: Create a submission package