Share via

HLK Failure on Windows 11 25H2 - ArchitecturalDesign.SupportPowerManagedStates (IPv6 Inbound Traffic Blocked)

Roshan Patil 45 Reputation points
2026-04-17T11:39:10.9766667+00:00

Hello Team,

We are encountering a failure in Windows HLK testing for our WFP-based network driver on Windows 11 25H2. The same driver previously passed on Windows 11 24H2.

Test Details:

  • Test Name: ArchitecturalDesign.SupportPowerManagedStates
  • Environment: Windows 11 25H2 HLK
  • Driver Type: WFP Callout Driver (Transport + ALE layers, IPv4 & IPv6)

Failure Summary:

The test fails with the following log:

SUB_VAR+ 1 : [IPVersion: IPv6][Direction: Inbound][Protocol: Raw UDP (17)] [Source Address: fe80::1:0:0][Destination Address: fe80::XXXX] [Source Port: 44736][Destination Port: 45723] [Action: PERMIT]

PowerStates [IPv6][Inbound] [expected: PERMIT] [actual: BLOCK]

Additionally, HLK reports:

  • Missing or incomplete trace generation in some runs (WFPLogo.wtl.trace)
  • Non-zero fail counts in LogFile

Observations:

  1. IPv6 ICMP (ping) traffic works correctly.
  2. However, TCP/UDP transport traffic fails locally:
    • Test-NetConnection shows TcpTestSucceeded: False
    1. The issue specifically affects:
      • IPv6 inbound traffic
        • Raw UDP / transport-layer packets
          • Link-local addresses (fe80::/10)
          1. Our driver:
            • Registers callouts for: 
              - FWPM_LAYER_INBOUND_TRANSPORT_V4/V6

      - FWPM_LAYER_OUTBOUND_TRANSPORT_V4/V6

            - ALE layers (connect, recv_accept, flow established, resource assignment)

               - Uses FWPM_CONDITION_IP_PROTOCOL filters (TCP/UDP)

Questions:

  1. Has there been any change in HLK validation behavior for IPv6 / transport-layer traffic in Windows 11 25H2 compared to 24H2?
  2. Are WFP callout drivers required to:
    • Handle ALL IPv6 traffic (including link-local and Raw UDP), even if not explicitly filtered?
    1. Is it mandatory for classifyFn to explicitly return FWP_ACTION_PERMIT for all non-blocking scenarios to pass HLK?
    2. Are there any updated best practices or requirements for:
      • Filter conditions (e.g., avoiding protocol-restricted filters)
        • Handling HLK-generated test traffic?

Request:

We would appreciate:

  • Confirmation of expected behavior for WFP drivers under HLK in 25H2
  • Guidance on handling IPv6 inbound Raw UDP traffic
  • Any updated documentation or sample code for HLK-compliant WFP drivers

Please let us know if additional logs, driver binaries, or HLK packages are required for further analysis.Hello Microsoft Support Team,

We are encountering a failure in Windows HLK testing for our WFP-based network driver on Windows 11 25H2. The same driver previously passed on Windows 11 24H2.

Test Details:

  • Test Name: ArchitecturalDesign.SupportPowerManagedStates
  • Environment: Windows 11 25H2 HLK
  • Driver Type: WFP Callout Driver (Transport + ALE layers, IPv4 & IPv6)

Failure Summary:

The test fails with the following log:

SUB_VAR+ 1 :
[IPVersion: IPv6][Direction: Inbound][Protocol: Raw UDP (17)]
[Source Address: fe80::1:0:0][Destination Address: fe80::XXXX]
[Source Port: 44736][Destination Port: 45723]
[Action: PERMIT]

PowerStates [IPv6][Inbound]
[expected: PERMIT]
[actual: BLOCK]

Additionally, HLK reports:

  • Missing or incomplete trace generation in some runs (WFPLogo.wtl.trace)
  • Non-zero fail counts in LogFile

Observations:

  1. IPv6 ICMP (ping) traffic works correctly.
  2. However, TCP/UDP transport traffic fails locally:
    • Test-NetConnection shows TcpTestSucceeded: False
    1. The issue specifically affects:
      • IPv6 inbound traffic
        • Raw UDP / transport-layer packets
          • Link-local addresses (fe80::/10)
          1. Our driver:
            • Registers callouts for: 
              - FWPM_LAYER_INBOUND_TRANSPORT_V4/V6

      - FWPM_LAYER_OUTBOUND_TRANSPORT_V4/V6

            - ALE layers (connect, recv_accept, flow established, resource assignment)

               - Uses FWPM_CONDITION_IP_PROTOCOL filters (TCP/UDP)

Questions:

  1. Has there been any change in HLK validation behavior for IPv6 / transport-layer traffic in Windows 11 25H2 compared to 24H2?
  2. Are WFP callout drivers required to:
    • Handle ALL IPv6 traffic (including link-local and Raw UDP), even if not explicitly filtered?
    1. Is it mandatory for classifyFn to explicitly return FWP_ACTION_PERMIT for all non-blocking scenarios to pass HLK?
    2. Are there any updated best practices or requirements for:
      • Filter conditions (e.g., avoiding protocol-restricted filters)
        • Handling HLK-generated test traffic?

Request:

We would appreciate:

  • Confirmation of expected behavior for WFP drivers under HLK in 25H2
  • Guidance on handling IPv6 inbound Raw UDP traffic
  • Any updated documentation or sample code for HLK-compliant WFP drivers

Please let us know if additional logs, driver binaries, or HLK packages are required for further analysis.

Windows for business | Windows Client for IT Pros | Devices and deployment | Set up upgrades and drivers
0 comments

Answer accepted by question author

VPHAN 33,910 Reputation points Independent Advisor
2026-04-17T12:34:20.0833333+00:00

Hi Roshan Patil,

The failure in the ArchitecturalDesign.SupportPowerManagedStates test under the Windows 11 25H2 HLK is a result of stricter validation surrounding network connectivity during system power state transitions. The operating system heavily relies on IPv6 link-local UDP traffic to maintain critical network states, discover neighboring devices, and manage wake-on-LAN offloads during these low-power phases. The updated hardware lab kit ensures that security and filtering drivers do not inadvertently drop this essential local traffic, which would otherwise result in broken network connectivity upon resuming from sleep or modern standby.

Regarding your architectural concerns, your Windows Filtering Platform callout driver is not inherently required to process all IPv6 traffic, but your classification function is held strictly responsible for the fate of any packet that matches your registered filter conditions. When an inbound IPv6 transport packet reaches your classifyFn routine, you must explicitly populate the FWPS_CLASSIFY_OUT0 structure. If the packet falls outside your specific inspection parameters, you must explicitly set the action.type field to FWP_ACTION_PERMIT. Relying on default fall-through behavior or leaving the action structure uninitialized results in an implicit block during filter arbitration, directly triggering the exact test failure and the local TCP/UDP connectivity issues you observed.

To resolve this, you can implement one of two standard architectural adjustments. The most efficient approach is to narrow your filter parameters at the Base Filtering Engine level by defining specific FWPM_FILTER_CONDITION arrays to exclude the fe80::/10 address space or specific raw UDP protocols. This allows critical system traffic to bypass your callout entirely, resolving the missing trace generation issue and improving overall driver performance. Alternatively, you must audit your classifyFn logic across both the transport and ALE layers to ensure your code explicitly assigns the FWP_ACTION_PERMIT flag and respects the FWPS_RIGHT_ACTION_WRITE flag for any packet it inspects but decides not to block. It is also recommended to regularly check the Windows Hardware Compatibility Program portal for published HLK errata targeting the 25H2 branch, as updated validation logic occasionally contains known test bugs that require an official workspace bypass.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. VPHAN 33,910 Reputation points Independent Advisor
    2026-04-21T00:38:28.4166667+00:00

    Hi Roshan Patil,

    How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

    VP

    Was this answer helpful?

  2. AI answer

    2026-04-17T11:39:41.99+00:00

    The provided context does not contain any information about:

    • ArchitecturalDesign.SupportPowerManagedStates
    • WFP/WFPLogo behavior changes between Windows 11 24H2 and 25H2
    • IPv6 link-local or Raw UDP handling requirements for WFP callout drivers
    • HLK-specific expectations for classifyFn behavior or filter conditions at WFP layers

    The only HLK-related guidance in the context is generic troubleshooting and support-escalation process. Based on that, the only supported guidance is to treat this as an HLK test failure and follow the standard HLK troubleshooting and support path:

    1. Follow the generic HLK troubleshooting steps in the prescribed order:
      • Install the latest HLK updates and filters for Windows 11 25H2 and confirm whether there is already a published filter or fix for ArchitecturalDesign.SupportPowerManagedStates.
      • Verify that the test was run correctly (including any special configuration requirements) and that the environment matches the test reference requirements.
      • Check for configuration changes between the 24H2 and 25H2 environments.
      • Use the Results tab in HLK Studio to identify the failure category and inspect all available logs.
    2. Identify the failure category in HLK Studio:
      • On the Results tab, locate the failing ArchitecturalDesign.SupportPowerManagedStates job.
      • Check whether the failure is categorized as:
        • “Test failed because of test results” (Task Error / Task Log), or
        • “System crashed”, or
        • “Test crashed”, or
        • “Test was cancelled because it ran too long”.
      • For “Test failed because of test results”, review the Task Log and Additional Files from the Results tab.
      • If there are no failing tasks and Execution Logs are disabled (greyed out under Infrastructure → Execution Logs), rerun the test to work around the known HLK client issue where logs are not copied back to the controller.
    3. Inspect logs and traces for the failing run:
      • In HLK Studio, right‑click the failed test result and review:
        • Task errors
        • Task execution logs
        • Additional files (including WFPLogo.wtl.trace if present)
      • Confirm whether the missing/incomplete WFPLogo.wtl.trace is due to the known “Execution Logs missing” issue; if so, rerun the test.
    4. If the test system encountered a blue screen or critical error and the job remains stuck in Running:
      • In HLK Manager, right‑click the test and select Delete to remove the stuck result and force a clean rerun.
    5. If the test continues to fail after following the above steps, collect the required artifacts and open an HLK support case:
      • Full and exact test name as shown in HLK Studio (ArchitecturalDesign.SupportPowerManagedStates).
      • The HLK package file for the failing run.
      • If the failure category is System crashed: provide at least a kernel crash dump (mini‑dump is not sufficient).
      • If the failure category is Test crashed: provide user‑mode dump files.
      • All system and application event logs generated during the test.
      • Any additional debugging data (including the WFPLogo.wtl.trace and LogFile with non‑zero fail counts).
      • Then contact HLK Support as described in the HLK support documentation.

    The context does not provide any updated WFP‑specific behavioral requirements, best practices, or sample code for 25H2, nor does it document any change in HLK validation behavior for IPv6 transport traffic. Those details must be obtained directly from HLK Support or from WFP/HLK test reference documentation outside the provided context.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.