Now accepting Windows 10, version 1903 submissions
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
HLK Version 1903 CompatPlaylist x86 x64 ARM64.xml
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.
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: