Whql addrechange test case failing

Question

Whql addrechange test case failing

David ambu 0

Hi All,

I’m facing failures in a few HLK network test cases using:

HLK Server: Windows Server 2022

Client systems: Windows Server 2025 / Windows 11

Issue Summary

The failures seem to be related to IPX packets being dropped, as observed via pktmon.

Observations

HLK is generating packets with:

802.3 + LLC/SNAP + IPX (0x8137) + payload

My network driver does not modify packets, it only parses LLC/SNAP headers.

In debugging (NdisProtocolTest.cpp):

The test checks packet type at offset 0x14, which aligns with IPX after LLC/SNAP.

If I truncate LLC/SNAP and pass:

802.3 + IPX + payload

→ The warning in ndistest.cpp disappears → But upper layers still drop the packet as “corrupted”

Questions

Why is HLK still sending IPX traffic, given that IPX is deprecated in modern Windows?

Is HLK expecting drivers to fully preserve and pass LLC/SNAP encapsulation, even for legacy protocols?

Are there any specific alignment, padding, or MDL requirements that HLK enforces for these packets?

Could this be related to known HLK test behavior or errata in recent versions?Hi All,

I’m facing failures in a few HLK network test cases using:

HLK Server: Windows Server 2022

  Client systems: Windows Server 2025 / Windows 11
  
  **Issue Summary**
  
  The failures seem to be related to IPX packets being dropped, as observed via pktmon.
  
  **Observations**
  
     - HLK is generating packets with:
     
     802.3 + LLC/SNAP + IPX (0x8137) + payload
     
        My network driver does not modify packets, it only parses LLC/SNAP headers.
        
           In debugging (NdisProtocolTest.cpp):
           
                 - The test checks packet type at offset 0x14, which aligns with IPX after LLC/SNAP.
                 
                    If I truncate LLC/SNAP and pass:
                    
                    802.3 + IPX + payload
                    
                       - → The warning in ndistest.cpp disappears  
                       → But upper layers still drop the packet as “corrupted”
                       
                       **Questions**
                       
                          Why is HLK still sending IPX traffic, given that IPX is deprecated in modern Windows?
                          
                             Is HLK expecting drivers to fully preserve and pass LLC/SNAP encapsulation, even for legacy protocols?
                             
                                Are there any specific alignment, padding, or MDL requirements that HLK enforces for these packets?
                                
                                   Could this be related to known HLK test behavior or errata in recent versions?

Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-23T10:57:05.3966667+00:00

Hi David ambu,

Thanks for reaching out.

I will need time to do research on this. I'll get back to you as soon as possible.

David ambu 0

Thanks Tom,

Additional info, Pktmon dropping on client VM IPX packets.

[03]0000.0000::2026-03-17 08:14:19.318771500 [Microsoft-Windows-PktMon] Drop: PktGroupId 844424930199588, PktNumber 1, Appearance 0, Direction Rx , Type Ethernet , Component 440, Filter 0, DropReason Unsupported EtherType , DropLocation 0xE0001007, OriginalSize 1514, LoggedSize 128 
	Drop: 5E-A6-19-9F-xx-xx > 02-02-04-06-08-04, 802.3, length 1500: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype IPX (0x8137), length 1492:

2 answers

Your answer

Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-23T10:57:05.3966667+00:00

Hi David ambu,

Thanks for reaching out.

I will need time to do research on this. I'll get back to you as soon as possible.
David ambu 0 Reputation points

2026-03-23T11:09:34.4933333+00:00

Thanks Tom,

Additional info, Pktmon dropping on client VM IPX packets.

[03]0000.0000::2026-03-17 08:14:19.318771500 [Microsoft-Windows-PktMon] Drop: PktGroupId 844424930199588, PktNumber 1, Appearance 0, Direction Rx , Type Ethernet , Component 440, Filter 0, DropReason Unsupported EtherType , DropLocation 0xE0001007, OriginalSize 1514, LoggedSize 128 Drop: 5E-A6-19-9F-xx-xx > 02-02-04-06-08-04, 802.3, length 1500: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Ethernet (0x000000), ethertype IPX (0x8137), length 1492:

Answer 1

Tom Tran (WICLOUD CORPORATION) 4,860 Microsoft External Staff Moderator

Hi @David ambu , Thank you for your patience.

This looks more related to how the packet is handled in the driver rather than the IPX protocol itself.

HLK network tests use synthetic traffic, so the protocol isn’t really the focus. These tests are exercising packet handling, where the frame is expected to be passed up as-is, including the full 802.3 + LLC/SNAP encapsulation. If anything is modified, truncated, or misaligned (NET_BUFFER offsets, MDL layout, length, etc.), the stack may fail to parse it and drop it as “Unsupported EtherType.”

The LLC/SNAP behavior you mentioned is a useful signal since removing it changes the result but leads to corruption, that typically points to an issue in how the original frame is being passed through rather than the protocol itself.

It might be worth double-checking these on the receive path:

Full frame preserved end-to-end
NET_BUFFER DataOffset/DataLength
MDL chain covers the entire buffer

Comparing the packet at the hardware/miniport edge vs what’s indicated to NDIS should help pinpoint where things diverge.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance provide feedback.

David ambu 0 Reputation points

2026-03-25T10:51:27.3933333+00:00

Thanks Tom for your reply, I am trying to recheck the flow thanks for the input once again. driver is not modifying or truncated. Checked with wireshark IPX packet exact data before sent from server and after received on client.
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-26T07:43:32.2266667+00:00
Hi @David ambu ,

Thanks for the helpful follow up.

Since the packet looks correct at the wire level, the drop is likely not about the packet content itself, but how it's being presented to NDIS.

The "Unsupported EtherType" drop reason is worth looking at more closely. Windows does support SNAP encapsulation, so this usually points to the EtherType being read at the wrong offset rather than the protocol being unsupported outright. It's also worth noting that Wireshark captures don't always reflect exactly how the buffer is laid out at the driver level, so the packet appearing correct there doesn't fully rule out a buffer presentation issue.

I'd suggest verifying a few things on the receive path:

NET_BUFFER->DataOffset points to the start of the 802.3 header

NET_BUFFER->DataLength matches the full frame size

The first MDL contains the full Ethernet + LLC/SNAP headers without splitting them across multiple MDLs

As an additional test, it might be worth trying to indicate the packet using a single contiguous buffer. If the HLK result changes, that would suggest the issue is with the buffer layout rather than the packet content itself, a split MDL chain can sometimes cause the stack to misread where the header boundaries are.

If possible, comparing the packet at the miniport receive side versus what gets passed into NdisMIndicateReceiveNetBufferLists would also help pinpoint whether there's any shift or difference in the buffer layout between those two points.
David ambu 0 Reputation points

2026-03-26T11:39:19.54+00:00

Thank you very much for details will cross check the details.

David ambu 0

Hi Tom,

Quick update what I different types tried, but still issue present.

single MDL with complete data is sent issue seen, NBL->NB->MDL-> buffer (Actual data 1514). NB data offset, length are correct.
Two MDLs one with 802.3+LLCSNAP and IPX Payload+data its same.
Issue is happening with inbuild Intel released drivers as well.

Force Core Dump NBL,NB, Buffer shown as below: truncated driver name, src mac add

3: kd> dx -id 0,0,ffffc68c926e4040 -r1 ((net!_NET_BUFFER_LIST *)0xffffc68ca5770dd0)
((net!_NET_BUFFER_LIST *)0xffffc68ca5770dd0)                 : 0xffffc68ca5770dd0 [Type: _NET_BUFFER_LIST *]
    [+0x000] Next             : 0x0 [Type: _NET_BUFFER_LIST *]
    [+0x008] FirstNetBuffer   : 0xffffc68ca5770f50 [Type: _NET_BUFFER *]
    [+0x000] Link             [Type: _SLIST_HEADER]
    [+0x000] NetBufferListHeader [Type: _NET_BUFFER_LIST_HEADER]
    [+0x010] Context          : 0x0 [Type: _NET_BUFFER_LIST_CONTEXT *]
    [+0x018] ParentNetBufferList : 0x0 [Type: _NET_BUFFER_LIST *]
    [+0x020] NdisPoolHandle   : 0xffffc68cac058680 [Type: void *]
    [+0x030] NdisReserved     [Type: void * [2]]
    [+0x040] ProtocolReserved [Type: void * [4]]
    [+0x060] MiniportReserved [Type: void * [2]]
    [+0x070] Scratch          : 0x0 [Type: void *]
    [+0x078] SourceHandle     : 0x0 [Type: void *]
    [+0x080] NblFlags         : 0x0 [Type: unsigned long]
    [+0x084] ChildRefCount    : 0 [Type: long]
    [+0x088] Flags            : 0x100 [Type: unsigned long]
    [+0x08c] Status           : 0 [Type: int]
    [+0x08c] NdisReserved2    : 0x0 [Type: unsigned long]
    [+0x090] NetBufferListInfo [Type: void * [27]]
3: kd> dx -id 0,0,ffffc68c926e4040 -r1 ((net!_NET_BUFFER *)0xffffc68ca5770f50)
((net!_NET_BUFFER *)0xffffc68ca5770f50)                 : 0xffffc68ca5770f50 [Type: _NET_BUFFER *]
    [+0x000] Next             : 0x0 [Type: _NET_BUFFER *]
    [+0x008] CurrentMdl       : 0xffffc68c9cfe7fc0 [Type: _MDL *]
    [+0x010] CurrentMdlOffset : 0x0 [Type: unsigned long]
    [+0x018] DataLength       : 0x5ea [Type: unsigned long]
    [+0x018] stDataLength     : 0x5ea [Type: unsigned __int64]
    [+0x020] MdlChain         : 0xffffc68c9cfe7fc0 [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   : 0xffffc68cac058680 [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 *]
3: kd> dx -id 0,0,ffffc68c926e4040 -r1 ((net!_MDL *)0xffffc68c9cfe7fc0)
((net!_MDL *)0xffffc68c9cfe7fc0)                 : 0xffffc68c9cfe7fc0 [Type: _MDL *]
    [+0x000] Next             : 0x0 [Type: _MDL *]
    [+0x008] Size             : 56 [Type: short]
    [+0x00a] MdlFlags         : 12 [Type: short]
    [+0x010] Process          : 0x0 [Type: _EPROCESS *]
    [+0x018] MappedSystemVa   : 0xffffc68c9cffd000 [Type: void *]
    [+0x020] StartVa          : 0xffffc68c9cffd000 [Type: void *]
    [+0x028] ByteCount        : 0x5ea [Type: unsigned long]
    [+0x02c] ByteOffset       : 0x0 [Type: unsigned long]
3: kd> db 0xffffc68c9cffd000
ffffc68c`9cffd000  02 02 04 06 08 02 xx xx-44 1c 70 06 05 dc aa aa  ........D.p.....
ffffc68c`9cffd010  03 00 00 00 81 37 4e 44-49 53 01 2c c0 05 6e e4  .....7NDIS.,..n.
ffffc68c`9cffd020  21 52 03 00 00 00 14 00-00 00 2c 2d 2e 2f 30 31  !R........,-./01
ffffc68c`9cffd030  32 33 34 35 36 37 38 39-3a 3b 3c 3d 3e 3f 40 41  23456789:;<=>?@A
ffffc68c`9cffd040  42 43 44 45 46 47 48 49-4a 4b 4c 4d 4e 4f 50 51  BCDEFGHIJKLMNOPQ
ffffc68c`9cffd050  52 53 54 55 56 57 58 59-5a 5b 5c 5d 5e 5f 60 61  RSTUVWXYZ[\]^_`a
ffffc68c`9cffd060  62 63 64 65 66 67 68 69-6a 6b 6c 6d 6e 6f 70 71  bcdefghijklmnopq
ffffc68c`9cffd070  72 73 74 75 76 77 78 79-7a 7b 7c 7d 7e 7f 80 81  rstuvwxyz{|}~...

for experiment HLK report shows MDL corruption it expects 0x14 offset particular value actually it will start LLCSNAP Type 81 37, I removed LLCSNAP header the warning not coming, is this something wrong it expecting what at offset 0x14 is checking by ndistestpacket.cpp is checking? On my debugging I see Ndistestpacket.cpp looking for pkttype from IPX Payload. Issue is seen still anyway.

mdl corruption

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
David ambu 0 Reputation points

2026-03-30T07:53:43.7566667+00:00
Hi Tom,

I wanted to share an update on the HLK failure related to the reported “MDL corruption”.

Summary of observations:

The packet structure is: NBL → NB → MDL → buffer, with a total packet size of ~1514 bytes.

Verified that:

NET_BUFFER.DataOffset = 0

NET_BUFFER.DataLength matches MDL.ByteCount

MDL is valid, contiguous, and correctly mapped

Test variations performed:

Single MDL containing the full packet → Issue reproduces

Two MDLs:

MDL1: 802.3 + LLC/SNAP headers

MDL2: IPX payload + test data → Issue still reproduces

Same behavior observed with inbox Intel drivers

HLK observation:

HLK reports MDL corruption, specifically expecting a value at offset 0x14.

At offset 0x14 in the actual packet, we see:

Start of LLC/SNAP header (e.g., 0x81, 0x37)

Key finding:

If the LLC/SNAP header is removed, the HLK warning no longer appears.

Analysis:

Based on debugging, ndistestpacket.cpp appears to check the packet type within the IPX payload.

This suggests the test may be assuming the payload begins at offset 0x14, effectively ignoring the presence of LLC/SNAP encapsulation.

Question:

Can you confirm what the HLK test expects at offset 0x14?

Is LLC/SNAP encapsulation expected to be present, or is the test assuming Ethernet II framing (no LLC/SNAP)?

If LLC/SNAP is valid, should the offset calculation in the test account for it?

At this point, the MDL layout and buffer contents appear correct, and the failure seems to be due to a mismatch between packet format assumptions and HLK validation logic.

Thanks.Hi,

I wanted to share an update on the HLK failure related to the reported “MDL corruption”.

Summary of observations:

The packet structure is:
NBL → NB → MDL → buffer, with a total packet size of ~1514 bytes.

Verified that:

NET_BUFFER.DataOffset = 0

NET_BUFFER.DataLength matches MDL.ByteCount

MDL is valid, contiguous, and correctly mapped

Test variations performed:

Single MDL containing the full packet → Issue reproduces

Two MDLs:

MDL1: 802.3 + LLC/SNAP headers

MDL2: IPX payload + test data
→ Issue still reproduces

Same behavior observed with inbox Intel drivers

HLK observation:

HLK reports MDL corruption, specifically expecting a value at offset 0x14.

At offset 0x14 in the actual packet, we see:

Start of LLC/SNAP header (e.g., 0x81, 0x37)

Key finding:

If the LLC/SNAP header is removed, the HLK warning no longer appears.

Analysis:

Based on debugging, ndistestpacket.cpp appears to check the packet type within the IPX payload.

This suggests the test may be assuming the payload begins at offset 0x14, effectively ignoring the presence of LLC/SNAP encapsulation.

Question:

Can you confirm what the HLK test expects at offset 0x14?

Is LLC/SNAP encapsulation expected to be present, or is the test assuming Ethernet II framing (no LLC/SNAP)?

If LLC/SNAP is valid, should the offset calculation in the test account for it?

At this point, the MDL layout and buffer contents appear correct, and the failure seems to be due to a mismatch between packet format assumptions and HLK validation logic?
Tom Tran (WICLOUD CORPORATION) 4,860 Reputation points Microsoft External Staff Moderator

2026-03-31T10:33:03.1833333+00:00
Hi @David ambu ,

Thanks for the detailed follow‑up and for taking the time to validate this across different MDL layouts and with the inbox Intel driver, that additional testing is very helpful.

Given that the behavior reproduces outside of your custom driver and the packet contents look correct on the wire, this no longer appears to be specific to a driver implementation issue. What stands out now is how the HLK test is evaluating the received frame, particularly around the fixed offset check when LLC/SNAP encapsulation is present.

At this point, further troubleshooting from the driver side is unlikely to provide new signal, since the behavior points to how the HLK test itself is validating the packet layout. That kind of validation requires deeper review of the HLK test logic and expectations, which goes beyond what can realistically be resolved through this platform alone.

To move this forward, the best next step would be to open a support request so this can be reviewed directly by the HLK engineering team with access to the test internals. You can do that here:

https://support.serviceshub.microsoft.com/supportforbusiness/create?sapId=4fd4947b-15ea-ce01-080f-97f2ca3c76e8

When creating the request, I’d recommend including the reproduction with the inbox Intel driver and the observations around the offset 0x14 check, as that context will help streamline the investigation.

Apologies if I cannot assist you further with this. If you need help creating a support ticket, please feel free to reach out.
David ambu 0 Reputation points

2026-03-31T12:11:14.8866667+00:00

Thanks Tom for support guidance.

Answer 2

The behavior can be analyzed and addressed only in terms of how HLK network tests are expected to run and how to troubleshoot HLK failures; the context does not document IPX-specific design decisions or errata.

For Device.Network / LAN tests, the recommended approach is:

Verify the test is being run correctly
- Confirm that all LAN test prerequisites are met as described in the LAN testing setup documentation referenced by the individual test (for example, LAN Testing Prerequisites from the test’s own page).
- Check whether the failing tests require any special configuration or supplemental data. In HLK Studio, tests that require special configuration are marked with the toolbox icon in the Type column. If such configuration is required and not present, tests will fail regardless of driver behavior.
- If the tests are being run as multi-device tests, rerun them as single-device tests to simplify troubleshooting and ensure that logs are not conflated across devices.
Use HLK’s generic troubleshooting flow for network tests
- For Device.Network tests, follow the “Troubleshooting Device.Network Testing” and “Troubleshooting LAN Testing” guidance:
  - Review the generic HLK failure guide: Troubleshooting Windows HLK Test Failures.
  - Review the Windows HLK release notes for any known current test issues.
  - For each failing run, inspect the HLK Studio test logs (Task Log and Additional Files) for concrete failure reasons and assertions from the test harness.
- For LAN tests specifically, if there are two-machine jobs involved, run the “NDISTest 6.5 – [2 Machine] – CheckConnectivity” job to verify that the basic connectivity and NIC selection are correct. If this job fails, the logs will show where bidirectional communication fails, which must be resolved before other tests can be trusted.
Identify the failure category in HLK
- Use the “Identify the failure category” guidance:
  - If there are no Task Logs, check whether the test was cancelled due to timeout or client unresponsiveness.
  - If there is a test result failure, focus on the Task Log and Additional Files, and the Troubleshooting section of the specific test reference.
  - If the test shows no failing task and Execution Logs are disabled (greyed out), this can be a known HLK client issue; the workaround is to rerun the test so that logs are copied back correctly.
Check for configuration changes and unsupported controller scenarios
- Ensure that the HLK infrastructure or device configuration has not changed after selecting the test target. If it has, re-select the test target (noting that this invalidates previous results).
- Verify that the HLK Studio/Controller environment is supported (for example, not a machine that was moved from domain to workgroup after installation), since unsupported scenarios can cause test failures unrelated to driver behavior.

Within the provided context, there is no documented requirement or errata about:

Use of IPX in current HLK network tests.
Specific alignment, padding, or MDL layout requirements for IPX or LLC/SNAP-encapsulated frames.
Expectations that drivers preserve LLC/SNAP encapsulation for legacy protocols.

Therefore, the actionable steps supported by the documentation are to:

Treat these as standard Device.Network / LAN HLK failures.
Use the HLK logs, LAN troubleshooting guidance, and connectivity checks to isolate whether the failure is due to test setup, connectivity, or driver behavior.
Consult the specific test’s reference and Troubleshooting section (via F1 in HLK Studio) and the HLK release notes for any test-specific issues.

References:

Share via

Whql addrechange test case failing

2 answers

Your answer