Windows hardware compatibility program

Пролог

Начиная с версии Windows 10 1607 корпорация Microsoft ввела обязательную сертификацию сторонних драйверов по программе Windows Hardware Compatibility Program (новость об этом в блоге msdn , пост на хабре ). Работает это нововведение на чистых установках Windows 10 соответствующей версии с включенным режимом Secure Boot .

Несоблюдение этого условия в лучшем случае (при отключенном Secure Boot) приведет к появлению предупреждения:

Картинка с сайта: blog.tomsksoft.ru

В худшем — к запрету на установку драйвера:

Несмотря на наличие официальной документации по прохождению процедуры сертификации, этот процесс может быть сопровожден рядом неочевидных на первый взгляд сложностей. Ниже приводится поэтапный разбор всех подводных камней на примере прохождения сертификации драйвера веб-камеры для 32 и 64-битной версий Windows 10 с обновлением 1803.

Краткий обзор всей последовательности действий:

• Подготовка парка машин
• Развертывание тестового фреймворка Windows Hardware Lab Kit
• Создание и конфигурация тестового проекта
• Прохождение списка тестов
• Подготовка финального пакета с результатами
• Обработка результатов на серверах Microsoft и получение подписи

Дебют или этап подготовки

Очевидным предварительным условием для сертификации является наличие следующего:

• EV сертификата;
• Подготовленных компонентов драйвера (файлы .inf, .sys, .map, .pdb);
• Сгенерированного утилитой inf2cat (входит в состав Windows SDK ) cat-файла .

Файлы .sys и .cat должны быть подписаны EV сертификатом. Для этого используется утилита singtool из Windows SDK.

В нашем случае файлы .inf, .sys, .map, .pdb и .cat представлены в двух экземплярах для архитектур x86 и x64 соответственно.

Первым шагом к сертификации драйвера является прохождение серии тестов на совместимость оборудования для Windows. Для этих целей Microsoft предоставляет специализированный фреймворк Windows Hardware Lab Kit , ранее называвшийся Windows Hardware Certification Kit (HCK). А еще ранее этот же фреймворк носил имя Windows Hardware Logo Kit, что доставляет неудобство в поиске информации, так как по запросу HLK нередко выпадает устаревшая. С кратким обзором концепции тестирования можно ознакомиться по ссылке . В состав HLK входят серверная часть (включает в себя менеджер тестов HLK Controller и управляющую консоль HLK Studio ) и клиентская часть (HLK Client). Таким образом, HLK предполагает наличия тестового парка из как минимум двух машин.

Подготовка парка машин

Для серверной части HLK ограничением является необходимость развертывания на Windows Server 2012, Windows Server 2012 R2 или Windows Server 2016.

Начиная с релиза 1709 HLK поддерживает тестирование клиентов только соответствующей версии Windows 10 , предыдущие редакции кита предусматривали возможность работы с некоторым подмножеством обновлений этой операционной системы.

Табличка поддерживаемых версий:

Для организации тестирования нам понадобятся одна управляющая машина с серверной версией Windows и две тестовые машины с 32 и 64-битными версиями Windows 10 в одной сети. При наличии нескольких доступных клиентов одной битности их можно использовать совместно, проводя тестирование параллельно. Альтернативной конфигурацией, в случае тестирования драйвера для двух архитектур, может быть схема с одним контроллером и одним клиентом (предполагается смена ОС клиента между тестовыми сессиями). Однако в этом случае возможны проблемы с настройкой пулов тестовых машин и потерей результатов тестирования. Кто виноват и что делать в такой ситуации будет рассказано ниже.

Миттельшпиль или работа с HLK

Важно: рекомендуется использовать свежеустановленные версии Windows с английской локалью во избежание появления внезапных проблем с тестами. Вас предупреждали.

Дополнительно на всех машинах парка можно отключить энергосберегающий режим и приостановить установку обновлений Windows, дабы исключить прерывания процесса тестирования, который может продолжаться несколько часов.

Развертывание HLK

На контроллере устанавливаем свежескаченный HLK корректной версии. В нашем случае это HLK 1803, поскольку на клиентах будет установлена Windows 10 с обновлением 1803. Существует вариант установки одной HLK Studio, однако он полезен только для работы с финальными пакетами hlkx.

Картинка с сайта: blog.tomsksoft.ru

Так же на контроллере должен быть установлен EV сертификат, которым были подписаны .sys и .cat файлы. Он понадобится нам позже, на этапе подготовки пакета для сабмита в Microsoft.

Клиентская часть ставится на тестовые машины по сети с контроллера:

\\контроллер\HCKInstall\Client\setup.exe

Установка драйвера

На каждую машину нужно установить наш подопытный драйвер. Для этих целей используется утилита hdwwiz (выполнить из Windows -> Run -> hdwwiz).

Стоит упомянуть о такой замечательной особенности Windows, как наличие кэша драйверов Driver Store. Если ранее в системе был установлен драйвера с версией, равной или новее той, которую вы пытаетесь поставить сейчас, существует вероятность, что Windows проигнорирует ваши попытки и возьмет копию из кэша. Для того, чтобы окончательно удалить предыдущий инстанс, можно воспользоваться приложением Driver Store Explorer .

Картинка с сайта: blog.tomsksoft.ru

Фильтры и плейлисты

Иногда с релизом нового обновления Windows или новой версии HLK часть тестов ломается. Результатом выполнения любого из них является ошибка, которая позже помешает нам подготовить финальный пакет hlkx. Для исключения сломанных тестов из общего списка тестирования, Microsoft выпускает специальные пакеты фильтров (HLK Filters). До начала процедуры тестирования необходимо скачать на контроллер архив самых свежих фильтров , распаковать их по пути

C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Controller

и запустить приложение UpdateFilters.exe, расположенное там же.

Важно: рекомендуется устанавливать фильтры до начала тестирования, так как их эффект применяется только к запущенным после установки тестам. Чтобы изменить результаты уже проведенных тестов, необходимо в проекте HLK Studio перейти на страницу Results и нажать кнопку Apply Filters.

Картинка с сайта: blog.tomsksoft.ru

Кроме фильтров Microsoft поставляет специализированные плейлисты (HLK Playlist), изменяющие состав базового списка тестов. Скачиваем архив с актуальными плейлистами и распаковываем его на контроллере.

Важно: плейлист может быть применен только к чистому проекту. Использовать его на серии пройденных тестов не удастся.

Информацию по выпуску новых фильтров и плейлистов можно найти в блоге Windows Hardware Certification

Подготовка пула тестовых машин

Пришло время подготовить пулы наших клиентских машин. Они нам понадобятся на этапе создания проекта. На вкладке Configuration все машины отобразятся в Default Pool. Нужно создать свои пулы (кнопка Create Machine Pool) и перетащить в них машины из пула по-умолчанию.

Важно: в одном пуле должны находиться машины с одинаковой битностью.

Поле Status у каждой машины будет Not Ready — нужно щелкнуть по ним правой кнопкой и изменить статус на Ready.

Картинка с сайта: blog.tomsksoft.ru

Важно: иногда студия выдает ошибку на попытку изменить статус машины.

Кроме прочего, такая ситуация появляется, когда меняется ОС на тестовом клиенте, например, в схеме с одним контроллером и одним клиентом. Решается это удалением машины из пула (пункт Delete Machine в контекстном меню), что заставляет контроллер создать новый инстанс клиента с правильными характеристиками в Defaul Pool. Внимание, удаление машины приводит к удалению всех ассоциированных с ней результатов тестирования. Во избежание напрасной потери результатов нескольких часов работы, перед удалением машины следует подготовить финальный hlkx пакет, включающий все пройденные тесты. О подготовке файла hlkx будет рассказано далее.

Подготовка и запуск проекта

На странице Projects выбираем Create project и задаем проекту произвольное имя. Активируем проект двойным кликом по нему. Каждый проект может тестироваться только на машинах одной битности.

Картинка с сайта: blog.tomsksoft.ru

На странице Selection выбираем пул машин, на котором будет производиться тестирование. В списке отобразятся устройства, подключенные к машинам из этого пула. Отмечаем устройства, которые будут тестироваться.

Картинка с сайта: blog.tomsksoft.ru

Переходим на страницу Tests. Перед запуском тестов применяем плейлист нужной версии, распакованный из архива ранее. Отмечаем тесты, которые будут запущены для устройства. Следует обратить внимание, что некоторые тесты проходят в ручном режиме (обозначены иконкой человечка в столбце Type) и требуют некоторого пользовательского ввода на стороне клиентской машины. Их лучше отложить на потом и сначала отметить все автоматические.

Картинка с сайта: blog.tomsksoft.ru

Несмотря на всю подготовительную работу, некоторые тесты все же могут завершаться с ошибками, несвязанными напрямую с качеством тестируемого драйвера. Некоторые из них успешно проходятся со второй попытки. Успех выполнения других, в том числе весьма продолжительные тесты Concurrent Hardware And Operating System , по результатам наблюдений может зависеть от аппаратной начинки клиента. Логи результатов тестирования — основной помощник выявления проблем. Посмотреть их можно на странице Results.

Картинка с сайта: blog.tomsksoft.ru

Финальный пакет — это файл с расширением .hlkx (zip-архив), который содержит результаты тестирования. Именно его нужно сабмитить в Microsoft через Partner Dashboard для получения цифровой подписи Microsoft Windows Hardware Compatibility Publisher.

При его создании необходимо указать:

• Путь к директории с драйвером (в директории должны находиться inf/sys/cat файлы);
• Путь к директории с отладочными символами (pdb/map).

После нажатия на «Create Package» потребуется отметить:

• Целевые ОС;
• Locales (отмечаем English).

Картинка с сайта: blog.tomsksoft.ru

Создание финального пакета hlkx

Можно создавать неподписанные hlkx, например, просто для последующего открытия в студии. Для сабмита в Microsoft файл hlkx необходимо подписать EV сертификатом. Проще всего импортировать сертификат в систему и выбрать его в процессе создания пакета (кнопка Create Packageна странице Package). Получаем файл hlkx с результатами пройденных тестов.

Мерджинг пакетов hlkx

Этот этап выполняется, если вы проходите тестирование для нескольких платформ. В нашем случае, тестирование проводится для x86 и x64.

Для конфигурации с одним контроллером и одним клиентом меняем битность тестовой ОС, повторяем шаги по настройке клиента, переинициализируем машину под соответствующий пул.

Создаем проект для следующей платформы и повторяем весь процесс тестирования.

На шаге создания пакета hlkx дополнительно вызываем меню Merge Package и указываем подготовленный hlkx пакет для платформы другой битности.

Картинка с сайта: blog.tomsksoft.ru

У нас готов hlkx пакет для отправки в Microsoft.

Эндшпиль или сабмит финального пакета hlkx в Microsoft

Заходим под своим аккаунтом на https://partner.microsoft.com/en-us/dashboard/.

На панели слева выбирвает Drivers. Нажимаем Submit new hardware.

Картинка с сайта: blog.tomsksoft.ru

Заполняем поле Product name и загружаем наш пакет hlkx.

Картинка с сайта: blog.tomsksoft.ru

В разблокированной секции Certification заполняем поля тип устройства, дата анонса и опционально маркетинговое имя. Нажимаем Submit.

Картинка с сайта: blog.tomsksoft.ru

Через некоторое время получаем результаты сертификации. Подписанные компоненты драйвера можно скачать, нажав по кнопке Download signed files.

Картинка с сайта: blog.tomsksoft.ru

Конечный результат всех усилий:

На что следует обращать внимание

• Проверить соответствие версии HLK версиям Windows на клиентах;
• Настроить английскую локаль на клиентских машинах;
• Установить фильтры перед созданием проекта;
• Сохранить результаты тестирования в пакет hlkx перед удалением тестовой машины из пула;
• Применить плейлист нужной версии до запуска тестов;
• Смерджить пакеты hlkx, если тестирование проводится для нескольких платформ.

For many years, Microsoft has been using driver signing and the Windows Hardware Certification program to allow for devices to be able to market themselves as fully Windows Compatible. This included using the Windows Logo on both company packaging and web sites, as well as being on the Windows official hardware compatibility list. The program was also used to sign drivers for Windows to show they have passed testing and have not been modified since that testing. Microsoft had for many years been ramping up the requirements for drivers and devices to pass testing, some of which increased costs of devices and caused a long time to market delay. Microsoft has increased the requirements for devices again, now requiring all kernel based drivers to be signed, not just 64 bit. Also, EV Code Signing certificates from Symantec/Verisign are also now required for all driver submissions. Even with the added expense of just getting an EV cert, Microsoft has listened to OEM and ISV partners and reduced some of the requirements for Windows 7 and 8. 1, and went further in Windows 10. Microsoft also ported many more driver frameworks to Mobile, allowing for a single device driver to be written to run on PC, Tablet and Phones for the first time ever. Because of all these changes, Microsoft separated Windows 10 Compatibility Program from the Windows 7 and 8. 1 programs, allowing for a lower bar of entry for Windows 10 compared to older Windows OS’s. This does not change the bar of entry for devices that must work on Windows 7 and 8. 1 though, so you would only reap the benefits if you just targeted Windows 10. One example of a major change is in USB devices. Under Windows 10, testing of USB devices in our lab was straight forward. We hooked up the device with a USB 2. 0 hub in between, ran USB CV for verification of Chapter 9 compliance, then ran the standard tests for USB devices for Windows plus any extra tests based on device type. In Windows 8. 0, things changed considerably. All devices now had to be tested with USB 3. 0 controllers (and USB 3. 0 devices had to be hooked up to a USB 3. 0 hub). This required us to move 1 system in our main lab that had built in USB 3. 0 ports (which was in its early days) to our WCL lab. We later purchased off the shelf USB 3. 0 certified PCIe controllers for the rest of the lab systems that were to run Windows 8. There was 1 test for USB devices that was added for 8. 0 that caused a LOT of headaches for us and our clients. This test was the USB 3. 0 Topology test. To do this test, regardless of what USB level the device supported, we had to hook up the device into several different topologies, all manually.

• 3. 0 Controller > Device
• 3. 0 Controller > 3. 0 Hub > Device
• 3. 0 Controller > 2. 0 Hub > Device
• 2. 0 Controller > Device
• 2. 0 Controller > 2. 0 Hub > Device
• 2. 0 Controller > 2. 0 Hub > 1. 1 Hub > Device

5 of these were easy since we had the devices in lab for them and we purchased USB 2. 0 controllers on some of our systems due to internal hub layouts. However, the one we had problems with was the USB 3. 0 hub one. Microsoft stated that the hub in question had to handle both USB 3. 0 and USB 2. 0 on the same chip and the same container ID. Problem was none of the shipping off the shelf USB 3. 0 hubs at the time of Windows 8. 0 coming out actually had this configuration, which forced us and many other companies to have to buy the one and only USB hub that actually followed the spec. This was a Texas Instruments reference device for USB 3. 0 Hubs. This device came under huge demand and it was expensive too at $150, and Microsoft for a very long time had waived the requirement due to TI being unable to meet demand. Eventually we did purchase this hub when the requirement went into full force, but there were still some unease about USB 2. 0 devices needing to be connected to a 3. 0 hub for only 1 test that only was checking to see if the device can handle USB speed changes and hub setups. For Windows 8. 1, Microsoft created an alternate method to verify the topology requirement by allowing for a USB 3. 0 device to have 2 connected, 1 to a USB 3. 0 controller and 1 to a USB 2. 0 controller at the same time. Alternatively, we could attach 1 to a USB 2. 0 hub on a USB 3. 0 controller. The requirement was fully waived for USB 2. 0 devices. This made testing a lot easier for us. For Windows 10, Microsoft decided that the theme for easing was to focus on requirements and tests where compatibility with Windows was most important. Several tests of the USB devices category were removed, including the topology test. This is because the test suite now has more reliance on the USB CV testing so testing effort is not duplicated. As for the topology test, well, it was just the complexity of the testing that caused that removal. There are several other key tests and requirements that got removed, here are some examples:

• Audio cards and OEM PCs were required to run audio quality tests using a special device which had a 5 figure price. This requirement caused smaller OEM system builders to either have to contact their motherboard company or hire a special lab that had the equipment to provide testing data that would work for their system. Microsoft has removed this requirement to reduce the cost and complexity of entry and to allow cheaper audio chips to come to market. However the test remains avaliable for those that do want to run it.
• Windows Media Center is no longer available on Windows 10, so MPEG-2 tests are now only run on graphics cards that have MPEG-2 offload.
• The amount of required tests needed for web cams on PCs was also reduced due to complexity. Web cams now only need to support a certain minimum resolution. Full testing is still available for ISV’s and OEM’s that wish to have us run them.
• The number of tests for printers and scanners has been reduced, the previous tests required a lot of paper and ink.
• Wifi Cards no longer need to be tested for support of 802. 11w, this required a special router setup in the lab and there was only 1 router that was supported for this test.
• Touch Screen Monitors and Precision Touch pads no longer require a certification blob inside their firmware, though it is still required for older Windows for PC and on Windows 10 mobile. To get this blob required both testing in our lab with special equipment that could give touches more precisely than fingers AND the device had to be sent to a special Windows lab in Taiwan for further testing afterwards. This made time to market slower and more expensive. The touch lab is optional now also for Windows 7 and 8. Wissenstest tageszinsen jahreszinsen test multiple-choice-test zinsen duden mathematik monatszinsen best-ghostwriter.com klausur wissenstest lexikon paetec nachschlagewerk stand 2010 dieser text befindet sich in redaktioneller bearbeitung. 1, but all new ISVs and new touch tech should be sent to the lab anyways.

These are just a few of the many changes that will make passing WCP tests easier. There are some new requirements though, which we will cover in a future white paper closer to Windows 10 general release. References:.

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

The updated version of the Requirements, Windows Hardware Lab Kit (HLK), along with updated playlists for testing Windows 11, version 22H2 hardware can be downloaded from below links. Compared to previous releases of the HLK, this version is intended for exclusive testing for Windows 11, version 22H2. Previous version of the HLK remain available at HLK Kits. Compare

**Please note that Partner Center(Hardware Dev Center) will only start accepting submissions from 5/31/2022 onwards. Partners can download requirements and start hardware validation with updated kit now, but submissions can only be done starting 5/31/2022.

Windows 11, version 22H2 WHCP Requirements

WHCP requirements for Windows 11, version 22H2 can be found here —  WHCP Specifications and Policies

Windows 11, version 22H2 certification build

Minimum acceptable build for Windows 11, version 22H2 certification is RTM build(i.e. 22621).

Windows 11, version 22H2 WHCP Playlists & Hardware Lab Kit

Windows Hardware Lab Kit can be found here — Windows Hardware Lab Kit

The table below illustrates the playlists needed for testing each architecture: Link —   HLKPlaylist

*Testing for ARM64 requires validation in a separate mode for each playlist. Please refer to the HLK ARM64 Getting Started Guide for details on ARM64 HLK client setup and playlist use.

Windows 11, version 22H2 – Submissions on Hardware Dev Center

Partner Center will start accepting submissions for Windows 11, version 22H2 starting 5/31/2022. When making WHCP submissions for the Windows 11, version 22H2 certification, use the following target in Partner Center:

Windows 11, version 22H2 based systems may ship with drivers that have achieved compatibility with Windows 11, version 21H2 until Sept 5^th, 2022.
Partners looking to achieve compatibility for systems shipping with Windows 11, version 22H2 Release may use drivers for components that achieved compatibility with Windows 11, Version 21H2 until Sept 5^th, 2021

Errata 103871 is available to filter the “System Logo Check” failure seen when testing Windows 11, version 22H2 based systems with Windows 11, Version 21H2 qualified drivers. To apply, download the latest errata filter package.