Now accepting Windows 10, version 1903 submissions
Published Apr 18 2019 04:25 PM 16.6K Views
Microsoft

Windows 10, version 1903 hardware driver submissions for Windows Hardware Compatibility Program (WHCP) are now being accepted at the Partner Center for Windows Hardware. The updated version of the Windows Hardware Lab Kit (HLK), along with updated playlists for testing Windows 10, version 1903 hardware may be downloaded from the Hardware Dev Center. As with previous releases of the HLK, this version is intended for exclusive testing for Windows 10, version 1903. Previous version of the HLK remain available from the Hardware Dev Center.

 

Windows 10, version 1903 WHCP Playlists
For the 1903 release playlists have been consolidated by Windows architecture resulting in 2 playlists:

Testing Target Architecture

Playlist

X86/x64/ARM64

HLK Version 1903 CompatPlaylist x86 x64 ARM64.xml

ARM64*

HLK Version 1903 CompatPlaylist ARM64_x86_on_ARM64.xml

*Testing of ARM64 requires two playlists. Please refer to the HLK ARM64 Getting Started Guide for details on ARM64 HLK client setup.


Windows 10, version 1903 based systems may ship with drivers that achieved compatibility with Windows 10, version 1809 until July 18, 2019
Partners looking to achieve compatibility for systems shipping Windows 10, version 1903 may factory-install drivers for components that achieved compatibility with Windows 10, version 1809 until July 18, 2019.
Errata 49105 filter is available to mask the failures seen when testing a Windows 10, version 1903 system and the latest errata filter package.


Driver Update Acceptable (DUA) Shell Update
The Driver Update Acceptable (DUA) Shell has been updated to generate from the 1903 version of the Package Manager. All new DUA submission requests will be generated from this new version of the Package Manager. Please ensure you are HLK Version 1903 when opening DUA Shell packages, otherwise errors will result.


INFVerif and APIValidator Updates
A new validation check has been added to InfVerif in 1903 and may cause driver packages that have passed previous versions of InfVerif to fail. This new check helps to prevent functional errors occurring due to a file copy paradigm that can produce non-deterministic results. The paradigm can result in the wrong file being used by a device causing the device to fail.

 

The affected file copy paradigm is when multiple DDInstall Sections copy different source files to a single destination file using the CopyFiles directive. If the multiple DDInstall sections all get processed on the same system, these CopyFiles could conflict. For example, if two different devices are using the same driver but different install sections or in some offline driver imaging and deployment scenarios. Because multiple source files from the different DDInstall Sections get copied to the same exact single destination file, the different source files from different DDInstall Sections overwrite each other so that the last file copied is the one placed in the destination file path, which may not give the expected results.


For example, the driver may not survive an OS upgrade properly although the symptoms of this fact may not be obvious, depending on the exact nature.
Guidance on how to implement similar functionality using best practices is provided here. If you run into an issue not covered by the guidance please file a collaborate feedback bug and include your INF and output of InfVerif.


https://docs.microsoft.com/windows-hardware/drivers/devtest/inf-verif-error-1330.

 

Partners should be aware that Hardware Dev Center will be using this 1903 version of InfVerif on all new submissions once Certification and signing for 1903 opens on the portal. This means any submission, no matter what OS it’s for, will be tested against this 1903 InfVerif version at submission time. This new check will be part of the declarative requirements. These tools are available in the 1903 WDK.
Impact to you:

  • All new Certification Submissions will require this check to pass in order to receive Declarative = True.
    • This includes DUA submissions and resubmissions for any OS level. This means you may have had Declarative = True previously, but the new submission will not receive Declarative = True.
  • Submissions made prior to 1903 RTM will not be touched or modified by this change.
9 Comments
Copper Contributor

Hi MSFT Team, @Andrew_Kovar 

I notice MSFT remove below information for WHCP 1903 compared 1809

Just double confirm below requirement removed from latest WHCP 1903, right?

********************************************************************************************************************************************

Windows Hardware Compatibility Product List (WHCPL) expiration

As Microsoft Windows transitions to a servicing model with more frequent update cycles, the Windows Hardware Compatibility Program (WHCP) must also evolve in order to accommodate the new release cadence. Because Windows branding remains constant throughout the accumulative OS updates, it is important to ensure the devices on the Hardware Compatibility List remains relevant. Starting August 1st, 2016, the Windows Hardware Compatibility List will host any WHCP qualified product for a period of no less than three years. A qualified product listing will be archived automatically after three years from the initial submission date of the product. A product listing can be renewed by explicit permission from Microsoft, or by retesting the device using the latest version of Windows and associated HLK for a WHCP submission. The product listing will be reinstated upon the completion of the WHCP submission process.

*********************************************************************************************************************************************

Copper Contributor

Hi, @Andrew_Kovar!

Could you please also provide updated "OS Code" values for Hardware Dashboard API sublmissions? At the moment it ends with "WINDOWS_v100_RS5_FULL".

Microsoft

@barry_b you are correct it has been removed from policy for Windows 10, version 1903. You may find the updated WHCP Policy, along with the previous policy docs here: https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/whcp-specifications-policies

Microsoft

@avzhatkin the new OS Codes are: 

OS Code

Description

WINDOWS_v100_19H1_FULL

 Windows 19H1 X86

WINDOWS_v100_X64_19H1_FULL

 Windows 19H1 X64

WINDOWS_v100_ARM64_19H1_FULL

Windows 19H1 ARM64

 

We will also request the following page to be updated https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-product-data#list-of-operati.... Please let us know if you saw a different incomplete list.

Copper Contributor

@Andrew_Kovar, thanks for the info!

A similar list exists in the Inf2Cat tool. The version supplied with WDK 1903 allows to set '/os:10_19H1_X64', but the usage output of the tool shows values only up to RS4 (not even RS5).

Microsoft
@avzhatkin, This is a known issue with Inf2Cat. I'm glad you are able to manually set the OS level and this is what you should do until an update to the inf2cat tool is supplied by the kit.
Copper Contributor

@Andrew_Kovar, the page with dashboard REST API is still not updated. There was some change of plans or the update process just takes that long?

Copper Contributor

Hi ,

 

My feedback on this .

With Every Win10 Release MS is releasing new HLK . And that HLK is not compatible for lower operating systems . 

We now have 3 HLK . 

For Win10 - 1903 HLK

For Win 2019 - 1809 HLK

For Win 2016 - 1607 HLK  

 

Can MS release one HLK that has backward compatibility for Win 2019, Win 2016 ? . It becomes difficult to use different HLK for different OSes . 

Copper Contributor

Hello everyone,

Does anyone know why my HLK certified for testing Kernel drive failed to load with Windows 10 x64 version 1809 and 1909 OSes.

The driver property reports that:

"Windows cannot load the device driver for this hardware, The driver my be corrupted or missing: Error (Code 39)."

 

clipboard_image_1.png

 

It works with Windows 10 x64 1903.

I ran HLK studio version 1903 & 1909 for the target test machines are Windows 10 x64 1809, 1909.

My certification keys from the Windows Hardware Partner Center for a driver is:

clipboard_image_2.png

 

1) I ran all the requirements for my .sys driver file from a "software device" tab and they are all passed.

2) I ran the partial requirement tests for a "device manager" selections and these are passed. I ignored the tests those failed.

The tests run of 1) & 2)  for both target systems Windows 10 x64 1909 & 1809 OS.

 

What am I missing in my driver package submission?

I want to be able to install and test the functionality of my driver on all Windows 10 versions and Windows Server 2016 & 2019.

For this test driver package, I try to verify my certication for testing driver to with 3 different windows 10 x64 versions (1809, 1903 & 1909). but it only works for Windows 10 x64 1903. Failed on 1809 & 1909.

 

Thanks in advance.

Chau, Len

 

 

Version history
Last update:
‎Apr 22 2019 03:17 PM
Updated by: