rss.livelink.threads-in-node

Publishing Blocklist Enforcement During Driver Signing

Garrettd — Wed, 13 May 2026 00:33:49 GMT

As part of Microsoft's commitment to improving Windows reliability through higher-quality driver content, we are extending the Driver Shiproom Publishing Blocklist to the signing stage of the driver submission process. Files that are already blocked from publishing to Windows Update due to known reliability issues will now also be rejected at the time of signing. This change helps partners identify problematic files earlier in their workflow and prevents known-bad content from entering the ecosystem.

Note: This blog is intended for Microsoft partners who submit drivers for signing through the Partner Center portal or API.

What's Changing

Today, the Driver Shiproom Flighting and Gradual Rollout processes evaluate thousands of drivers for reliability issues. When individual binaries repeatedly are determined to cause reliability issues in drivers, they're added to the Driver Shiproom Publishing Blocklist and automatically rejected at publishing.

With this update, we are extending that same check to the signing stage. Going forward, if a signing submission contains a file that appears on the Publishing Blocklist, the submission will be rejected before the driver is signed. Partners will receive an error identifying the problematic file so they can take corrective action.

Key points:

The Publishing Blocklist is maintained by Microsoft based on files that have been determined to cause reliability issues across multiple driver submissions.
This check runs during the signing request — before the driver is signed and before any publishing request is created.
If your submission contains a blocklisted file, you will receive an error message identifying which file triggered the rejection.

Note: The Driver Shiproom Publishing Blocklist is not related to the Microsoft Vulnerable Driver Blocklist or the Malicious Driver Blocklist. A file appearing on the Publishing Blocklist does not mean it is malicious or vulnerable.

What This Means for Partners

If your submission is rejected

If your submission contains a blocklisted file, it will fail at the Validation stage. The error report will include a message identifying the specific file and version:

"The driver submission has been rejected because file name: [filename] with version: [version] is blocked."

To resolve:

Review the error message to identify which file in your submission is on the Publishing Blocklist.
Remove or replace the problematic file in your driver package.
Resubmit the driver for signing.

If you use API automation

If your build pipeline automates driver signing submissions, update your error handling to account for the new rejection reason. Submissions rejected due to a blocklisted file will return an error identifying the specific file. Failing to handle this response may cause your automation to treat the rejection as an unexpected failure.

Timeline

Milestone	Status
Publishing Blocklist enforcement at signing	May 2026

FAQs

Q: Will this affect submissions that are already signed?
A: No. This check applies only to new signing submissions going forward. Drivers that have already been signed are not affected. Existing publishing blocklist enforcement at the shiproom stage remains unchanged.

Q: Why was a file added to the Publishing Blocklist?
A: Files are added when Microsoft determines they cause reliability issues across multiple driver submissions.

Q: Is this related to the Microsoft Vulnerable Driver Blocklist or the Malicious Driver Blocklist?
A: No. The Publishing Blocklist is a completely separate program. It focuses on driver reliability, not security threats. It is enforced during the signing and publishing process (pre-distribution) via HDC, while the Vulnerable and Malicious Driver Blocklists are endpoint protection mechanisms that operate on Windows devices (post-distribution).

Q: What if I believe a file was incorrectly added to the blocklist?
A: Contact support through the Hardware Program support channel. Include the file name, your submission ID, and details on why you believe the file should not be blocked.

Q: Does this apply to both HLK-signed and attestation-signed submissions?
A: Yes. The Publishing Blocklist check applies to both HLK and attestation signing submissions.

Q: Will the Publishing Blocklist change over time?
A: Yes. Microsoft may add or remove files from the Publishing Blocklist as reliability data evolves.

Questions or feedback? Use the comments section below.

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

katiezb — Wed, 13 May 2026 00:20:58 GMT

Microsoft is pleased to announce that a refreshed Hardware Lab Kit (HLK) for Windows 11, version 25H2 is available starting May 12, 2026. This refreshed version replaces the previous version on the HLK Download site. The VHLK version is expected to be available within a week.

Partners may submit to WHCP using either the previous version or this refreshed HLK, provided passing results can be obtained (waivers acceptable).

What’s New

This release includes playlist updates for 25H2, 26H1, and 24H2 Server. Changes include 43 test additions (25H2), 8 additions and 2 removals (26H1), and 2 removals (24H2 Server). All additions correspond to existing hardware requirements — no new WHCP requirements are being introduced.

Preview Period for Playlist Changes

Starting with this release, we are introducing a preview period to give partners advance notice before new playlist requirements are enforced. This change is based on direct partner feedback requesting more preparation time for playlist updates.

How It Works

- May 12, 2026 — Playlist and Kit Available: The updated HLK kit and compatibility playlist will be published to MS Learn. Partners can download and begin testing against the new requirements immediately.

- May 12 – June 9, 2026 — Preview Period: During this window, the HDC submission system will continue using the previous playlist for enforcement. Partners will NOT be blocked by the new tests during this time. Use this period to deploy the updated kit, update your playlists, and validate your hardware.

- June 9, 2026 — Enforcement Begins: The HDC playlist will be updated. When the May Refresh kit and playlist are used for testing, all new tests will be enforced for submissions from this date forward.

- Additional information: Partners can continue to submit using RTM versions of the kit and RTM playlist

What You Should Do

- Download the updated HLK kit and compatibility playlist from MS Learn when available on May 12.

- Deploy the kit to your test environments.

- Run the new tests to identify any issues before enforcement begins.

- If you encounter test failures, file feedback through the standard WHCP support channels.

- Ensure your submissions are updated and passing by June 9, 2026.

Important Notes

- No changes will be made to the playlist during the preview period.

- Submissions made during the preview period (May 12 – June 9) will NOT be evaluated against the new tests.

- After June 9, submissions using the newest kit and playlist will follow standard enforcement (manual review or rejection) for missing required tests.

25H2 Playlist Updates

Removed Tests

No tests removed for this playlist.

Added Tests

GUID	Test Name	Additional Information
79cebcc5-8d0e-49d6-aca2-31addd53f588	Bluetooth - 4.0 Specification (2-Machine)	Migrated to TAEF framework
faf6358b-0863-42df-a95f-8b652a5af9f4	Bluetooth - L2CAP Performance (2-Machine)	Migrated to TAEF framework
30e16985-15b4-4048-af6a-eb58a70b2eb0	Bluetooth - LE Audio Broadcast (3-Machine)	Migrated to TAEF framework
af1a1399-b0d2-4782-8dae-2f12423731a1	D3D12 - Dawn End2End Tests	New Chromium-focused graphics driver validation tests within existing Windows and DirectX graphics requirements
346831f2-468b-4220-b13f-f7f496bc446c	D3D12 HEVC Playback test 48	Addresses regression gap
41aded74-1f59-4694-8c6d-2ebc655691f5	D3D12 HEVC Playback test 49	Addresses regression gap
c37399cc-b3fd-4c02-9767-26da05c99ae2	D3D12 HEVC Playback test 50	Addresses regression gap
be126366-ec51-4687-93a9-cc17e94a3ec1	HEVC Playback test 48	Addresses regression gap
130abb81-fdbc-42ff-8af1-d7877f268ae3	HEVC Playback test 49	Addresses regression gap
73697eca-671a-42b4-9889-2f783b4ccd1f	HEVC Playback test 50	Addresses regression gap
72205ee4-decf-41f8-8646-9dae0d572507	MITTI2C BasicIOKernel	I2C bus interface test, missing from playlist and re-adding
774bf853-aae2-4f1a-99a7-0650e7b82ec1	MITTI2C BasicIORead	I2C bus interface test, missing from playlist and re-adding
97845f14-9a27-428a-9568-1959f6537114	MITTI2C BasicIOSequence	I2C bus interface test, missing from playlist and re-adding
4968d46e-7999-4482-9b07-16999c9275d0	MITTI2C BasicIOWrite	I2C bus interface test, missing from playlist and re-adding
01705206-a298-47a8-9f3f-691da1c7608c	MITTI2C BusRecovery	I2C bus interface test, missing from playlist and re-adding
9fee93f3-8f12-47d8-8d7f-b770e9d062f9	MITTI2C CancelRead	I2C bus interface test, missing from playlist and re-adding
0a1a6003-90ee-449c-9e6d-129af7e51f93	MITTI2C CancelSequence	I2C bus interface test, missing from playlist and re-adding
b6863753-fa6e-4e8f-846f-a9a26d9dde61	MITTI2C CancelWrite	I2C bus interface test, missing from playlist and re-adding
c3e7de57-958a-4f17-a885-a11e82ea14be	MITTI2C ClockStretching	I2C bus interface test, missing from playlist and re-adding
d7adbfc3-e650-4be0-bdcd-8f2bb9446405	MITTI2C DeviceNACK	I2C bus interface test, missing from playlist and re-adding
3a2f7055-4c33-47da-8d58-1a38ac3310e6	MITTI2C LockUnlock	I2C bus interface test, missing from playlist and re-adding
f7412705-99a2-4ca1-ab9c-2a0d03c3544f	MITTI2C PerfRead	I2C bus interface test, missing from playlist and re-adding
31221b1b-15bf-486e-af13-933481a5422a	MITTI2C PerfSequence	I2C bus interface test, missing from playlist and re-adding
f0ee7dea-aafb-4b97-b6bb-367b46eee49d	MITTI2C PerfWrite	I2C bus interface test, missing from playlist and re-adding
27c2360a-f473-457b-b6f8-f89ccd2fba47	MITTI2C Power	I2C bus interface test, missing from playlist and re-adding
f0744097-2f8d-44d8-b681-2653fd5305a5	MITTI2C Stress	I2C bus interface test, missing from playlist and re-adding
4c812eca-069b-43a1-b1b4-d7fae82b4408	MITTSPI BasicFullDuplex	SPI bus interface test, missing from playlist and re-adding
495e0c8c-d2bc-40a7-9e59-c4439ab59e24	MITTSPI BasicIOKernel	SPI bus interface test, missing from playlist and re-adding
f705fdd0-8d99-4030-a3f5-782265d971a1	MITTSPI BasicIORead	SPI bus interface test, missing from playlist and re-adding
0d610181-6a58-4f88-9947-6a4fed658455	MITTSPI BasicIOSequence	SPI bus interface test, missing from playlist and re-adding
b0c8b3a1-d74e-428f-a6c8-c329190a2798	MITTSPI BasicIOWrite	SPI bus interface test, missing from playlist and re-adding
94301fab-3a16-403a-a557-de3ba4e5c9db	MITTSPI CancelFullDuplex	SPI bus interface test, missing from playlist and re-adding
1dafad19-35df-450b-b430-71aea505e245	MITTSPI CancelRead	SPI bus interface test, missing from playlist and re-adding
67ffe1cc-79cd-4023-b45b-315d55d1bca2	MITTSPI CancelSequence	SPI bus interface test, missing from playlist and re-adding
da562f6d-6ad5-4d63-bc3b-da83b40083ac	MITTSPI CancelWrite	SPI bus interface test, missing from playlist and re-adding
a459a690-4350-4510-ae40-14435f81109a	MITTSPI LockUnlock	SPI bus interface test, missing from playlist and re-adding
759ad7fd-ff00-467b-93dd-ef04bd7b5122	MITTSPI PerfFullDuplex	SPI bus interface test, missing from playlist and re-adding
16f0cadf-f47e-4091-b9be-bb4b7914dd54	MITTSPI PerfRead	SPI bus interface test, missing from playlist and re-adding
e6481502-d32b-4c54-8913-9d783537ac81	MITTSPI PerfSequence	SPI bus interface test, missing from playlist and re-adding
00686ee1-b0cd-4068-8007-cc367725f81c	MITTSPI PerfWrite	SPI bus interface test, missing from playlist and re-adding
ed58287c-f1d3-46f1-b0ee-8d46002d3d65	MITTSPI Power	SPI bus interface test, missing from playlist and re-adding
e9c4fbae-6385-4dff-a560-331f24fef036	MITTSPI Stress	SPI bus interface test, missing from playlist and re-adding

26H1 Playlist Updates (Playlist Only, No New HLK Kit)

Removed Tests

GUID	Test Name
f4f5a8a2-91fe-4508-a75c-24fe46c2b1f3	Display capture tests - Display Mode Change Performance
b80af82b-6d0b-4ac5-b649-4c02c1242570	DisplayMux Acpi block test

Added Tests

GUID	Test Name	Additional Information
346831f2-468b-4220-b13f-f7f496bc446c	D3D12 HEVC Playback test 48	Addresses regression gap
41aded74-1f59-4694-8c6d-2ebc655691f5	D3D12 HEVC Playback test 49	Addresses regression gap
c37399cc-b3fd-4c02-9767-26da05c99ae2	D3D12 HEVC Playback test 50	Addresses regression gap
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.
be126366-ec51-4687-93a9-cc17e94a3ec1	HEVC Playback test 48	Addresses regression gap
130abb81-fdbc-42ff-8af1-d7877f268ae3	HEVC Playback test 49	Addresses regression gap
73697eca-671a-42b4-9889-2f783b4ccd1f	HEVC Playback test 50	Addresses regression gap

24H2 Server Playlist Updates (Playlist Only, No New HLK Kit)

Removed Tests

GUID	Test Name
5bcada95-9836-4c64-bcb7-298ab27382cb	PrivateCloudSimulator - Device.Network.LAN.10GbOrGreater
6e757c1d-eef8-4d11-9a4c-c7e9a06140f0	PrivateCloudSimulator - System.Solutions.StorageSpacesDirect (MIN)

Added Tests

No tests added for this playlist.

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.

Resolved: 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

Frequently Asked Questions

What HLK version is being refreshed?

- The 25H2 HLK is being refreshed. This HLK supports certifying drivers for Windows 11, version 25H2 and Windows Server 2025.

How do I install the refreshed HLK?

- Visit the HLK download page, download the refreshed HLK, and run HLKSetup.exe.

- Note: The refreshed HLK cannot be installed alongside a previous version. A clean OS install is recommended for both Controller and Client.

What should I do if a previously passing test now fails?

- Triage the failure first, then open a CSS support case if the issue persists.

How often are HLK refresh releases expected?

- Microsoft currently evaluates releasing a refreshed HLK each quarter.

Can results from different HLK versions be merged for submission?

- No. Submissions should use results from a single HLK version.

Does this update apply to both client and server?

- Yes.

Is the VHLK also being updated?

- Yes.

What is the preview period for playlist changes?

- Starting with this release, we publish the updated playlist and kit before enforcement begins. This gives partners time to download, deploy, and test before new requirements are enforced on submissions.

When will the new tests be enforced?

- The HDC playlist will be updated on June 9, 2026. After that date, all new tests will be enforced for submissions using the updated kit and compat playlist.

Will I be blocked during the preview period?

- No. The HDC playlist will only be updated on June 9, 2026

Introducing Cloud-Initiated Driver Recovery for Windows Update

Garrettd — Tue, 12 May 2026 21:32:44 GMT

As part of Microsoft's ongoing commitment to improving Windows quality and reliability, we are introducing Cloud-Initiated Driver Recovery — a new capability that proactively rolls back problematic drivers delivered through Windows Update. When a driver is identified as having quality issues during our shiproom evaluation process, Microsoft can now initiate a recovery action from the cloud, replacing the problematic driver on affected devices without requiring manual intervention from the user or the hardware partner.

Note: This blog is intended for Microsoft partners who publish drivers through the Hardware Dev Center portal.

What's Changing

Today, when a driver published through Windows Update is identified after distribution to have quality issues, the remediation path relies on the hardware partner to submit an updated driver — or on end users to manually uninstall the problematic driver themselves. This creates a gap where devices may remain on a low-quality driver for an extended period.

With Cloud-Initiated Driver Recovery, Microsoft can now trigger a recovery action directly from the Hardware Dev Center (HDC) Driver Shiproom, rolling back a problematic driver to the previously known-good version via the Windows Update pipeline. This is handled through coordinated updates to the PnP driver stack and the driver flighting and publishing services.

Key points:

Recovery is initiated by Microsoft when a driver publishing request is rejected for quality reasons during shiproom evaluation.

The recovery action replaces the problematic driver with the previously installed version or the next best version available on Windows Update on affected devices.

Devices where a Driver Shiproom approved driver cannot be located will not attempt Cloud-Initiated Driver Recovery

Recovery is delivered through the existing Windows Update infrastructure — no new client agent or partner tooling is required.

Partners are not required to take any action. Microsoft handles the recovery end-to-end.

How It Works

Driver flagged in Shiproom — A driver previously published to Windows Update is identified as having quality issues through the Driver Shiproom evaluation process.
Recovery initiated — A recovery request is created from the Driver Shiproom, targeting the specific driver and its associated shipping labels.
Rollback instruction delivered via Windows Update — The Windows Update pipeline delivers the rollback instruction to affected devices, confirming an approved driver is available then uninstalling the rejected driver.

What This Means for Partners

No action is required from partners. Cloud-Initiated Driver Recovery is a Microsoft-managed capability:

You will be notified through the existing shiproom communication channels when a driver is rejected during flighting or gradual rollout.

The recovery does not affect your other published drivers or shipping labels.

You can continue to submit an updated driver through the normal submission and publishing process.

We encourage partners to continue monitoring their driver quality metrics in the Hardware Dev Center dashboard and to respond promptly to any shiproom feedback on rejected submissions.

Timeline

Milestone	Status
Manually validation and testing on selected Shipping labels	May - August 2026
Automatically included upon Flighting or Gradual Rollout rejection	Targeted September 2026

FAQs

Q: Will this affect drivers that are currently published and working correctly?
A: No. Recovery is only initiated for drivers that have been rejected for quality issues during the shiproom evaluation process. Drivers that are published and functioning correctly are not affected.

Q: Do I need to update my API automation or portal workflows?
A: No. Cloud-Initiated Driver Recovery is managed entirely by Microsoft. There are no new API fields, portal changes, or partner-side actions required.

Q: What happens after a recovery — can I submit a fixed driver?
A: Yes. After a recovery, you can submit an updated driver through the normal Hardware Dev Center publishing process. Once the updated driver passes shiproom evaluation, it will be published to Windows Update as usual.

Q: Will I be notified if one of my drivers is recovered?
A: Yes. You will receive notification through the existing shiproom communication channels when a recovery action is taken on one of your submissions.

Q: Does recovery affect all devices that received the driver, or only specific hardware targets?
A: Recovery is scoped to the devices and hardware targets associated with the specific shipping label. It does not broadly affect other hardware configurations or drivers.

Additional Information

Driver shiproom and publishing process: Publish a driver to Windows Update

Hardware Dev Center documentation: Gradual rollout

Updated Graphics Driver Publishing Policy: From 4-Part to 2-Part HWID + CHID Targeting

Garrettd — Tue, 12 May 2026 21:26:37 GMT

One of the top pieces of customer feedback in the graphics driver area is clear: "Windows Update downgrades my drivers." Today, we are announcing a policy change to how display drivers are published through Windows Update — allowing 2-Part HWID + Computer Hardware ID (CHID) targeting for new devices. This change gives customers more control over their display driver of choice while preserving OEM control over the devices they ship.

Note: This blog is intended for Microsoft partners — IHVs and OEMs — who publish display drivers through the Hardware Dev Center portal.

What's Changing

Today, display drivers published to Windows Update use 4-Part Hardware IDs for targeting. This broad targeting establishes a highest ranked driver on Windows Update — including devices where the customer installed a preferred driver version of their choice. The result: customers who actively manage their display drivers experience unwanted downgrades through Windows Update.

With this policy change, display drivers for new devices can be published using 2-Part HWIDs combined with Computer Hardware IDs (CHIDs) where appropriate. This narrower targeting model ensures that driver updates are scoped to the specific systems they are intended for, reducing unintended driver replacements across the ecosystem.

Key points:

Display loose-leaf drivers on new devices can target using 2-Part HWIDs + CHIDs.

CHIDs should not be included in the driver's INF — they are applied at the shipping label level in Hardware Dev Center.

This will allow devices not locked to a 4-part HWID driver to keep their user installed display driver of choice, instead of experiencing a driver downgrade from Windows Update.

IHV partners may publish graphics drivers on behalf of OEMs using 2-Part HWIDs and CHIDs, with OEM approval.

What This Means for Partners

For IHVs (Graphics Driver Publishers)

Update your shipping labels to use 2-Part HWIDs + CHIDs for display drivers targeting new devices.

During the pilot phase, share feedback with your Microsoft representative if 2-Part HWID + CHID targeting is insufficient for your scenario.

For OEMs

You retain full control over which drivers target your devices through CHID targeting.

If an IHV publishes on your behalf, confirm the CHIDs they use to match your intended device population.

No changes are required to your existing device manufacturing or driver packaging processes.

Timeline

Milestone	Timing
Pilot — Collect feedback where 2ID+CHID is insufficient for targeting. Share feedback with your Microsoft representative.	April 2026 - September 2026
GA — Enforce 2-Part HWID+CHID targeting display driver submissions on new devices (devices that have not had a 4ID Windows Update driver installed).	2026 Q4 - 2027 Q1

FAQs

Q: Does this affect drivers that are already published and working correctly?
A: No. This policy applies to new display driver submissions targeting new devices. Drivers that are currently published with 4-Part HWID targeting will continue to function as-is.

Q: What qualifies as a "new device"?
A: A new device is one that has not previously had a 4-Part HWID Windows Update driver installed. Devices with an existing 4ID driver history are not affected by the GA enforcement.

Q: Do I need to change my driver's INF?
A: Your INF should reference 2-Part HWIDs. CHIDs are applied at the shipping label level in Hardware Dev Center — they should not be included in the INF.

Q: What if 2-Part HWID + CHID targeting doesn't work for my scenario?
A: During the pilot phase (starting April 2026), share your feedback with your Microsoft representative. We want to identify cases where this targeting model is insufficient before GA enforcement begins.

Q: Can IHVs still publish display drivers on behalf of OEMs?
A: Yes. IHVs can publish using 2-Part HWIDs and CHIDs with OEM approval. The OEM provides the appropriate CHIDs for their systems.

Q: Does this apply to all driver types or only display drivers?
A: This policy change applies specifically to display (graphics) drivers. Other driver classes are not affected at this time.

Additional Information

Driver publishing process: Publish a driver to Windows Update

Using CHIDs in shipping labels: Using Computer Hardware IDs (CHIDs)

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 — Fri, 22 May 2026 19:50:56 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

End of May 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.

Frequently Asked Questions (FAQ)

Q. My INF defines OS compatibility ranges for hardware IDs. Why is the CeilingOsCode field still null?

A. During the rollout phase of this feature, it is expected that the CeilingOsCode field in HardwareDriverMetadata may not yet be populated, even if OS compatibility ranges are defined in the INF.

This indicates that the field is available as part of your submission metadata, but population logic is still being gradually enabled across the service.

We will update this blog post once the rollout is complete. After that point, if you continue to observe this behavior, please reach out to us for further investigation.

Q. My shipping label failed validation due to a mismatch between the shipping label floor and INF CeilingOsCode. How can I proceed?

A. This validation failure indicates that the shipping label OS floor does not align with the maximum supported OS version (CeilingOsCode) derived from the INF for one or more selected Hardware IDs in the shipping label. To resolve this:

- Review and update your shipping label floor so that it is consistent with the OS compatibility range defined in your INF.
- Ensure that the selected floor does not exceed the supported ceiling.

For detailed guidance, refer to: Limit driver distribution based on Windows version

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

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

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, 28 May 2026 20:35:24 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? If you can't sign in to Engage Center with an account that is enrolled in the Hardware Program — for example, your enrollment is incomplete, you can't access the enrolled tenant, or you're trying to enroll for the first time — open a case through Partner Center support instead.

Go to Partner Center Support
Under Next Step choose the option to 'Provide issue details'
- Shows the Provide issue details button
Complete the form and submit the case. A confirmation email with a support request number will be sent to the contacts confirming receipt of the submission.

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?