Microsoft Hardware Dev Center:
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:
Code:
Response excerpt:
"OSPnPInfoMap": {
"WINDOWS_v100_RS3_FULL": {
"pci\\ven_test&dev_abcd": {
"Manufacturer": "RAID",
"DeviceDescription": "Virtual Raid Adapter",
"FeatureScore": null
}
}
}Example — after:
Code:
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 parsingThe 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.
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 upper bound of that range — the first OS version where the hardware ID is no longer listed in the INF.
CeilingOsCode value | Meaning |
|---|---|
| "WINDOWS_v100_X64_20H1_FULL" | This hardware ID is supported up to but not including Windows 10 20H1 (build 19041) for x64 |
| 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:
Code:
[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 onwardIn this case, PCI\VEN_8086&DEV_1234 is only applicable for OS builds in the range [17763, 25952). The CeilingOsCode for this hardware ID would reflect the upper bound of that range.
Rollout plan
Starting May 8, 2026, the HardwareDriverMetadata response will include the new CeilingOsCode field on each PnP entry in OSPnPInfoMap for packages submitted on or after that date. This field will not be backfilled — metadata for packages submitted before this date will remain unchanged and will not include CeilingOsCode.Note: We plan to use this ceiling data to improve driver targeting accuracy on Windows Update. We will communicate those changes separately as they approach rollout.
What you should do now
- Review your JSON parsing logic. If you consume HardwareDriverMetadata via the Hardware Dev Center API (as described in Driver package metadata ) and use strict schema validation, update your parser to accept the new CeilingOSCode property in OSPnPInfoMap entries.
- No changes are required to your driver packages, INF files, or shipping labels at this time.
- No resubmission is required, but if you want your existing packages to take advantage of the improved OS ceiling targeting, you should resubmit them after the rollout date. The CeilingOsCode field will only be populated for packages submitted on or after that date — metadata for previously submitted packages will not change unless resubmitted.
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.
Source:
Upcoming changes to driver metadata and publishing validations in Hardware Dev Center | Microsoft Community Hub
We're making improvements to how the Windows Hardware Dev Center (HDC) handles driver OS compatibility. These changes will help reduce driver installation...
techcommunity.microsoft.com
