rss.livelink.threads-in-node

Sleep and PNP Fails on ARM

aklak — Tue, 28 Apr 2026 19:53:27 GMT

Issue Summary

I'm trying to certify a minifilter driver with HLK tests where the client is ARM64.

Because Microsoft's documentation states that physical hardware must be used, I purchased a Microsoft Surface (2025).

All the tests pass fine, except the DF FSMF – Sleep and PnP (disable/enable) with I/O Before and After Reliability test.

Parameters used

Parameter Name	Value
DQ	DriverBinaryNames='myDriver.sys'
Wpa2skAesSsid	kistestssid
Wpa2PskPassword	password
ResumeDelay	10
WDTFREMOTESYSTEM
TestCycles	4
IOPeriod	1
DriverVerifierAdditionalDrivers	MSDMFilt.sys
FSMFApiTest	TRUE
LogDriverVerifierEventsAsFailure	FALSE

Key Observations

- This test passes fine when certifying for x86_64.

- For ARM64 Virtual Machine, test passes.

- For ARM64 (Physical device), the test fails every time.

- When targeting another driver (not my own) `WDFILTER.sys` the test fails with the same symptoms

- When targeting Microsoft's sample driver [passThrough](https://github.com/microsoft/Windows-driver-samples/tree/main/filesys/miniFilter/passThrough) the test fails with the same symptoms

- The tests will pass fine with the TestCycle parameter set to `3`. It always fails when set to the default `4` cycles.

Errors/Warnings

- HLK Studio typically states that the test failed due to an unexpected reboot

- The client device's event viewer system logs show several instances of this log: Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: TE.ProcessHost.exe (6136) consumed 63349456896 bytes, MsMpEng.exe (5332) consumed 301400064 bytes, and HLKAcmengine.exe (6944) consumed 116539392 bytes.

- There are more logs regarding memory usage such as: `The Client License Service (ClipSVC) failed to start due to insufficient memory resources.`

- Right before the test fails, an error appears on the client where the `TE.ProcessHost.exe` process says: breakpoint reached

- The CMD prompt on the client right before the test fails will often show: `crash with exception code 0xC000027B occurred in module "TextInputHost.exe"`

Question

The above observations and errors/warnings seem to point to either the device or the test itself being the issue.

I've factory reset the laptop already and also created a fresh .vhlk to use in Hyper-V but the outcome is the same.

What is the root cause of the error? Is this a known problem? Can I workaround the problem? Is the problem the test or my device?

Introducing Control Over Driver Update Acceptance (DUA) Creation on Shared Driver Submissions

Cymoki — Mon, 20 Apr 2026 23:14:33 GMT

As part of Microsoft’s commitment to improving Windows quality through more predictable and reliable update delivery, we are introducing a new capability that will give submission owners control over Driver Update Acceptance (DUA) creation on shared submissions. This opt-in, per-sharing-shipping-label control will allow submission owners to explicitly block receivers from creating DUA submissions on shared content — providing greater flexibility and control over driver distribution. Receivers who use automation to create DUA submissions on shared products should update their code to handle the new error responses. Default behavior will remain unchanged — DUA creation will be allowed unless the owner explicitly enables the block.

Note: This blog is intended for Microsoft partners who share or receive shared driver submissions through the Partner Center portal or API.

What's Changing

A new per-sharing-shipping-label control will allow submission owners to block DUA creation by receivers of shared submissions. When selected on a sharing shipping label, receivers will not be able to:

Download the DUA shell
Create new DUA (derived) submissions

The only allowed action on a DUA-blocked shared submission is publishing the driver to Windows Update as-is.

Timeline

This new feature and the API will be available Starting May 18th.
Documentation and resources will be published before general availability

For Submission Owners

In the Partner Center Portal

When creating or editing a sharing shipping label, you will see a new option under the Properties section to block DUA creation by the receiver.

The option is off by default — existing behavior is preserved unless you opt in.
You can enable or disable this setting at any time, even on existing shipping labels.
The setting applies per sharing shipping label. Different shipping labels for the same submission can have different DUA policies.
If you share to multiple partners in a single request, the same setting applies to each resulting shipping label.

In the API

A new boolean field blockDuaCreation will be added to the existing recipientSpecifications object on sharing shipping labels, alongside the existing enforceChidTargeting property. It will be available in POST (create), GET (read), and PATCH (update) shipping label calls.

Creating a shipping label (POST):

{
    "recipientSpecifications": {
        "receiverPublisherId": "2600000",
        "enforceChidTargeting": false,
        "blockDuaCreation": true
    }
}

Reading a shipping label (GET): The blockDuaCreation field will be returned in the response so you can confirm the current setting.

Updating a shipping label (PATCH): You can now include recipientSpecifications (with blockDuaCreation and enforceChidTargeting) in the PATCH payload.

{
    "recipientSpecifications": {
        "blockDuaCreation": true,
        "enforceChidTargeting": true
    },
    "targeting": {
        .
        .
    }
}

For Submission Receivers

In the Partner Center Portal

When a submission owner has blocked DUA creation on a shared submission:

The "Upload new" and "Download DUA shell" buttons will be disabled (greyed out).
A message will be displayed: "Driver Update Acceptance (DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."

You can still create publishing shipping labels and publish the shared driver to Windows Update.

In the API

GET Submission: When DUA creation is blocked, the derivedPackage download link will be excluded from the response, and a restriction message will be included:

{
    "downloads": {
        "items": [
            { "type": "initialPackage", "url": "..." },
            { "type": "signedPackage", "url": "..." },
            { "type": "driverMetadata", "url": "..." }
        ],
        "messages": [
            {
                "message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."
            }
        ]
    }
}

POST Create Derived Submission: Attempting to create a DUA submission when blocked will return HTTP 412 Precondition Failed:

{
    "error": {
        "code": "DUACreationNotAllowed",
        "message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner for this shared submission."
    }
}

Action Required for API Consumers

If your automation creates DUA submissions on shared products, you must update your code to handle:

The new DUACreationNotAllowed error code (HTTP 412) when attempting to create a derived submission.
The potential absence of derivedPackage in the downloads.items list when calling GET Submission.
The new messages array in the downloads response, which will contain a restriction message when DUA creation is blocked.

Failing to handle these responses may cause your automation to break when an owner enables the DUA block on a submission shared with you.

Next Steps

Review your current sharing and DUA workflows to understand where this control might benefit your scenarios.
Engage with your partner counterparts to discuss how this feature might affect your existing agreements.
Update your API automation to handle the new DUACreationNotAllowed error code (HTTP 412) and the absence of derivedPackage and the new messages array in the downloads response in GET Submission responses if you create DUA submissions on shared products.
Contact support if you have questions or concerns about this capability through the Partner Center support channel.

⚠️ Important: Avoid strict JSON parsing

The Hardware Dev Center API may add new properties to responses at any time as part of non-breaking, additive changes. Your client must not use strict JSON deserialization that rejects unknown properties.

- - System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
  - Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
  - General — If you use schema validation or strict contracts, ensure they allow additional properties.

This applies to all Hardware Dev Center API responses, not just this change.

FAQs

Q: Will my existing DUA submissions be affected when the owner enables the block?
A: No. Existing DUA submissions are not retroactively affected. The block only prevents future DUA creation on the shared submission.

Q: Can the owner change the setting after the shipping label is already shared?
A: Yes. The owner can enable or disable the block at any time via the Partner Center portal or the PATCH API. The change takes effect immediately.

Q: Does this require a new API version?
A: No. The blockDuaCreation field is an additive, non-breaking change. Existing API clients that do not send or read this field will continue to work as before.

Q: What happens if the owner blocks DUA on one shipping label but not another for the same submission?
A: Each shipping label has its own DUA policy. A receiver will be blocked from creating DUAs only on the specific shared submission associated with a shipping label where the block is enabled.

Q: I receive shared submissions from multiple partners. Do I need to change anything right now?
A: If your automation creates DUA submissions on shared products, you should update your code to handle the new error responses. If you only publish shared drivers to Windows Update without creating DUAs, no changes are needed.

Q: What if I need DUA for a specific shared submission where the owner has blocked it?
A: Work directly with the submission owner. They can disable the block on the relevant shipping label at any time via the portal or the PATCH API, and the change takes effect immediately.

Q: Can I block DUA for specific Hardware IDs on a shipping label?
A: No. The setting applies to the entire sharing shipping label. Use separate shipping labels if you need different DUA policies per Hardware ID.

Additional Information

DUA documentation: Hardware submission update (DUA)
Hardware API documentation: Hardware API

Upcoming changes to driver metadata and publishing validations in Hardware Dev Center

Cymoki — Thu, 16 Apr 2026 04:03:29 GMT

We're making improvements to how the Windows Hardware Dev Center (HDC) handles driver OS compatibility. These changes will help reduce driver installation failures caused by drivers being offered to Windows versions outside their supported range.

This post explains what's changing, what you need to know, and what — if any — action you may need to take.

What's changing

New field in HardwareDriverMetadata: CeilingOsCode

We are adding a new nullable string property, CeilingOsCode, to the per-PnP entries in the HardwareDriverMetadata asset (documented at Driver package metadata ). This field represents the maximum OS version that a given hardware ID (PnP) supports, as determined by the INF file's OS version decorators.

Note: The CeilingOsCode field will only be populated for packages submitted after the feature rollout date. Packages submitted before this date will not have this field in their metadata — it will not be backfilled for existing submissions.

If you use the Hardware Dev Center API to retrieve driver metadata — via Get a submission  (the driverMetadata link) or Create Publisher Metadata  — the OSPnPInfoMap entries in the response will now include this additional property.

Example — before:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null

}

Example — after:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null,

"CeilingOsCode": "WINDOWS_v100_X64_20H1_FULL"

}

Do I need to take action?

In most cases, no. This is an additive change. The new property is nullable — it will be null when no OS ceiling is detected for a hardware ID. Standard JSON parsers (including Newtonsoft.Json and System.Text.Json) handle new, unknown properties gracefully by ignoring them.

If your tooling uses strict JSON validation that rejects unknown properties, you may need to update your deserialization logic to allow the new CeilingOsCode field.

⚠️ Important: Avoid strict JSON parsing

- System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
- Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
- General — If you use schema validation or strict contracts, ensure they allow additional properties.

This applies to all Hardware Dev Center API responses, not just this change.

What CeilingOsCode means

When your INF file contains multiple OS-decorated [Manufacturer] sections, each hardware ID is only applicable within a specific OS range. The CeilingOsCode reflects the last OS version wher the hardware ID is still listed in the INF - the inclusive upper bound of that range.

CeilingOsCode value	Meaning
"WINDOWS_v100_X64_20H1_FULL"	This hardware ID is supported up to and including Windows 10 20H1 (build 19041) for x64. It is not supported on the next OS version or above.
null	No upper bound detected — the hardware ID is supported on all OS versions from its floor onward.
(field absent)	The package was submitted before the feature rollout and metadata has not been regenerated.

Example

Consider an INF with two OS-decorated manufacturer sections:

[Manufacturer]

%MfgName% = Models, NTamd64.10.0...17763, NTamd64.10.0...25952

[Models.NTamd64.10.0...17763]

%DevDesc% = Install, PCI\VEN_8086&DEV_1234 ; present from build 17763

[Models.NTamd64.10.0...25952]

; PCI\VEN_8086&DEV_1234 is NOT listed here ; absent from build 25952 onward

In this case, PCI\VEN_8086&DEV_1234 is only applicable for OS builds in the range [17763, 25952). The CeilingOsCode for this hardware ID would reflect the upper bound of that range.

Rollout plan

Starting May 8, 2026, the HardwareDriverMetadata response will include the new CeilingOsCode field on each PnP entry in OSPnPInfoMap for packages submitted on or after that date. This field will not be backfilled — metadata for packages submitted before this date will remain unchanged and will not include CeilingOsCode.

Note: We plan to use this ceiling data to improve driver targeting accuracy on Windows Update. We will communicate those changes separately as they approach rollout.

What you should do now

Review your JSON parsing logic. If you consume HardwareDriverMetadata via the Hardware Dev Center API (as described in Driver package metadata ) and use strict schema validation, update your parser to accept the new CeilingOsCode property in OSPnPInfoMap entries.
No changes are required to your driver packages, INF files, or shipping labels at this time.
No resubmission is required, but if you want your existing packages to take advantage of the improved OS ceiling targeting, you should resubmit them after the rollout date. The CeilingOsCode field will only be populated for packages submitted on or after that date — metadata for previously submitted packages will not change unless resubmitted.

Questions or feedback?

If you have questions about these changes or encounter issues, please reach out through the support channel Support for Partner Center Dashboard - Windows drivers | Microsoft Learn.

How debugging TPM issues with WHLK

fmainz — Fri, 20 Feb 2026 15:57:26 GMT

Hello,
I'm currently running the WHLK on a TPM, and would like to understand why some tests are failing.
As the TPM is under development the error is much probably on the TPM side, but as I don't know what the tests are doing exactly it's very tricky.
Ideally I would need a way to enable as much logs as possible (to see what tpm commands are sent) - today I'm doing it with an spi analyser with a home made tpm interpreter ...
Is there also any way to have access to the source files of the tests (or a doc)? I'm currently relying only on the run logs (Te.wl) which are not sufficient to know at which step the test fail exactly.

Hardware Lab Kit API Updates and New Unreferenced File Check in February Refresh

Cymoki — Wed, 18 Feb 2026 20:44:54 GMT

What’s Changing?

The refreshed Windows Hardware Lab Kit (HLK) available starting February 2026 for Windows 11, version 25H2, Windows Server 2025, and Windows 11, version 24H2 will introduce a new check during HLK packaging. If the attached driver package includes one or more files that were not referenced by an .inf, the following warning will display at the end of packaging:

This will not affect package generation. Even if the warning appears, an .hlkx will still be created regardless.
It is highly recommended to validate that all files are referenced before testing. To do so, attach the driver package, create an .hlkx package (test results not necessary), and observe whether the warning appears. This validation can be performed any time after target selection.
The PackageWriter class in the Microsoft.Windows.Kits.Hardware.ObjectModel.Submission namespace will include the following updates:
- The AddDriver and AddReplacementDriver methods will include a new check for files in the driver package that were not referenced by an .inf file. This information will be available through the warningMessages output arg.
- There will also be new AddDriver and AddReplacementDriver overloads that expose the unreferenced file information through new output arguments in addition to warningMessages.
- See Creating a Package for code samples accessing data on unreferenced files using the updated API.
See Microsoft Learn for more details.

Actions Required

To address an unreferenced file, first navigate to the log path to see which attached files were not referenced.

If creating an original submission package...
- Option 1 (recommended): Remove the driver package from the project. Remove the unreferenced files from the driver package, then re-attach.
- Option 2 (recommended): Remove the driver package and modify the .inf to reference all the files. Re-test the driver and attach the modified driver package.
- Option 3: Keep the driver package attached, even with the unreferenced files. If submitting to HDC, please see this documentation for any policy updates regarding submissions with unreferenced files.
If creating a DUA package...
- Option 1 (recommended): Replace the attached driver package with a new one. Before re-attaching, remove any unreferenced files from the driver package.
- Option 2: Create a new original submission. Modify the .inf to reference all the attached files. Re-test the driver and attach the modified driver package.
- Option 3: Keep the driver package attached, even with the unreferenced files. If submitting to HDC, please see this documentation for any policy updates regarding submission with unreferenced files.

Tips

The new unreferenced file check supports most compressed files.
- If a file is compressed and its extension ends in “_”, the new warning will not appear so long as the decompressed version of the file is properly referenced by the .inf.
- If a .cab is included as a source location in the .inf’s [SourceDisksNames] section, HLK will examine the .cab’s contents during the unreferenced file check.
- If a .cab is referenced as a driver file in the .inf, it will be treated as such during the unreferenced file check, and the .cab’s contents will not be examined.
What is not supported:
- Attaching compressed .cat files.
- Attaching double-compressed files (e.g. A user compresses a file individually, and then packs the already-compressed file into a cab. Or a user compresses files into a .cab, and then compresses the .cab a second time so it now ends with an underscore).

Troubleshooting

Issue: “Failed to analyze driver package for unreferenced files”

This means that the HLK was not able to successfully finish the unreferenced file check. It does not indicate whether the attached files were referenced or not. Confirm there are no files missing from the attached driver package (i.e. the .inf referenced a file, but the file wasn’t attached).

Issue: A file is being identified as unreferenced, but the .inf includes the file.

It could be that the file is included in the .inf, but the .inf section that it’s in is not referenced properly. Run infverif to identify any unreferenced sections.

Also, check whether the file should (or should not) be placed under a subdirectory. The relative path of each driver file in the attached package must exactly mirror what is specified in the .inf file.

Issue: An .inf is being identified as an unreferenced file.

Confirm that the .inf is placed at the top root of the driver package (not in a subdirectory).

Issue: How do I check whether a file is signed?

Please see How to validate the Microsoft signature - Windows drivers | Microsoft Learn

PackageWriter.AddDriver Method | Microsoft Learn

PackageWriter.AddReplacementDriver Method | Microsoft Learn

Creating a Package | Microsoft Learn

For additional questions/assistance, please reach out to Microsoft support team by creating a support ticket here - Windows HLK Support

Updates to HLK Waiver Management - Coming Soon

AndyW — Wed, 18 Feb 2026 18:02:48 GMT

The HLK Team is making some updates to how waivers are tracked internally. This will not have any effect on the submission process at a high-level; filters will be published/downloaded in the same way, filters will get applied in the HLK the same way, and manual waivers will be applied to submissions in the same way. However, the IDs of all manual waivers will be updated because of the switch (IDs for waivers with automatic filters will remain the same).

We are aware that many of you keep track of waiver numbers internally so that you can track status/expiration and report to Microsoft if there are issues. So, if you have a list of waiver numbers that you track, please check the linked conversion table to prepare for the updated IDs for manual submissions.

To make the transition easier, there will be a grace period of 4 months after the effective date where submissions with manual waivers that still use the old IDs will still be accepted.

What Changes:

- IDs for manual waivers

What Doesn’t Change:

- How filters are downloaded

- How filters get applied to HLK projects

- How manual waivers get applied to submissions

Effective Date:

This change will go into effect in mid-March.

Action Required:

Download the linked waiver ID conversion table
Effective July 15, 2026 (after the grace period), submissions that reference legacy manual waiver IDs will be rejected. Partners should update the submission README to reference the new manuals waiver IDs during the transition period.

Questions?

If you have any questions now or have issues with waivers after the effective date, please reach out to HLK support.

HLK February Refresh Release for Windows 11 Version 25H2 and Windows Server 2025

Cymoki — Fri, 20 Feb 2026 17:03:00 GMT

Microsoft is pleased to announce that a refreshed HLK for Windows 11, version 25H2 and Windows Server 2025 is available starting February 17, 2026.

See below for detailed information on what’s new with this HLK refreshed version. The refreshed version of the HLK will replace the RTM version that is available on the HLK Download site. The VHLK version will be available in a week. Partners can submit to WHCP using either the RTM version of the HLK for Windows 11, version 25H2 and Windows Server 2025 or the refreshed HLK so long as passing results can be obtained (waivers acceptable).

What's new with this refresh?

We’ve introduced a small update to the HLK ARM64 Client setup experience by defaulting the emulation test setting to x86. This change aligns ARM64 client testing more closely with the existing AMD64 workflow, allowing partners to use a single, unified playlist for ARM64 testing, including both full and emulation scenarios. By reducing the need to manage multiple architecture specific playlists, we’re making it faster and easier for partners to stand up an ARM64 emulation test environment, minimize playlist configuration overhead, and focus on validating driver quality.  In the February refresh, partners can point to x86 as default emulation during automated script setup and enjoy the benefit of the single playlist deployment; in the following quarterly refresh, the default UI change will be available as well.

In addition, the refreshed kit includes a new check for unreferenced files. If the attached driver package includes one or more files that were not referenced by an .inf, a new warning will display at the end of packaging. The PackageWriter class in the Microsoft.Windows.Kits.Hardware.ObjectModel.Submission namespace has been updated to provide access to this new information from the HLK API. Please see Attention: HDC is changing the policy on signing unreferenced files in driver packages | Microsoft Community Hub for details.

25H2 Playlist updates: 

The following tables describe the playlist changes included with this refresh.

Removed tests:

GUID	TestName
7bcca3c4-3853-4f22-8eb2-effa2feeba57	Bluetooth - LE Audio VSAP (Broadcast) - [Render] Default, 32_1, 1 channel
4a3813a2-b24c-4784-b932-f2aa1e559747	Bluetooth - LE Audio VSAP (Broadcast) - [Render] Default, 32_1, 1 channel
25a4e032-246f-491d-b246-5be7dd8abb3e	Bluetooth - LE Audio VSAP (Broadcast) - [Render] Default, 32_2, 1 channel
4981e0a5-3583-4c49-896f-8342c70d75dc	Bluetooth - LE Audio VSAP (Broadcast) - [Render] Default, 32_2, 2 channels
b88a8d7b-4e43-41c2-b8e6-e6cb63a1f431	DXGI - Hybrid WDDM 3.0
f4f5a8a2-91fe-4508-a75c-24fe46c2b1f3	Display capture tests - Display Mode Change Performance
b80af82b-6d0b-4ac5-b649-4c02c1242570	DisplayMux Acpi block test
d0aaac5c-7c4c-488c-8352-14c49bc2ac67	NDISTest 6.0 - [1 Machine] - 1c_NdisRequestCov
5d6ac688-70fd-4163-8313-ffa2922b2afd	NDISTest 6.0 - [1 Machine] - 1c_WMICoverage
5f53cf62-a767-4469-92e6-1bca087193fd	NDISTest 6.0 - [2 Machine] - 2c_Priority
16084044-7baf-48ca-abe8-ae68062bebef	RepeatPublishWriteTag
d7e5b99f-d655-484c-a4ed-6467976d7813	RepeatTagReading
0cc234e0-9513-48fd-8b5d-1ef9ce168941	RepeatTagReadingLonghaul

Added tests:

GUID	TestName	Additional Information
9d59f9d8-ca18-42db-8bc7-a50bf071af00	Driver Attribute Test	This test is being added to the playlist. It reports the version of the WDK used to build the driver package. This test does not currently cause any failures as it is reporting only.
9f351400-f4fa-42b1-8c53-7affb526ee78	GRFX Adapter - Unreleased Features Block	Our new GRFX Adapter Unreleased Features Block Test will prevent graphics drivers from showing full support for unreleased features. Once a feature has been released, we will check that the system passes the corresponding HLK tests associated with the feature and remove it from the unreleased feature list.
d3d5e718-9313-4de6-9b38-41facdfd6314	Wlan Test - Connect to an enterprise network using MLO	Adding missing test that supports existing WHCP requirements.

26H1 Playlist (only) updates, no new HLK Kit: 

Removed tests:

GUID	Test Name
b88a8d7b-4e43-41c2-b8e6-e6cb63a1f431	DXGI - Hybrid WDDM 3.0
16084044-7baf-48ca-abe8-ae68062bebef	RepeatPublishWriteTag
d7e5b99f-d655-484c-a4ed-6467976d7813	RepeatTagReading
0cc234e0-9513-48fd-8b5d-1ef9ce168941	RepeatTagReadingLonghaul
067dba2c-6ee8-48a8-bb23-11182608f64c	BitLocker TPM + PIN + USB and Recovery Password Tests
ce9e5b64-8903-4025-bccf-a99d65663cf8	BitLocker TPM and Recovery Password Tests for NONAOAC devices with Legacy PCRs
5aac52da-a57c-4a12-aaac-de878a62bb08	BitLocker Tpm And Recovery Password tests for AOAC devices with PCR[7]
8a4641a2-4fc6-4447-9d94-fdf402ca263c	BitLocker Tpm And Recovery Password tests for AOAC devices with Legacy PCR's
8c7a62bb-7f02-4a16-b37d-711cc9026e17	BitLocker TPM and Recovery Password Tests for NONAOAC devices with PCR[7]

Added tests:

GUID	Test Name	Additional Information
d3d5e718-9313-4de6-9b38-41facdfd6314	Wlan Test - Connect to an enterprise network using MLO	Adding missing test that supports existing WHCP requirements.
067dba2c-6ee8-48a8-bb23-11182608f64c	BitLocker TPM + PIN + USB and Recovery Password Tests	Replacing existing BitLocker Tpm+PIN+ USB and Recovery Password tests.
721864b7-a33e-4831-bfb3-7e04e67a6f87	BitLocker Device Encryption Test	New HLK test, doesn't raise WHCP bar as we use software APIs to determine hardware capability for DE.
ba380fe0-7d56-432e-b504-56b73201d08a	BitLocker TPM and Recovery Password Tests for AOAC devices	Replacing BitLocker Tpm and Recovery password tests for AOAC devices with PCR[7] and  BitLocker Tpm and Recovery password tests for NONAOAC devices with Legacy PCRS.
008d97d3-1535-4abe-b0c4-9663e5e12b1f	BitLocker TPM and Recovery Password Tests for NONAOAC devices with Legacy PCRs	Replacing BitLocker Tpm and Recovery password tests for NONAOAC devices with Legacy PCRS.
e922e6ac-a3ca-4e7f-a4c6-4b3ce685ec4f	BitLocker TPM and Recovery Password Tests for NONAOAC devices with PCR[7]	Replacing  BitLocker Tpm and Recovery password tests for NONAOAC devices with PCR[7].

Troubleshooting and Known Issues: 

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening HLKX generated from this release on separate system.

Submission packages from this release are generated in a new schema and a newer version of the HLK Studio is required to open it.

Solution: Install/Update to a newer of HLK or HLK Studio

Existing HLK Controller installations may be kept as is and do not need to be reinstalled as it is not supported to update just the HLK Studio on an existing HLK Controller instance. An HLK Studio only instance from the latest HLK may be installed on a separate system to open these HLKXes.

Issue: Wi-Fi tests regressed due to removal of TestNetv2.0 dependencies.

The TestNetv2.0 was removed from the HLK test infrastructure, causing some Wi-Ffi tests to regress due to not being able to invoke “testnetv2.0/ccrun.exe”. The list of affected tests can be found below:

Wi-Fi Direct Basic Discovery Tests – Functional
Wi-Fi Direct Basic Pairing Tests – Functional
Wi-Fi Direct Basic Reconnect Tests – Functional
Wi-Fi Direct Legacy Pairing Tests – Functional
Wi-Fi Direct Service Discovery Tests – Functional
Wi-Fi Direct Service Pairing and Reconnect Tests – Functional

This issue will be fixed on a future refresh of the 25H2 Hardware Lab Kit

Frequently Asked Questions

What HLK version is being refreshed?
- The 25H2 RTM HLK is being refreshed, this HLK helps support certifying drivers for Windows 11, version 25H2 and Windows Server 2025. For the following FAQ’s, the 25H2 RTM release will be referenced to as “RTM HLK” and the upcoming release in February 2026 will be referenced as “refresh HLK.”
How can I tell what version of the HLK I have?
- The distinction between RTM HLK and refreshed HLK will be in the last digits of the HLK studio version, 10.1.26100.X
  - The RTM HLK Studio version is 10.1.26100.1
  - The refresh HLK Studio version is 10.1.26100.X

The HLK Studio version information can be located by clicking ‘About’ in the upper right corner of studio.

How do I install the refreshed version of the HLK?

1. To install the refreshed version of the HLK, visit the HLK download page: Windows Hardware Lab Kit | Microsoft Learn
2. Download the refreshed HLK
3. Run HLKSetup.exe

Notes

- Ensure your current HLK projects are finished before attempting to use the same system for the HLK refresh.
- The refreshed HLK cannot be installed on a system that already has the RTM HLK, this goes for both Controller and Client. It is highly recommended to start with a clean install of the OS for both.

How should I address a test that was passing on the RTM HLK but now failing on the refreshed HLK?
- Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
- Next, open a CSS case. Click the following link for more information on opening a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

Going forward, will Microsoft be updating the HLK regularly?
- Yes, Microsoft is transitioning into this servicing model for the HLK, which maintains overall test quality and reduces dependency on errata.

How often are the HLK refresh releases expected?
- Our current plan is to evaluate releasing a refreshed HLK each quarter.

Does this update apply to client and server?
- Yes

Can results from an RTM test run and a Refreshed test run be merged and used for submission?
- No, submission should be completed with either the RTM or refreshed HLK.

Will the refreshed HLK continue to support merged packages for multiple-OS submissions?
- Yes

Is the VHLK also going to be updated?
- Yes

Attention: HDC is changing the policy on signing unreferenced files in driver packages

Cymoki — Wed, 29 Apr 2026 18:53:02 GMT

Today, HDC signs all files contained in a submitted driver package (.cab/HLKx), regardless of whether they are referenced by the INF.
With the upcoming change, any files in a submitted package that are not referenced by the INF will be returned unsigned.

Impact on Windows Update Publication

Driver packages published to Windows Update will include only INF‑referenced files.
This means customers receiving driver updates will install packages that contain only the files required by the INF.

To help minimize disruption:

Starting February 23, HDC will enable this policy in “On with Logging Only” mode.
- Submissions will be processed normally.
- Partners will be able to see whether this change affects their packages through either HDC submissions or the HLK:
  - HDC - The signing logs provided in HDC submissions are available in both the UI and API. Note: if the submission does not contain any unreferenced files, the logs will not be present.
  - HLK - February 2026 HLK refresh release will present a warning when the driver package is added to the submission package if the driver package contains files that are not referenced in an INF.
- Microsoft will collect partner feedback through bug reports and direct engagement. This will allow us to identify any scenarios that require special handling or further consideration.
After feedback is reviewed, Microsoft will announce the date when the policy changes to “On and Enforced” mode where any files in a submitted package that are not referenced by the INF will be returned unsigned.

Why this change matters

This change improves package integrity and aligns WU deliveries with the set of files your INF declares, reducing the risk of unsigned and unreferenced artifacts in distributed driver bundles.

Who is impacted

OEMs, IHVs, and driver developers who submit packages to HDC for signing.
Partners who include helper tools, debug utilities, or extra artifacts in packages without INF references.

What you need to do (checklist)

Audit your packages for unreferenced files (files not listed in INF sections such as SourceDisksFiles, CatalogFile, or other driver package manifest references. More information can be found here: INF SourceDisksFiles Section - Windows drivers | Microsoft Learn and to validate whether there are unreferenced files please pick up the latest HLK here: Windows Hardware Lab Kit | Microsoft Learn
Ensure the driver package only contains the files needed for the functioning of the driver package
Validate your package with the latest HLK validation tools before submitting to HDC.
Note: The February 2026 refresh of the HLK will showcase a warning at package creation time if unreferenced files are found in the driver. See What's new in the Hardware Lab Kit | Microsoft Learn for more information.
Update automation if you have it to create submissions or process signed packages to avoid adding unreferenced files.
If using the HDC API for submissions, update your automation to account for a new asset that will be returned ("type": "unreferencedFilesReport",
"url": "<SAS URL from Hardware API>"). See Get product data - Windows drivers | Microsoft Learn for more information.

Note: Starting April 27th, 2026, the ability to get the Unreferenced File Report through the API will be enabled. This is to ensure there is ample time for users of the API to adjust their code to account for the new download type being returned.

Important operational detail: When enforcement starts, HDC will continue to accept packages that contain unreferenced files; those unreferenced files will simply be returned unsigned. This initial implementation does not reject submissions for unreferenced files; stricter enforcement may be considered later.

Timeline

Start enforcement of “On with Logging Only” mode: February 23rd.
Update of enforcement of “On and Enforced” mode: To be announced – when any files in a submitted package that are not referenced by an INF will be returned unsigned.

How this works in practice

Output you receive from HDC: The returned package may contain unsigned unreferenced files alongside signed INF referenced files. Signed driver bundles published to WU will no longer contain files unreferenced in an inf.

Links & resources

Get a submission - Windows drivers | Microsoft Learn
What's new in the Hardware Lab Kit | Microsoft Learn
Partner Center doc & support: Support for Partner Center Dashboard - Windows drivers | Microsoft Learn

Frequently asked Questions

Q1: What is an “unreferenced file”?
A: An unreferenced file is any file in your submitted package that is not listed in an INF. More information can be found here: INF SourceDisksFiles Section - Windows drivers | Microsoft Learn. Such files will not receive embedded signatures in this phase. Note: If adding files to an INF ensure that they are referenced correctly, if they are not then they will be treated as an unreferenced file. INF Verif in the WDK can assist in ensuring the files are referenced correctly.

Q2: What happens if I submit a package with unreferenced files?
A: During the “On with Logging Only” mode, submissions will be processed normally, and partners can see whether this change will affect them. During the “On and Enforced” mode, HDC will return the driver package; only the INF referenced files will be signed. The unreferenced files will be returned unsigned. Driver packages published to Windows Update will include only INF‑referenced files.

Q3: Will my package be rejected?
A: Not in the initial phase. We may move to stricter enforcement later (e.g., rejecting packages that contain unreferenced files). We’ll publish dates and guidance well in advance.

Q4: What will be published to Windows Update?
A: Only INF referenced files will be included in the signed driver bundles that are published to Windows Update.

Q5: Do nested CAB files get embedded signing?
A: No. HDC does not perform embedded signing on nested CAB files; those components are protected by catalog signing and are out of scope for this change.

Q6: I have runtime dependencies that aren’t in the INF (e.g., firmware blobs, config files, user mode DLLs). What should I do?
A: If such a file is needed at runtime, it must be referenced in the INF to be signed and delivered via WU. Otherwise, it will be returned unsigned and will not be included in WU bundles. Plan to add appropriate INF references or maintain your own distribution for those artifacts.

Q7: How can I check for unreferenced files?
A: Partners will be able to see whether this change affects their packages through either HDC submissions or using the HLK:

HDC - The signing logs provided in HDC submissions are available in both the UI and API. Note: if the submission does not contain any unreferenced files, the logs will not be present. Examples:
- HDC On and Logging message:
  - Warning: This submission contains one or more files that are not referenced by any INF in the submitted driver package. These files have been signed and published; however, in a future update, files not referenced by an INF will no longer be eligible for signing or publishing. For additional information on unreferenced files, see the documentation
- HDC On and Enforced message:
  - Attention: This submission contains one or more files that are not referenced by any INF in the submitted driver package. Files not referenced by an INF are not eligible for signing or publishing. For additional information on unreferenced files, see the documentation.

Note: The messaging above will be seen at the submission level, though it is possible that the initial submission package does not contain unreferenced files, but the derived package contains additional files which are unreferenced. In this case, the partner verbiage would be displayed at the derived submission level, and not at the top-level submission.

HLK - February 2026 HLK refresh release will present a warning when the driver package is added to the submission package if there are unreferenced files included in the driver package.

Q8: How are symbol files handled since they are not referenced by an INF?

A: Symbol files today are not included in the signed driver package that is returned. This behavior is not changing, and symbol files do not need to be referenced in an INF. Including symbols with your driver package is highly recommended.

Q9: Will HDC fail submissions that contain unreferenced files?
A: Not in this phase. Submissions will still be accepted; unreferenced files will be returned unsigned. Stricter enforcement may be considered later after partners have time to adapt.

Q10: How can I tell what files are signed by Microsoft?

A: How to validate the Microsoft signature - Windows drivers | Microsoft Learn

Q11: Where can I get help?
A: If you need direct assistance, open a Partner Center support case and reference this policy change. Support for Partner Center Dashboard - Windows drivers | Microsoft Learn

Windows Hardware Compatibility Program - Guidance for Windows 11, version 26H1 Release

AndyW — Tue, 18 Nov 2025 22:55:15 GMT

Building on the recent WIP Blog post, we’re releasing WHCP and HLK for Windows 11, version 26H1 to support partners working on engineering efforts.

This release is focused on enabling new platforms and is not intended for existing or previously released silicon. For mainstream products, continue using Windows 11 version 25H2 and its HLK to maintain compatibility with the current Windows 11 release.

There’s no expectation for most devices or components to certify on both 25H2 and 26H1.

Submission Pre-requisites

If you’re submitting for 26H1, please ensure:

OS Version: Windows 11, version 26H1 (Build 28000)
HLK Version: Windows 11, version 26H1 (Build 28000), and using the matching 26H1 Playlist
Downloads:

o HLK - Windows Hardware Lab Kit

o Playlists - https://aka.ms/HLKPlaylist

Target Architecture

Required Playlist(s)

ARM64

HLK Version 26H1 CompatPlaylist x64 ARM64.xml

HLK Version 26H1 CompatPlaylist ARM64_x86_on_ARM64.xml

X64

HLK Version 26H1 CompatPlaylist x64 ARM64.xml

System-Level Submissions: Must use 26H1 certified/signed drivers

This alignment ensures consistency across WHCP and HLK for silicon enablement and validation.

To avoid submission rejection, all required playlists and tests must be fully executed. For devices with ARM64 processors, HLK must run on each required playlist listed above, and the resulting logs should be included for submission.

Please refer to the HLK Getting Started Guide for details on HLK client setup and playlist use.

Partner Dev Center Opening Date

Starting from 11/18/2025, Partner Dev Center will accept submissions for Windows 11, version 26H1 packages that meet the pre-requisites mentioned above.

FAQ

Q: Will there be a 90-day transition period for system-level submission?

A: No – Since this release emphasizes new platform support, all components and drivers are expected to qualify under the same release. Therefore, the traditional 90-day transition period does not apply. In other words, system-level submissions for 26H1 must preinstall with drivers that are certified and signed for 26H1.

Q: Can a pre-released version of OS and/or HLK be used for submission?

A: No – To ensure full compatibility, HLK logs generated from the final release of both the OS and HLK are required for 26H1 submissions.

Driver Isolation Ruleset Changes for WHCP and Attestation Submissions

Cymoki — Wed, 03 Dec 2025 21:30:25 GMT

In November, Hardware Dev Center enforced stricter driver isolation requirements using the existing InfVerif /h validation. While InfVerif /h is already in use across WHCP and Attestation workflows, this update raises the bar for what qualifies as a compliant submission. These changes will impact both WHCP and Attestation driver packages submissions and are designed to help increase the security and quality of the Windows driver ecosystem.

Action for Partners

To help ensure that your driver submission passes HDC validation checks, run InfVerif /h on your driver package before submission. InfVerif /h testing is automatically executed as part of the Windows 11 version 25H2 HLK. Additionally, you can get the latest version of InfVerif by downloading the most recent Windows Driver Kit (WDK). The tool is located in the \tools folder of your WDK installation (e.g., C:\Program Files (x86)\Windows Kits\10\tools). To apply the 25H2 ruleset, use the command:
InfVerif /h /rulever 25h2

For additional information on the errors and how to address them:

Running InfVerif from the Command Line - Windows drivers | Microsoft Learn

INF Validation Errors and Warnings - Windows drivers | Microsoft Learn

Additional information about InfVerif /h:

InfVerif /h - Windows drivers | Microsoft Learn

Information about viewing your certification level in Partner Center:

Update a hardware submission - Windows drivers | Microsoft Learn

Questions?

If you have any questions or issues, please reach out to our support team. For details on how to contact support, see Get support for Partner Center dashboard issues - Windows drivers | Microsoft Learn.

Action Required: Account Verification for Windows Hardware Program Begins October 16, 2025

NatachaC — Thu, 30 Apr 2026 21:25:23 GMT

4/13/26 Update for partners experiencing challenges regaining access to the Hardware Dev Center

We've heard your feedback. We know that some partners whose accounts were suspended following Account Verification are experiencing challenges regaining access to the Hardware Dev Center (HDC). Protecting the security of the Windows ecosystem remains our highest priority, and we are adding a temporary process to accelerate the reinstatement experience for partners who are able to resolve outstanding compliance requirements.

Opening a support case is the fastest path towards reinstatement. Partners may request reinstatement through Hardware Program support. If reinstated, all compliance issues must be resolved prior to regaining access to HDC.

Encountering issues with the support experience? Make sure you are signed in using the email address associated with your Hardware Program account in Partner Center. Case creation is now live on Microsoft EngageCenter where you should see the following options for Product: Windows Developer Center.

Still unable to submit a ticket? The only official channel to get support is by opening a ticket as described above. However, we know some partners have been having challenges with that workflow, which we’re planning to address in a future update. Until then, you can reach out for support at aka.ms/HDC-Account-Verification-Support and someone from our team will reach out to assist.

Before submitting a reinstatement request, please review the information below and the Account Verification guidance in Partner Center to ensure all required verification steps are completed.

Original Post

Effective October 16, 2025, Microsoft will initiate mandatory account verification for all partners in the Windows Hardware Program who have not completed account verification since April 2024.

Required Actions for Partners:

Review and update your Legal Info in Partner Center to ensure it is current and accurate.

Prepare to complete the account verification process when notified.

Monitor your verification status on the Legal Info page in Partner Center to ensure all requirements are met and your account remains in good standing.

To successfully complete Account Verification:

The primary contact email address must be a monitored work account that can send and receive email. Generic or group email addresses are not permitted; use an individual address in the format you@yourcompany.com.

The name on the government-issued ID must match the Partner Center Primary Contact. Acceptable forms of ID include a valid passport, driver’s license, or other national identification.

Identity verification must be completed within 30 days of receiving the request. Failure to do so will result in rejection and suspension from the hardware program.

Blockers that will prevent successful verification include:

Failure to complete identity verification within 30 days.

Primary contact email address is not a monitored work account or is a group/generic address.

Mismatch between the name on the government ID and the Partner Center Primary Contact.

Incomplete or outdated information in the Legal Info page on Partner Center.

Partners who fail to complete Account Verification by the deadline, or who do not meet the requirements, will have their status set to Rejected and will be suspended from the program.

For more information on what is required to successfully complete verification or how to check status of your account, please review Verify Your Account Information - Partner Center | Microsoft Learn. If you have questions or need assistance, please contact our support team as described on Get support for Partner Center dashboard or HLK issues - Windows drivers | Microsoft Learn.

Update: Account Verification Completed

Account verification for the Windows Hardware Program has now concluded. Accounts that did not successfully complete account verification and received a Rejected verification status have been suspended from the Windows Hardware Program, and submissions from these accounts are no longer permitted.

Partners whose accounts were suspended may request reinstatement by submitting an appeal through Hardware Program support. Appeals must include either:

Supporting evidence that the suspension was issued in error, or
A clear business justification explaining why access to the Windows Hardware Program is required

Appeal requests that do not include supporting evidence or a business justification are not reviewed.

Windows Hardware Compatibility Program - Windows 10 Certification Deprecation Plan

AndyW — Tue, 07 Oct 2025 19:14:52 GMT

As part of our ongoing commitment to transparency and ecosystem readiness, we are sharing the Windows Hardware Compatibility Program (WHCP) and Hardware Lab Kit (HLK) end-of-support plan for Windows 10, in alignment with its upcoming end-of-support (EOS) milestone on October 14, 2025.

Key Updates

WHCP Windows 10 Certification Deprecation

WHCP will begin deprecating the certification process for Windows 10 following its official end-of-support date on October 14, 2025. Windows 10 LTSC 2021 release (22H2) and HLK 22H2, which will remain supported through the Extended Security Updates (ESU) program in 2026.

For Windows Server certification, HLK versions 1809 and 22H2 will continue to be used for Windows Server LTSC releases until their respective EOS dates described under Server Policy. https://aka.ms/WHCP

How this deprecation affects you

Hardware Dev Center

o HDC will continue to accept HLK packages for all Windows 10 versions. We will announce timelines for when HDC will stop accepting packages built on unsupported HLK and Windows 10 versions. Further announcements on the timeline will be shared on our blog.

o Partners are strongly encouraged to transition to supported HLK versions to avoid disruptions in certification workflows.

HLK & Windows 10 Supports

o Effective October 14, 2025, Microsoft will end support for all unsupported Windows 10 versions and their corresponding HLK releases, except for the versions supported through Extended Security Updates (ESU) and Windows Server LTSC programs. After this date, Microsoft Premier Support will no longer accept HLK cases for unsupported versions.

o As of October 14, 2025, downloads for unsupported HLK releases will be removed from https://learn.microsoft.com/en-us/windows-hardware/test/hlk/.

This deprecation plan is designed to provide clarity and predictability as we collectively transition toward modern platforms. For additional context on the Windows 10 ESU program and lifecycle, please refer to the public announcement: https://techcommunity.microsoft.com/blog/windows-itpro-blog/when-to-use-windows-10-extended-security-updates/4102628.

Stay secure with Windows 11, Copilot+ PCs and Windows 365 before support ends for Windows 10 | Windows Experience Blog

We appreciate your continued partnership and look forward to supporting your success through this transition.

Windows Hardware Compatibility Program - Guidance for Windows 11, version 25H2 Release

AndyW — Fri, 03 Oct 2025 21:14:45 GMT

To support the Windows 11, version 25H2 release, the Windows Hardware Compatibility Program is set to accept submission for the release. However, any submission package must meet the pre-requisites to help ensure compatibility between OS and HLK.

Windows Hardware Compatibility Requirements – Windows 11, version 25H2

https://aka.ms/whcp

Submission Pre-requisites

OS and HLK minimum acceptable build

o Windows 11, version 25H2 (Build 26200.6584)

o HLK Kit version will display as 26100.6584

Playlist and Kits –
- https://aka.ms/HLKPlaylist
- https://go.microsoft.com/fwlink/?linkid=2335804

The table below illustrates the required playlists for testing each processor architecture:

Target Architecture

Required Playlist(s)

ARM64

HLK Version 25H2 CompatPlaylist x64 ARM64.xml

HLK Version 25H2 CompatPlaylist ARM64_x86_on_ARM64.xml

X64

HLK Version 25H2 CompatPlaylist x64 ARM64.xml

Please refer to the HLK Getting Started Guide for details on HLK client setup and playlist use.

Deferment of Partner Dev Center SBOM Validation

The WHCP SBOM requirement (Device.DevFund.Security.SoftwareBillofMaterials) is deferred and will be enforced by Hardware Dev Center for CRA compliance beginning in H2 of 2026. However, Microsoft recommends all driver submissions to include SBOMs. Additional guidance for Device.DevFund.Security.SoftwareBillofMaterials will be provided in advance to H2 2026.
Partners will be given notice as soon as there is a set enforcement date during a future release, along with guidance on how to meet any new requirements.

WHCP continues to support a secure supply chain throughout our signing process. That said, the EO on Cyber Security is a call to action from the U.S. Government, so we continue to encourage that our partners seek to enable a secure supply chain as stated in the NIST guidance.

90-day N-1 Driver Transition Period for System-level submissions

To qualify for Windows 11, version 25H2 system-level qualification with Windows 11, 24H2 qualified drivers, the standard 90-day transition period can be applied through 01/09/2026.
Errata 225900 is available to filter the “System Logo Check” failure when testing Windows 11, version 25H2 system with Windows 11, version 24H2 qualified drivers. To apply, please download and apply the latest Errata Filter Package

Signing with the new 2023 Microsoft UEFI certificates: what submitters need to know

Pratishtha — Wed, 24 Sep 2025 05:53:28 GMT

Note: This blog is intended for Microsoft partners who submit UEFI binaries for signing—such as OEMs, IHVs, ISVs, and other device builders. If you are a Windows IT administrator or enterprise customer, please refer to Act now: Secure Boot certificates expire in June 2026.

Certificate expirations and continuity

Microsoft Corporation UEFI CA 2011 (Expiration: June 2026) → replaced by:

Microsoft UEFI CA 2023 for UEFI application submissions
Microsoft Option ROM UEFI CA 2023 introduced for Option ROM submissions

Important: Expiration does not invalidate binaries already signed with the 2011 cert. Those remain trusted on devices that still have the 2011 CA in their DB.

Why the rollout is careful

Microsoft began introducing the new Secure Boot certificates in 2023, and while many newer devices already include them, a significant number of existing systems still need to be updated. To ensure a smooth and safe transition, Microsoft is taking a phased and measured approach to deploying these updates. Past internal testing revealed that some devices had firmware compatibility issues, which have since been resolved in collaboration with OEMs. This experience informed our decision to proceed cautiously, validating updates across diverse hardware configurations before broader deployment.

For organizations managing Windows updates, Microsoft offers different paths to receive these certificate updates—either by allowing Microsoft to manage the rollout automatically or by handling the update process independently. These options, along with detailed guidance for IT-managed environments, are outlined in the blog post Act now: Secure Boot certificates expire in June 2026.

Transition timeline: October 2025 → June 2026

From October 20, 2025, each approved submission will return two signed files instead of the usual one:

One binary signed with the existing 2011 UEFI CA
One binary signed with a 2023 UEFI CA:
- UEFI application submissions: Microsoft UEFI CA 2023
- Option ROM submissions: Microsoft Option ROM UEFI CA 2023

This will happen through June 2026, when the existing 2011 CA expires and signing ceases with the 2011 CA.

Install-time detection logic

Your installer must check the Secure Boot DB for the 2023 certs:

If present → install/use the 2023-signed binary
If absent → install/use the 2011-signed binary

✅ Windows helper script (PowerShell)

# Requires: UEFIv2 PowerShell module # Install-Module -Name UEFIv2 -Force Import-Module UEFIv2 $db = Get-UEFISecureBootCerts db function Test-CertPresent([string]$thumbprint) { $db | Where-Object { $_.SignatureThumbprint -eq $thumbprint } | ForEach-Object { return $true } return $false } $UEFI2023Thumb = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" $OptionROM2023Thumb = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" $hasUEFI2023 = Test-CertPresent $UEFI2023Thumb $hasOptionROM2023 = Test-CertPresent $OptionROM2023Thumb if ($hasUEFI2023 -and $hasOptionROM2023) { Write-Host "Install 2023-signed binaries" exit 0 } else { Write-Host "Install 2011-signed binaries" exit 1 }

✅ Linux helper script (Bash)

#!/bin/bash UEFI2023 = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" OPTIONROM2023 = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" db=$(mokutil --list-db 2>/dev/null) if echo "$db" | grep -q "$UEFI2023" && echo "$db" | grep -q "$OPTIONROM2023"; then echo "Install 2023-signed binaries" exit 0 else echo "Install 2011-signed binaries" exit 1 fi

(Replace mokutil with efi-readvar if preferred.)

✅ Windows C APIs

The Windows win32 API, GetFirmwareEnvironmentVariableExw, can be used to retrieve the values of the Secure Boot DB database to determine which signed binary to use.

Some devices may not trust all 3P CAs

Some devices manufactured for specific use case configurations (e.g., Secured-Core PCs) may not trust the Option ROM CA or the other third-party CAs by default. Test your target platforms and coordinate with OEMs if your product depends on these certs. Most OEMs’ firmware has a UEFI menu option to switch Secure Boot configurations.

Quick reference: certificate names and SHA-1 thumbprints

Certificate	Subject String	SHA-1 Thumbprint
UEFI CA (2011)	Microsoft Corporation UEFI CA 2011	46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3
UEFI CA (2023)	Microsoft UEFI CA 2023	B5EEB4A6706048073F0ED296E7F580A790B59EAA
Option ROM CA 2023	Microsoft Option ROM UEFI CA 2023	3FB39E2B8BD183BF9E4594E72183CA60AFCD4277

Coming soon: changes to signing requirements

Beginning in October 2025, Microsoft partners submitting binaries for signing with the third-party UEFI CA must undergo an annual security audit conducted by a Microsoft-approved independent partner specializing in security code reviews. For SHIM submissions, the SHIM Review Board process is sufficiently rigorous and meets this requirement. However, when the Review Board flags risks they can't cover, such as proprietary, non-SHIM code that is included with the submission, then you must also complete the independent security code audit.

Stay tuned for further announcements on this blog, including how to identify a qualifying partner to conduct the audit.

Submitter checklist

Prepare your submission process to handle two returned files (2011 and 2023 signed).
Update your installers to detect the 2023 certs and select the correct binary.
Keep shipping the 2011-signed binary along with the 2023-signed binary until most devices have updated their UEFI trust anchors – Microsoft will provide an update when this happens.
If you try dual-signing, test comprehensively across your target fleet.
Engineer for crypto agility (avoid hard-coded assumptions about key sizes or algorithms).

FAQs

Q: Will my existing 2011-signed binary stop working when the cert expires?
A: No. Existing signatures remain valid on devices that still trust the CA in DB.

Q: What about Post-Quantum Cryptography (PQC)?
A:Microsoft and the UEFI Forum are working together to ensure the ecosystem is ready. Guidance will be published in stages—focus now on crypto agility and update mechanisms. Microsoft’s PQC roadmap is published here: Microsoft Quantum | Quantum Roadmap

Additional information

Secure Boot CA update website: Windows Secure Boot certificate expiration and CA updates - Microsoft Support
Article for OEMs and ODMs: Windows Secure Boot Key Creation and Management Guidance - Microsoft Support
Blog post announcement: Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog

[Microsoft Partner Center]Cannot access Feedback ID in Collaborate

mimimomo1982 — Mon, 22 Sep 2025 05:35:18 GMT

Could you please help us to check error message in Feedback page.

Error:

Due to recent changes in our security and access policies, some content or functionality may be unavailable to certain users. For additional support, please create a ticket with Partner Center and reference Message Code: 715-123220. https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create

After Create New id successfully, and then we cannot access the ID anymore.

HLK July Refresh Release for Windows 11 Version 24H2 and Windows Server 2025

Cymoki — Tue, 08 Jul 2025 20:54:50 GMT

Microsoft is pleased to announce that a refreshed HLK for Windows 11, version 24H2 and Windows Server 2025 is available starting July 8, 2025.

This release of the HLK contains only infrastructure changes. See below for detailed information on what’s new with this HLK refreshed version. The refreshed version of the HLK will replace the RTM version that is available on the HLK download site. The VHLK version will be available in a week. Partners can submit to WHCP using either the RTM version of the HLK for Windows 11, version 24H2 and Windows Server 2025 or the refreshed HLK so long as passing results can be obtained (waivers acceptable).

What's new with this refresh?

Upcoming HLKX Packager changes

This HLK refresh will increment the HLKX packager version to a newer version, the data format will not be readable by previous versions of the HLK Studio. Opening an HLKX saved from this version will fail with the message text "Failed to open package. Could not open package: (hlkx filename)" when opened from previous releases of the HLK Studio and will require installation of this version or newer to read it. HLK Studio in this refresh will continue to be backwards compatible and will be able to read, merge, and add drivers to submission packages that were saved from current and previous releases of the HLK.

Note that the HLK Installer supports installation of the HLK Studio components only to read and write HLKXes if HLK Controller functionality is not needed.

The submission portal will continue to accept HLKXes from older versions of the HLK, but any HLKX submitted after the switchover will return Driver Update Acceptable (DUA) HLKX shells in the new format when requested, while HLKXes submitted prior to the switchover will continue to be in the previous format. Without the refreshed HLK, the update will not be able to read and process DUA HLKX shells in the new format.

Action Required:

Note that HLKX files created in this release of the HLK will be generated in an updated format version. The user should be aware of scenarios which will and will not require an update to this version of the HLK or HLK Studio.

HLKXes generated from this release will be readable by this and future versions of the HLK Studio.
HLK Studio from previous releases of the HLK will not be able to read the data format of the upcoming version.
This release of the HLK is backwards compatible and will also be able to read HLKXes and HCKXes from current and past versions of the HLK.

Troubleshooting and Known Issues:

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening HLKX generated from this release on separate system.

Submission packages from this release are generated in a new schema and a newer version of the HLK Studio is required to open it.

Solution: Install/Update to a newer of HLK or HLK Studio

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening DUA shell downloaded from submission portal.

After the portal switches over to processing submissions in the new format, DUA shells for submission packages submitted to the portal after the switchover will return them in the new format. These DUA shells will not be readable without an HLK Studio installation that does not have the updated changes and will return the error "Failed to open package. Could not open package: (hlkx filename)"

Solution: HLK/HLK Studio instance should be updated to newer version.

Issue: Reinstall of HLK Controller fails with “Install did not complete successfully: An error occurred installing ‘Windows Hardware Lab Kit Infrastructure’”

This issue is caused by a missing check in the HLK installer to detect whether a newly supported version of SQL is already installed. When this occurs, the HLK SQL installer fails due to an existing instance with the same instance name.

Workaround:

After uninstalling the Hardware Lab Kit on the HLK Controller system:

Right-click on the “Start” button on the Windows taskbar and select the “Settings” menu option to launch the Windows Settings app.
From the Windows Settings app, select the “Apps” option, then select “Installed Apps”
Look for the item “Microsoft SQL Server 2022 (64-bit)” and uninstall it.
Attempt to install the Hardware Lab Kit again and confirm that it completes without errors.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: HLK Studio may throw InvalidOperationException when selecting targets

Enabling the Distributed Target Selection feature in HLK Studio may cause HLK Studio to crash with the error: “System.InvalidOperationException: A TwoWay or OneWayToSource binding cannot work on the read-only property 'RedistributeTests.'”

Workaround:

If this issue occurs in HLK Studio, disable the Distributed Target Selection feature.

From HLK Studio, select the “Configuration” menu option.
Select the “Options” item on the left side of the user interface
Under the “Distributed Testing” group box, look for the “Show Distributed Target Selection dialog when multiple matching targets are found” checkbox and uncheck it.
Confirm that the InvalidOperationException is no longer thrown when selecting targets in HLK Studio.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: Wifi tests regressed due to removal of TestNetv2.0 dependencies

The TestNetv2.0 was removed from the HLK test infrastructure, causing some Wifi tests to regress due to not being able to invoke “testnetv2.0/ccrun.exe”. The list of affected tests is:

- Wi-Fi Direct Basic Discovery Tests – Functional

- Wi-Fi Direct Basic Pairing Tests – Functional

- Wi-Fi Direct Basic Reconnect Tests – Functional

- Wi-Fi Direct Legacy Pairing Tests – Functional

- Wi-Fi Direct Service Discovery Tests – Functional

- Wi-Fi Direct Service Pairing and Reconnect Tests – Functional

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit

Frequently Asked Questions

What HLK version is being refreshed?

The May refresh HLK is being refreshed, this HLK helps support certifying drivers for Windows 11, version 24H2 and Windows Server 2025. For the following FAQ’s, the May 2024 release will be referenced to as RTM HLK and the upcoming release in July 2025 will be referenced as refresh HLK.

How can I tell what version of the HLK I have?

The distinction between RTM HLK and refreshed HLK will be in the last digits of the HLK studio version, 10.1.26100.X

The RTM HLK Studio version is 10.1.26100.1
The refresh HLK Studio version is 10.1.26100.X

The HLK Studio version information can be located by clicking ‘About’ in the upper right corner of studio

How do I install the refreshed version of the HLK?

Visit the HLK download page: Windows Hardware Lab Kit | Microsoft Learn
Download the refreshed HLK
Run HLKSetup.exe

Notes

Ensure your current HLK projects are finished before attempting to use the same system for the HLK refresh.
The refreshed HLK cannot be installed on a system that already has the RTM HLK, this goes for both Controller and Client. It is highly recommended to start with a clean install of the OS for both.

How can I tell if the errata I use was fixed in the refreshed HLK?

The list of errata fixed is available below

What do I do if the errata I use doesn’t appear to be fixed in the refreshed HLK?

If the errata is not on the fixed list the waiver can be used on both the RTM HLK as well as the refreshed HLK

What do I do if the errata I use is listed as fixed, but failures are still being seen in the test?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

How should I address a test that was passing on the RTM HLK but now failing on the refreshed HLK?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

Going forward, will Microsoft be updating the HLK regularly?

Yes, Microsoft is transitioning into this servicing model for the HLK, which maintains overall test quality and reduces dependency on errata.

How often are these refresh releases expected?

Current plan is to evaluate releasing a refreshed HLK each quarter.

Does this update apply to client and server?

Can results from an RTM test run and a Refreshed test run be merged and used for submission?

No, submission should be completed with either the RTM or refreshed HLK.

Will the refreshed HLK continue to support merged packages for multiple-OS submissions?

Is the VHLK also going to be updated?

HLK July Refresh Release for Windows 11 Version 24H2 and Windows Server 2025

Cymoki — Tue, 08 Jul 2025 20:53:43 GMT

Microsoft is pleased to announce that a refreshed HLK for Windows 11, version 24H2 and Windows Server 2025 is available starting July 8, 2025.

What's new with this refresh?

Upcoming HLKX Packager changes

Note that the HLK Installer supports installation of the HLK Studio components only to read and write HLKXes if HLK Controller functionality is not needed.

Action Required:

HLKXes generated from this release will be readable by this and future versions of the HLK Studio.
HLK Studio from previous releases of the HLK will not be able to read the data format of the upcoming version.
This release of the HLK is backwards compatible and will also be able to read HLKXes and HCKXes from current and past versions of the HLK.

Troubleshooting and Known Issues:

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening HLKX generated from this release on separate system.

Submission packages from this release are generated in a new schema and a newer version of the HLK Studio is required to open it.

Solution: Install/Update to a newer of HLK or HLK Studio

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening DUA shell downloaded from submission portal.

Solution: HLK/HLK Studio instance should be updated to newer version.

Issue: Reinstall of HLK Controller fails with “Install did not complete successfully: An error occurred installing ‘Windows Hardware Lab Kit Infrastructure’”

Workaround:

After uninstalling the Hardware Lab Kit on the HLK Controller system:

Right-click on the “Start” button on the Windows taskbar and select the “Settings” menu option to launch the Windows Settings app.
From the Windows Settings app, select the “Apps” option, then select “Installed Apps”
Look for the item “Microsoft SQL Server 2022 (64-bit)” and uninstall it.
Attempt to install the Hardware Lab Kit again and confirm that it completes without errors.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: HLK Studio may throw InvalidOperationException when selecting targets

Workaround:

If this issue occurs in HLK Studio, disable the Distributed Target Selection feature.

From HLK Studio, select the “Configuration” menu option.
Select the “Options” item on the left side of the user interface
Under the “Distributed Testing” group box, look for the “Show Distributed Target Selection dialog when multiple matching targets are found” checkbox and uncheck it.
Confirm that the InvalidOperationException is no longer thrown when selecting targets in HLK Studio.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: Wifi tests regressed due to removal of TestNetv2.0 dependencies

The TestNetv2.0 was removed from the HLK test infrastructure, causing some Wifi tests to regress due to not being able to invoke “testnetv2.0/ccrun.exe”. The list of affected tests is:

- Wi-Fi Direct Basic Discovery Tests – Functional

- Wi-Fi Direct Basic Pairing Tests – Functional

- Wi-Fi Direct Basic Reconnect Tests – Functional

- Wi-Fi Direct Legacy Pairing Tests – Functional

- Wi-Fi Direct Service Discovery Tests – Functional

- Wi-Fi Direct Service Pairing and Reconnect Tests – Functional

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit

Frequently Asked Questions

What HLK version is being refreshed?

The May refresh HLK is being refreshed, this HLK helps support certifying drivers for Windows 11, version 24H2 and Windows Server 2025. For the following FAQ’s, the May 2024 release will be referenced to as RTM HLK and the upcoming release in July 2025 will be referenced as refresh HLK.

How can I tell what version of the HLK I have?

The distinction between RTM HLK and refreshed HLK will be in the last digits of the HLK studio version, 10.1.26100.X

The RTM HLK Studio version is 10.1.26100.1
The refresh HLK Studio version is 10.1.26100.X

The HLK Studio version information can be located by clicking ‘About’ in the upper right corner of studio

How do I install the refreshed version of the HLK?

Visit the HLK download page: Windows Hardware Lab Kit | Microsoft Learn
Download the refreshed HLK
Run HLKSetup.exe

Notes

Ensure your current HLK projects are finished before attempting to use the same system for the HLK refresh.
The refreshed HLK cannot be installed on a system that already has the RTM HLK, this goes for both Controller and Client. It is highly recommended to start with a clean install of the OS for both.

How can I tell if the errata I use was fixed in the refreshed HLK?

The list of errata fixed is available below

What do I do if the errata I use doesn’t appear to be fixed in the refreshed HLK?

If the errata is not on the fixed list the waiver can be used on both the RTM HLK as well as the refreshed HLK

What do I do if the errata I use is listed as fixed, but failures are still being seen in the test?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

How should I address a test that was passing on the RTM HLK but now failing on the refreshed HLK?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

Going forward, will Microsoft be updating the HLK regularly?

Yes, Microsoft is transitioning into this servicing model for the HLK, which maintains overall test quality and reduces dependency on errata.

How often are these refresh releases expected?

Current plan is to evaluate releasing a refreshed HLK each quarter.

Does this update apply to client and server?

Can results from an RTM test run and a Refreshed test run be merged and used for submission?

No, submission should be completed with either the RTM or refreshed HLK.

Will the refreshed HLK continue to support merged packages for multiple-OS submissions?

Is the VHLK also going to be updated?

Action Required: HLK Submission Packager Changes Coming in July

Cymoki — Tue, 24 Jun 2025 23:01:41 GMT

The Hardware Lab Kit (HLK) packaging component is important for reading, writing, and packaging test results, as well as submitting drivers to the Hardware Dev Center (HDC) portal for certification and signing.

What’s Changing?

In July, an upcoming HLK refresh will update the submission packager version and format. Submission packages generated using this HLK refresh will be saved in a new data format and will not be readable by previous versions of HLK Studio.
The updated packaging components can read both current and previous data formats but will always write HLKX files in the new format. Older versions of the HLK Studio will not be able to read submission packages written in the new format.
The above applies to DUA HLKX packages as well.
The HDC portal will synchronize deployment of the new submission package format with the upcoming HLK refresh. .

Actions Required

To enable compatibility with the new format:

Watch for a notification and an upcoming HLK release announcement regarding the switch to the new submission package version and format on this blog and on the HDC portal.
Installations of older HLK Controller versions do not require updates for this scenario as submission packages from older versions of the HLK will continue to be accepted by the portal. An HLK Studio only instance can be installed on a separate system for opening and processing a DUA shell package returned after the update,
If the error "Failed to open package. Could not open package: (hlkx filename)" is encountered when opening a submission package in HLK Studio, it is recommended to install a newer version of HLK/HLK Studio. This error message may be indicating that the updated version of HLK Studio is necessary to read the latest submission package format.
Automation and tools utilizing the HLK Object Model may require additional dependencies to be deployed due to updates in these dependencies. These changes will be detailed in the HLK Documentation upon the release of the update.

Action Required: HLK Submission Packager Changes Coming in July

AndyW — Tue, 24 Jun 2025 21:55:10 GMT

What’s Changing?

In July, an upcoming HLK refresh will update the submission packager version and format. Submission packages generated using this HLK refresh will be saved in a new data format and will not be readable by previous versions of HLK Studio.
The updated packaging components can read both current and previous data formats but will always write HLKX files in the new format. Older versions of the HLK Studio will not be able to read submission packages written in the new format.
The above applies to DUA HLKX packages as well.
The HDC portal will synchronize deployment of the new submission package format with the upcoming HLK refresh. .

Actions Required

To enable compatibility with the new format:

Watch for a notification and an upcoming HLK release announcement regarding the switch to the new submission package version and format on this blog and on the HDC portal.
Installations of older HLK Controller versions do not require updates for this scenario as submission packages from older versions of the HLK will continue to be accepted by the portal. An HLK Studio only instance can be installed on a separate system for opening and processing a DUA shell package returned after the update,
If the error "Failed to open package. Could not open package: (hlkx filename)" is encountered when opening a submission package in HLK Studio, it is recommended to install a newer version of HLK/HLK Studio. This error message may be indicating that the updated version of HLK Studio is necessary to read the latest submission package format.
Automation and tools utilizing the HLK Object Model may require additional dependencies to be deployed due to updates in these dependencies. These changes will be detailed in the HLK Documentation upon the release of the update.

Removal of unwanted drivers from Windows Update

Cymoki — Tue, 24 Feb 2026 23:48:23 GMT

This blog post is intended to notify all Windows Hardware program partners that Microsoft has taken a strategic initiative to clean up legacy drivers published on Windows Update to reduce security and compatibility risks. The rationale behind this initiative is to ensure that we have the optimal set of drivers on Windows Update that cater to a variety of hardware devices across the windows ecosystem, while making sure that Microsoft Windows security posture is not compromised. This initiative involves periodic cleanup of drivers from Windows Update, thereby resulting in some drivers not being offered to any systems in the ecosystem.

2/24/2025 update:

Microsoft has completed the expiration of the first batch of drivers as of 02/23/2026. A thorough vetting was completed by Microsoft to ensure that the expiration of these drivers would not cause any feature disruption for current devices in the ecosystem. We are actively monitoring the ecosystem for any impact caused by the expiration and have a sound mitigation plan in place should it be the case. Please note that this was the first iteration of the WU cleanup and subsequent iterations will occur at a set cadence. Similar updates to the blogpost will not be made after every iteration similar to the one today.

Further details of the effort are as follows:

What category of drivers are targeted in the first cut of the cleanup?

The first phase targets legacy drivers that have newer replacements already on Windows Update.

What does “cleanup” mean in this context?

Cleanup here refers to the process of expiring drivers so that they are no longer associated with an audience in Windows update, resulting in them not being offered to any system. Technically, expiring a driver means removing all its audience assignments in Hardware Development Center, which stops Windows Update from offering that driver to devices.

Can partners republish a driver that was expired by Microsoft?

Yes, partners will be able to republish the drivers that were expired. Microsoft may require business justification as to why there was a need for republishing.

What happens to the cleaned-up drivers?

After the expiry, Microsoft will publish a blog post mentioning the end of the first cut of driver expiry. After that, there will be a 6-month window for partners to get back with concerns (if any). If no action is taken, the drivers will be permanently removed from windows update.

Will this be a one-time exercise or will similar instances occur in the future?

This is meant to be a regular exercise to optimize what windows update has to offer. We are beginning with the above-mentioned category of drivers but will expand to cover more categories of drivers that Microsoft deems fit to be expired from windows update. Each time such a cleanup occurs, Microsoft will communicate broadly so that partners know what to expect.

In summary, Microsoft removing legacy drivers from Windows Update is a proactive measure to safeguard security and improve driver quality for Windows users. As a partner, you should review your drivers in the Hardware Program, be aware of what your current drivers in the ecosystem are, and make sure that any unwanted/legacy driver is proactively expired from windows update. Moving forward, expect this cleanup to be a routine practice, and prepare for the introduction of new publishing guidelines that will help all windows users keep their systems in a secure and reliable state. We appreciate your cooperation in this initiative, as it helps ensure that Windows devices run on the most secure and compatible drivers available.