Windows driver kit windows 10 version 1903

Install the latest hardware development tools to build, test and deploy drivers; test and measure your hardware running Windows; and customize, assess, and deploy Windows 10 on your hardware.

WDK:
https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit  
WinDbg:
https://developer.microsoft.com/en-us/windows/hardware/download-windbg 
HLK:
https://developer.microsoft.com/en-us/windows/hardware/windows-hardware-lab-kit

ADK:
https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

Changes and known issues for the WDK

WDK supports Visual Studio 2019

The Windows Driver Kit (WDK) for Windows 10, version 1903, has been updated to support Visual Studio 2019 as previously

announced. This release of the WDK is not compatible with Visual Studio 2017 however, developers can continue working with Visual Studio 2017 using the previous releases of the WDK

here. To learn about what is new with Visual Studio 2019 please review the information

here.

Driver Menu and Driver Template location changedPlease visit the page

‘What’s new in driver development for WDK’ to see the new location of the WDK menus in Visual Studio 2019. 

EWDK and SDV running on Server have .NET requirements

Running the EWDK and Static Driver Verifier tool on Windows Server 2018 requires
.Net Framework 4.7.2 to be installed on the machine

Driver Verifier does not get enabled/disabled when using WDK test explorer
Driver Verifier does not get enabled/disabled when Device Fundamental tests are run using the WDK Test Explorer.

Workaround:
On the client machine manually enable/disable driver verifier per these
instructions. 

WDK Side by Side installations of Windows 10, version 1903 and Windows 10, version 1803
With both versions of kits installed on the same PC the ‘Deploy driver’ feature won’t work for older version.

Work around:
Use 1803 on a separate machine if Deploy driver  feature is needed.

Windows Device Testing Framework (WDTF) tests now only run on systems with matching Windows 10 versions as the WDK
In WDK for Windows 10, version 1809, changes were made to WDTF in order to support this version of Windows 10, version 1809. The effect of this is that WDTF will no longer run on down-level OS. The change continues with WDK for Windows 10, version 1903.

 
Alterative for down-level testing:
The WDTF tests in WDK for Windows 10, version 1803 can be run on previous Windows versions

APIValidator
On an x86 arch machine APIValidator is unable to run against x64 binaries. If building x64 drivers on an x86 machine APIValidator should be turned off.

 
Workaround:
1. Go to the properties page of the driver solution
2. Select APIValidator, then General and change Run ApiValidator from Yes to No

WDK running on Windows 7 systems requires KB 3033929
WDK will require installing Microsoft Security Advisory 3033929
(KB3033929) prior to installing the WDK on systems running Windows 7.  KB3033929 can be downloaded
here

WDK Enables Spectre mitigation by default

When the WDK is installed, Spectre mitigation is enabled by default for all drivers, this by design. If the Spectre mitigation libraries are not installed, then at build time this message
will be seen:

Error seen when Provisioning a computer for driver deployment and testing when using WDK 1903 and Visual Studio 16.1 +

The Visual Studio team addressed a reported issue that resulted in the MSVC debug tool location changing. WDK has a dependency on this folder structure and with the Visual Studio fix the folder structure that WDK is looking for is no longer
present. When provisioning a computer for driver deployment and testing on a system which has WDK and Visual Studio 16.1 +, provisioning fails. When reviewing the logs, the following error message is present:
An error occurred while deploying files to the target machine for test «Driver Removal»: Could not find a part of the path
‘C:VSVCRedistMSVC14.21.27702debug_nonredistX64Microsoft.VC141.DebugCRT’..​

Workaround:

As Administrator, run Developer Command Prompt for VS 2019
Run the following commands in the VS Developer Command Prompt:

1. cd /d %VCToolsRedistDir%debug_nonredist
2. MKLINK /J x86Microsoft.VC141.DebugCRT x86Microsoft.VC142.DebugCRT
3. MKLINK /J x64Microsoft.VC141.DebugCRT x64Microsoft.VC142.DebugCRT

Installing the WDK generates an error from Visual Studio that the add-in componet is already installed

This error message can be seen if the WDK was uninstalled but the WDK drivers extension for Visual Studio was not uninstalled.

Resolution:

In Visual Studio go to the Extension dropdown menu, choose Manage Extensions, select the Windows Driver Kit and click on the Uninstall button. 

Системные программисты, в частности под ОС Windows практически лишены того объема информации, который доступен разработчикам высокоуровневых программ. Можно выделить три основных источника, позволяющих заполнить пробелы при разработке драйверов для Windows:

1. Печатные издания.

2. Официальная документация DDK от Microsoft.

3. Open-source проекты.

Сложно поспорить с тем, что порог вхождения в область разработки драйверов достаточно высокий, однако желание погрузиться в это направление пропадает еще на этапе написания HelloWorld. Начинающему программисту сложно найти ответы на казалось бы банальные вопросы:

1. Как запустить драйвер?

2. Как понять, что драйвер работает?

3. Как отлаживать драйвер?

В этой статье я постараюсь максимально подробно описать несколько (вообще их гораздо больше) способов установки и отладки драйвера, удобные по моему субъективному мнению, на примере реализации простого драйвера, выполняющего единственное действие — вывод при запуске отладочного сообщения «Hello from Windows kernel mode!!».

Предварительные условия

Разрабатывать драйвер я буду в Microsoft Visual Studio 2019 (на момент публикации Microsoft предлагает WDK для Visual Studio 2022, совместимый только с Windows 11, переходить на которую пока не планирую). Для разработки драйвера необходимо скачать установить пакет DDK с официального сайта Microsoft.

Microsoft предлагает несколько версий (соответствуют сборкам самой операционной системы), однако пакеты WDK для Windows 10 имеют обратную совместимость, то есть самая свежая версия WDK позволяет реализовать драйвер для младших сборок Windows. Однако, как обычно, есть один нюанс, касающийся настройки тестовой системы (об этом будет написано ниже), поэтому также стоит скачать пакет WDK для вашей тестовой системы. Посмотреть номер сборки можно утилитой winver, (Win+R -> winver -> Enter).

В моем случае самая свежая версия WDK — это WDK для Windows 10 версии 1903 (статья написана сильно раньше как пособие для студентов, на момент публикации доступна версия 2004) на виртуальную машину будет установлена Windows 10 build 1709, поэтому я также скачиваю (но не устанавливаю) WDK для Windows 10 версии 1709.

Для запуска и отладки драйвера будет использована виртуальная машина с ОС Windows 10 x64 на VMWare Workstation.

Для просмотра отладочных сообщений от драйвера используется утилита DbgView из пакета Sysinternals.

Создание проекта

Сначала предлагается реализовать сам драйвер. Так как по плану он должен обладать минимальным функционалом, то этот процесс займет небольшое количество времени.

Шаг 1. Запустить Microsoft Visual Studio.

Шаг 2. Приступить к созданию нового проекта KMDF Driver.

Шаг 3. Назначить имя проекта и его расположение.

Шаг 4. Добавить файл исходного кода драйвера.

Шаг 5. Написать исходный код драйвера.

// Основной файл WDK
#include <ntddk.h>

// Объявление функции выгрузки драйвера
VOID DriverUnload(PDRIVER_OBJECT driverObject);

// Точка входа в драйвер (аналог функции main)
NTSTATUS DriverEntry(IN PDRIVER_OBJECT driverObject, IN PUNICODE_STRING registryPath)
{
  // Отметка параметра неиспользуемым
  UNREFERENCED_PARAMETER(registryPath);

  // Печать отладочного сообщения
  DbgPrint("Hello from Windows kernel mode!!");

  // Регистрация функции выгрузки драйвера
  driverObject->DriverUnload = DriverUnload;

  return STATUS_SUCCESS;
}

// Функция выгрузки драйвера
VOID DriverUnload(IN PDRIVER_OBJECT driverObject)
{
  // Отметка параметра неиспользуемым
  UNREFERENCED_PARAMETER(driverObject);
  // Вывод отладочного сообщения
  DbgPrint("Goodbye!");
}

Шаг 6. Собрать драйвер.

Драйвер написан, собран и готов к установке на целевую систему.

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

Можно предложить два основных способа установки драйвера: с помощью мастера установки и вручную, с использованием утилиты SC (вообще говоря можно даже реализовать программу, которая используя функции OpenSCManager, CreateService, OpenService и другие из Windows API позволит управлять драйверами и службами). Однако мастер установки предполагает установку драйверов для устройств, а написанный драйвер таковым не являтеся, поэтому установка будет произведена с помощью утилиты SC.

Перед установкой драйвера (точнее перед первым запуском) необходимо включить тестовый режим, позволяющий устанавливать неподписанные драйверы. Сделать это можно выполнив в командной строке от имени администратора bcdedit /set testsigning ON, после чего необходимо перезагрузить систему. Хотя при сборке проекта был создан самоподписанный сертификат, ОС Windows 10 не позволит запустить драйвер, подписанный таким сертификатом (как было сказано выше, в новых версиях ОС драйвер должны иметь подпись от Microsoft).

Далее необходимо выполнить следующие действия:

Шаг 1. Скопировать файл HelloWorldDriver.sys на целевую систему.

Шаг 2. Открыть командную строку от имени администратора.

Шаг 3. Выполнить команду установки драйвера.

Драйвер установлен, но не запущен. Информацию о текущем состоянии драйвера можно получить командой SC QUERY <название_драйвера>

Перед первым запуском предлагается запустить утилиту DbgView и убедиться, что драйвер действительно выводит отладочное сообщение. Утилиту необходимо запустить от имени администратора, а после запуска включить захват сообщения из ядра нажатием Capture->Capture Kernel и включить подробный режим вывода нажатием Capture->Enable Verbose Kernel Output. WDK предлагает расширенную версию функции отладочной печати — DbgPrintEx, которая позволяет задать уровень важности сообщения, это позволяет фильтровать сообщения с уровнем важности меньше заданной.

Запустить драйвер можно командой SC START <название_драйвера>, в окне DbgView должно появиться заданное в исходном коде сообщение.

Может случиться, что после запуска драйвера сообщение в DbgView не появится. В таком случае нужно попробовать перезагрузить систему. Скорее всего, настройки DbgView, касающиеся включения подробного режима, применяются не сразу.

Остановить драйвер можно командой SC STOP <название_драйвера>, а в DbgView снова появится отладочная строка.

Остановить драйвер позволила зарегистрированная «ненужная» функция DriverUnload. В качестве эксперимента можете удалить ее из исходного кода и попробовать повторить действия по запуску и остановке драйвера. Он запустится, но остановить его не получится.

Отладка драйвера

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

Отладка программы может осуществляться различными способами. Например, часть моих студентов в курсе, посвященному языку PHP, отлаживают программы путем вставки в определенные участки кода конструкций типа echo ("I'm here42") или print("Var1 = $var1"). Почему так? Ответ на этот вопрос во многом подтолкнул меня к созданию этой статьи. Всё дело в том, что для PHP подключение привычного отладчика (а студенты сначала изучали язык C++ в IDE, где вполне успешно использовали «коробочные» возможности установки точек остановки, пошагового исполнения, окон watch и memory) подразумевает выполнение некоторого обряда: загрузка дополнительной библиотеки для php (xdebug, например), редактирование php.ini, установка расширения в браузере. И это при том, что в сети достаточно источников, описывающих этот процесс. Материалов по отладке драйверов гораздо меньше.

Я выделяю два основных способа отладки драйвера для ОС Windows: нормальный, с помощью утилиты WinDbg, и удобный — средствами Visual Studio.

Подготовка виртуальной машины

Пошаговая отладка драйвера подразумевает остановку его выполнения. Однако в архитектуре на уровне ядра ОС Windows, грубо говоря, деление на различные драйверы достаточно условно, можно представить все ядро как одну программу, где различные компоненты (драйверы) — это библиотеки. Остановка в исполнении любого драйвера подразумевает остановку всей системы. Поэтому отладка должна производиться на удаленном компьютере (хотя методом вставки строк кода с конструкцией DbgPrint(«…») можно отлаживать и локально). Удобно заменить удаленный компьютер виртуальной машиной, как это и делается в подавляющем большинстве случаев.

Так как драйвер исполняется на удаленном компьютере, то связь с отладчиком осуществляется по физическому интерфейсу: COM, Ethernet, USB, FireWire. Наибольшую популярность получила отладка по COM-интерфейсу. Признаюсь, вообще не видел примеров с иными.

На виртуальную машину необходимо добавить последовательный интерфейс, выполнив следующую последовательность действий:

Шаг 1. Открыть настройки виртуальной машины.

Шаг 2. Добавить последовательный интерфейс.

Шаг 3. Настроить последовательный порт

Отладка с использованием WinDbg

Необходимо перевести тестовую систему в отладочный режим. Для этого нужно запустить ее и от имени администратора исполнить команду bcdedit /debug on, а также настроить тип отладки. В примере используется отладка по COM-порту, поэтому в командной строке необходимо выполнить команду bcdedit /dbgsettings serial debugport:2 (значение параметра debugport должно совпадать с номером последовательного порта в настроках виртуальной машины. Скорее всего это будет Serial Port 2). После перезагрузки системы активируется отладочный режим.

После активации режима отладки система может «зависать» при включении и выключении. Я так и не смог разобраться, в каких случаях это проиcходит, а в каких нет. Если при включении или выключении системы она «зависла», то достаточно просто запустить отладчик (об этом ниже) и загрузка продолжится.

WinDbg внешне выглядит не очень современно. Особенно это заметно на фоне привычной разработчикам программ для Windows среды Visual Studio. На момент написания статьи вышла в свет новая версия утилиты отладки — WinDbg Preview, однако она доступна только в Microsoft Store, а у меня Disable Windows Spying отключил возможность установки приложений из магазина. Хотя скриншоты на портале Microsoft выглядят многообещающе.

Теперь необходимо настроить WinDbg. Наиболее подробное описание WinDbg представлено на сайте Microsoft, мы же рассмотрим лишь основы. К основным настройкам WinDbg можно отнести следующие:

1. Тип подключения к отлаживаемой системе, её адрес.

2. Расположение исходных кодов отлаживаемых драйверов.

3. Расположение символьной информации.

WinDbg позволяет задать все эти опции в виде аргументов командной строки, поэтому удобно (я делаю так) создать необходимое количество ярлыков исполняемого файла (сам исполняемый файл WinDbg имеет путь Program Files (x86)Windows Kits10Debuggersx64windbg.exe), в свойствах ярлыка задать необходимые параметры:

1. -k. Обозначает режим отладки ядра.

2. com:port=.pipeWin10,pipe. Обозначает порт отладки (именование канала должно совпадать с тем, которое было указано в настройках виртуальной машины).

3. -y srv*C:ProgramDataMicrosoftSymbols*http://msdl.microsoft.com/download/symbols. Определяет расположение символьной информации. Если отладочные символы не найдены в локальном хранилище, то они будут загружены из указанного репозитория.

4. -srcpath C:dev. Определяет расположение файлов исходного кода (можно указывать не директорию конкретного проекта, а директории выше в иерархии).

5. -WF Dark.WEW. Определяет файл с сохраненным рабочим пространством (WorkSpace). В рабочее пространство входит набор и расположение окно, шрифты, цвета шрифтов и фона. Мне показалось очень удобным однажды настроить WinDbg, а далее использовать эти настройки. За основу своего WorkSpace я взял найденную давно темную тему, далее удобно расположил окна, перенастроил некоторые шрифты.

Мне показались удобными такие расцветка и расположение окон:

Теперь давайте отладим драйвер. Для того, чтобы выполнение остановилось, необходимо добавить инструкцию int 3, в исходном коде драйвера это можно сделать, вставив макрос DbgBreakPoint();. Предлагается установить точку останова в первой строке функции DriverEntry и попытаться запустить драйвер. Нет большой разницы, когда запускать WinDbg. В определенные моменты выполнение инструкций прекращается, визуально система «зависает» в ожидании подключения отладчика. То есть можно сначала запустить драйвер, а только потом WinDbg, а можно и наоборот.

Я запустил WinDbg, после чего запустил драйвер. Отладчик подключился к тестовой системе, WinDbg автоматически загрузил исходный код драйвера.

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

Отладка средствами Visual Studio

В новых версиях Visual Studio (начиная с 2013) также появилась возможность отладки драйверов. Кроме непосредственно отладчика Visual Studio предлагает широкие возможности по установке драйвера на удаленную систему, что позволяет производить отладку драйвера практически идентично отладке обычной программы (Сборка->расстановка точек останова->запуск отладки).

Для использования функций Visual Studio также необходимо обеспечить отладочное соединение с тестовой системой, в нашем случае это COM-порт, остальные действия не требуются (включать тестовый и отладочный режимы не нужно). Visual Studio позволяет автоматически настроить удаленную систему. Для этого на тестовую систему нужно установить пакет WDK Test Target Setup, который находится в директории %Program Files (x86)%Windows Kits10Remote%Платформа%. Этот .msi файл нужно скопировать на тестовую систему и установить.

Теперь пошагово сконфигурируем тестовую систему.

Шаг 1. Запустить Visual Studio.

Шаг 2. Открыть конфигуратор тестовых устройств.

Шаг 3. Добавить и сконфигурировать тестовое устройство.

Настройка тестовой системы почти закончена. На нее установлены средства TAEF — Test Authoring and Execution Framework и WDTF — Windows Driver Test Framework, позволяющие Visual Studio автоматически удалять старую версию драйвера, устанавливать новую, а также проводить автоматическое тестирование (вопрос автоматических тестов выходит за рамки данного материала).

ВНИМАНИЕ!!! В самом начале статьи я рекомендовал выяснить версию Windows на тестовой машине. Если она совпадает с версией установленного пакета WDK, то данный абзац можно не читать. WDK имеет обратную совместимость, то есть установленная WDK 1903 позволяет разрабатывать драйверы для предыдущих сборок (можно найти этот параметр в свойствах проекта, хотя я не сталкивался с ситуацией, когда драйвер не работает на некоторой сборке), однако пакет WDK — это не только набор заголовочных файлов, расширение для Visual Studio, но еще и набор вспомогательных утилит для отладки (тот же WinDbg) и тестирования. В том числе в пакет WDK входит и названный выше WDTF. И он обратной совместимости не имеет (или, возможно, не имеет для некоторых сборок). Для проверки наличия WDTF необходимо проверить на тестовой системе содержимое директории C:Program Files (x86)Windows Kits10TestingRuntimes. Если там содержатся поддиректории TAEF и WDTF, то все в порядке, а если только TAEF, как в моем случае, то нужно отдельно установить WDTF из пакета WDK версии, совпадающей с версией тестовой системы (напомню, у меня это Windows 10 1709). На тестовую систему из директории WDKInstallers необходимо скопировать файл Windows Driver Testing Framework (WDTF) Runtime Libraries соответствующей разрядности и попытаться установить его командой msiexec /i «Windows Driver Testing Framework ….». Установщик выдаст ошибку отсутсвия .cab файла. Найдите соответствующий файл в той же директории Installers, скопируйте на тестовую машину и повторите установку. Рядом с директорией TAEF должна появиться WDTF.

Тестовая система готова к загрузке и отладке драйвера. Visual Studio предлагает различные варианты установки (Deploy) драйвера на тестовую систему, настройки доступны в свойствах проекта во вкладке Driver Install->Deployment. В первую очередь нужно выбрать тестовую машину из выпадающего списка. Выше она уже была сконфигурирована и теперь доступна.

Подробно с различными вариантами можно ознакомиться на портале Microsoft. Мне показались наиболее понятными два из них: Install/Reinstall and Verify и Custom Command Line. Стоит отметить, что не совсем корректно работают точки остановки. Даже при их установке выполнение не прерывается. Нужно вставить как минимум одну конструкцию DbgBreakPoint(); (я это делаю первой же строкой функции DriverEntry), дальше отладку можно производить привычным для пользователя Visual Studio образом, пошаговая отладка нормально работает, установленные точки остановки тоже.

При опции Install/Reinstall and Verify драйвер будет установлен (переустановлен) и запущен, однако система будет перезагружена (это долго), а драйвер будет установлен с опцией старта при запуске системы. Для большинства случаев это не должно быть проблемой, однако если для вас важен момент запуска драйвера, то этот способ не подходит. Я устанавливаю конструкцию прерывания в первой строке DriverEntry, а также устанавливаю точку остановки на строке с выводом отладочного сообщения и возвратом из функции и нажимаю привычное F5.

На виртуальной машине можно увидеть исполнение скриптов. Также могут появляться сообщения об ошибках, однако даже с некоторыми ошибками все работает. В моем случае по неизвестным мне причинам установка драйвера не всегда удается с первого раза (в Visual Studio вы увидите сообщение о том, что программа завершила работу с ненулевым кодом). Но со второй-третьей попытки все начинает работать. После исполнения скриптом система перезагрузится, драйвер начнет загружаться, исполнение остановится на конструкции DbgBreakPoint();. Отладчик Visual Studio должен подключиться к виртуальной машине, отобразить в окне с исходным кодом текущую строку и нормальным образом реагировать на пошаговое исполнение, показывать значения переменных, отображать содержимое памяти, и, что важно, останавливаться на установленных средствами Visual Studio точках остановки.

Окно Debugger Immediate Window точно такое же, как и в WinDbg. Точнее говоря, это одно и то же. Поэтому Visual Studio через него поддерживает все команды WinDbg, а среди них много полезных.

Еще один способ установки драйвера, который я использую — это Custom Command Line. Можно создать простой bat-скрипт, содержащий команды по установке и запуску драйвера. Visual Stuio позволяет указать дополнительные файлы, которые нужно скопировать на тестовую систему, однако эта функция не работает. Поэтому создаем файл createandstart.bat на диске C, который содержит две строки: SC CREATE HelloWorldDriver binPath= C:DriverTestDriversHelloWorldDriver.sys type=kernel и SC START HelloWorldDriver

А в поле ввода под опцией Custom Command Line указать C:createandstart.bat

При нажатии F5 драйвер установится, запустится и Visual Studio укажет на строку с вызовом макроса DbgBreakPoint();

Простая отладка средствами Visual Studio

Однако все возможности Visual Studio Deployment раскрываются при создании тестов. Для простой отладки все это лишнее, поэтому, возможно, будет гораздо проще настроить тестовую систему для отладки самостоятельно (утилитой bcdedit), далее вручную запускать драйвер, а отлаживать его средствами Visual Studio. Такой подход представляет собой что-то среднее между рассмотренными выше. Для подготовки к отладке необходимо выполнить следующие шаги:

Шаг 1. Подготовить виртуальную машину.

На виртуальной машине нужно включить тестовый и отладочный режимы, а также установть драйвер командой SC CREATE.

Шаг 2. Сконфигурировать Visual Studio.

Теперь на тестовой системе можно запустить драйвер командой SC START. Выполнение драйвера остановится на строке DbgBreakPoint();, а виртуальная машина будет ожидать подключения отладчика. В Visual Studio нужно нажать Debug->Attach To Process, в появившемся окне в поле Connection type выбрать Windows Kernel Mode Debugger, в поле Connection target — имя настроенной выше тестовой машины, нажать Attach.

Очень вероятно, что вы получите ошибку Frame is not in module:

Введите в поле ввода окна Debugger Immediate Window команду .reload и переключитесь на файл с исходным кодом. Если и это не помогло, скорее всего, вы что-то изменили в исходном коде, скомпилировали, но забыли скопировать новую версию драйвера. Пересоберите (для надежности) проект, скопируйте его на тестовую машину, запустите драйвер, подключие отладчик снова.

Я считаю этот способ самым удобным при отладке драйвера. Он позволяет использовать более комфортную и привычную Visual Studio, при этом не тратить целые минуты на установку новой версии драйвера на тестовую систему.

Заключение

Разработка драйверов для ОС Windows — достаточно увлекательный процесс. Реализация даже мелких и простых драйверов позволяет глубже понять внутреннее устройство Windows, что весьма полезно. Однако начинающих системных программистов отпугивает не столько сложность написания непосредственно кода (как минимум, есть множество примеров), сколько сложность установки и отладки. Надеюсь, что данный материал поможет кому-то не потерять интерес в первом же проекте.

Upd

В комментариях были выражены опасения, что инструкция по установке драйвера некорректная в части отключения подписи драйверов. В результате эксперимента установлено, что все нормально и работает ровно так, как описано. Также попутно выяснилось, что можно смело качать последнюю версию WDK (для 22H2) и SDK (если у вас Windows 10, а не Windows 11) и тогда разработку можно вести в Visual Studio 2022.

скачать

Загрузите WDK для Windows 10 версии 1903
Скачать Visual Studio Enterprise 2019

Ссылка на общий доступ к сетевому диску: (включая Visual Studio Enterprise 2019+, загрузите WDK для Windows 10, версия 1903 + SDK18362)
ссылка:https://pan.baidu.com/s/1UrdOnHz2l5cWO43ngzLP_A
Код извлечения: jaa1

Ссылка на официальный сайт:https://docs.microsoft.com/zh-cn/windows-hardware/drivers/download-the-wdk (Эта страница может быть изменена, когда станет доступна последняя версия)

установка

1. Проверьте версию системы.

win+r->winver

2. Установите vs_enterprise__770120330.1555400473.exe

При установке выберите использование разработки для настольных ПК на C ++, чтобы пакет разработки программного обеспечения (SDK) Windows 10 был включен автоматически, что можно увидеть на сводном экране справа.

Время установки немного велико, поэтому наберитесь терпения.

Перезагрузите.

3. Установите SDK, Windows_InsiderPreview_SDK_en-us_18362_1.iso.

В предыдущей версии VS, выбранной для разработки настольных компьютеров C ++, был установлен SDK, но на четвертом шаге он сообщает, что не существует соответствующей версии SDK (версия 18362). Итак, установил это снова.

4. Установите WDK.

Автономная установка:. Windows Kits 10 WDK wdksetup.exe
Загрузите и установите в Интернете:. wdksetup.exe

Установите цифровую подпись, на картинке ниже изображена сеть. Забыл сделать снимок экрана на этом этапе.

Если подключаемый модуль, установленный wdk, успешно работает. Откройте Vs для создания проекта, есть вариант драйвера.

Если в процессе компиляции драйвера появляется следующая ошибка, код драйвера hello world здесь не публикуется.

Компиляция выполнена.

Справка:https://blog.csdn.net/newnewman80/article/details/90754999

Software installed / Build worker image
Visual Studio 2013
Visual Studio 2015
Visual Studio 2017
Visual Studio 2019
Visual Studio 2022

Operating system

Windows Server 2012 R2

Windows Server 2016

Windows Server 2019

PowerShell

Windows PowerShell 5.1

PowerShell Core

6.2.3
6.2.3
7.2.7
7.2.7

Docker

• Docker CE 18.05.0-ce for Windows and Linux with base images:
  • mcr.microsoft.com/windows/servercore:ltsc2016
  • mcr.microsoft.com/windows/nanoserver:sac2016

• Docker Desktop 2.2.0.5 in experimental mode (LCOW support) with base images:
  • mcr.microsoft.com/windows/servercore:ltsc2019
    sha256:2ecf1e2987b91b41f576afd7f56aa40c9ddbc691d7b6b066c64d8f27fb3070ca
  • mcr.microsoft.com/windows/servercore:1803
    sha256:3c409b7874dd466dee08e6abc6a68eb6a9586054739249cc4e460aa68140e121
  • mcr.microsoft.com/windows/servercore:ltsc2016
    sha256:f4c4f31c7ee654e73bd130b89e6ad5a659f5ede52fd9eb653c9db4aa12f6e0ea
  • mcr.microsoft.com/windows/nanoserver:1809
    sha256:28805a307e17836a84a6af231f8516110839e4840e4ab41c7d286a0ca5627ea1
  • mcr.microsoft.com/windows/nanoserver:1803
    sha256:f10f91cc7f5624a1b2434c8a625a1d376a784a0bb941ecf06e6b745ec9f337d4
  • mcr.microsoft.com/windows/nanoserver:sac2016
    sha256:2b783310e6c82de737e893abd53ae238ca56b5a96e2861558fb9a111d6691ddb
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8
    sha256:5f49640a2ef69037dae10075943838c528b4ddf5191bef79a62a8446e754d632

docker-compose 1.16.1

docker-compose 1.24.1

Windows Subsystem for Linux (WSL)

• Windows Subsystem for Linux Distributions:
  • Ubuntu-20.04 (Default)
  • Ubuntu-18.04
  • Ubuntu-16.04
  • openSUSE-42

Version control systems

Git (with git config --global core.autocrlf input)
2.26.2
2.26.2
2.26.2
2.38.1
2.38.1

Git Large File Storage (Git LFS)
2.9.2
2.9.2
2.9.2
3.2.0
3.0.2

Mercurial
4.1.1
4.1.1
4.1.1
6.1.4
6.0

Subversion 1.8.17 (x86)

Visual Studio 2008

Visual C++ 2008 Express

Visual Studio 2010

Visual C# 2010 Express

Visual Basic 2010 Express

Visual C++ 2010 Express

Visual Web Developer 2010 Express

Visual Studio 2010 Service Pack 1

Visual Studio 2012

Visual Studio Express 2012 for Windows Desktop

Visual Studio 2012 Update 5

SQL Server Data tools for Visual Studio 2012

Visual Studio 2013

Visual Studio Community 2013 with Update 5

Visual Studio 2013 SDK

Python Tools for Visual Studio 2013

Node.js Tools for Visual Studio 2013

WDK 8

Visual F# 3.1.2

Microsoft Visual Studio Installer Projects Extension (`.vdproj` support)

SQL Server Data tools for Visual Studio 2013

Microsoft SQL Server Data Tools — Business Intelligence for Visual Studio 2013

Office Developer Tools for Visual Studio 2013

Code Contracts for .NET 1.9.10714.2

Visual Studio 2015

Visual Studio Community 2015 with Update 3

Universal Windows App Dev Tools for Visual Studio 2015

Python Tools for Visual Studio 2015

Node.js Tools 1.2 for Visual Studio 2015

Visual F# Tools 4.0 RTM

WDK 10.0.14393

WDK for Windows 10, version 1803 (10.0.17134.1)

WDK for Windows 10, version 1903 (10.0.18362.1)

SQL Server Data Tools (SSDT) 17.0 (14.0.61704.140) for Visual Studio 2015

Data-Tier Application Framework (17.1 DacFx)

Azure Service Fabric SDK 3.2 (Runtime 6.3)

Azure Service Fabric 7.0 Fourth Refresh

Microsoft .NET Portable Library Reference Assemblies 4.6

Microsoft Visual Studio Installer Projects Extension (.vdproj support)

SQL Server Data tools for Visual Studio 2015

Office Developer Tools for Visual Studio 2015

Code Contracts for .NET 1.9.10714.2

Visual Studio 2017

Visual Studio Community 2017 version 15.9.19

WDK for Windows 10, version 1709

SQL Server Data Tools (SSDT) 15.5.2 for Visual Studio 2017

Visual Studio 2019

Visual Studio Community 2019 version 16.11.20 (installed components)

Visual Studio Community 2019 Preview version 16.11 Preview 2 on Visual Studio 2019 Preview image

SDK/WDK for Windows 10, version 1709 (build 16299)

SDK/WDK for Windows 10, version 1803 (build 17134)

SDK/WDK for Windows 10, version 1809 (build 17763)

SDK/WDK for Windows 10, version 1903 (build 18362)

Visual Studio 2022

Visual Studio Community 2022 version 17.4.0 (installed components)

Windows SDKs

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1

Microsoft Windows SDK for Windows 7 and .NET Framework 4

Windows SDK for Windows 8

Windows SDK for Windows 8.1

Windows Driver Kit Version 7.1.0 (to support ATL)

Windows Driver Kit 10

Windows Driver Kit 1809

Windows 10 SDK 10.0.10586

Windows 10 SDK 10.0.14393

Windows 10 SDK 10.0.26624

Windows 10 SDK/WDK, version 1809 (build 10.0.17763)

Windows 10 SDK/WDK, version 1903 (build 10.0.18362)

Windows 10 SDK/WDK, version 2004 (build 10.0.19041)

Windows 11 SDK/WDK (build 10.0.22000.1)

Windows 11 SDK (build 10.0.22621.0)

Microsoft Expression Blend Software Development Kit (SDK) for .NET 4

Microsoft Expression Blend Software Development Kit (SDK) for Silverlight 4

Windows Phone SDK 8.0

Windows PowerShell 2.0 SDK

DirectX SDK (C:Program Files (x86)Microsoft DirectX SDK)

Misc SDKs

Flutter SDK 3.3.6

AWS SDK for .NET with AWS Tools for Windows 3.3.69

AWS CLI 1.11.68

AWS CLI 1.17.4

WiX Toolset 3.11.0.1701

WiX Toolset 3.11.1

TypeScript

TypeScript 1.4 for Visual Studio 2013

TypeScript 1.5 for Visual Studio 2013

TypeScript 1.6 for Visual Studio 2013

TypeScript 1.7 for Visual Studio 2013

TypeScript 1.8 for Visual Studio 2013

TypeScript 2.4.1 for Visual Studio 2015

TypeScript 2.1.5 for Visual Studio 2017

TypeScript 2.5.2 for Visual Studio 2015/2017

TypeScript 2.6 for Visual Studio 2015/2017

TypeScript 2.7.2 for Visual Studio 2015/2017

TypeScript 2.8.3 for Visual Studio 2015/2017

TypeScript 3.0.1 for Visual Studio 2015/2017

TypeScript 3.1 for Visual Studio 2017

Azure

Azure SDK 2.3

Azure SDK 2.4

Azure SDK 2.5.1

Azure SDK 2.6

Azure SDK 2.7.1

Azure SDK 2.8.1

Azure SDK 2.9.5

Azure SDK 2.9.6

Azure SDK 3.0

Microsoft Azure Storage Emulator 5.5

Microsoft Azure Storage Emulator 5.9

Microsoft Azure Storage Emulator 5.10

Microsoft Azure PowerShell 5.7

Microsoft Azure CLI 2.0

DocumentDB Emulator 1.13.58.2

Azure Cosmos DB Emulator 2.7.0

Xamarin

Xamarin 4.9

Xamarin 4.11

Android SDK 4.4 (KitKat) API level 19

Android SDK 5.0 (Lollipop) API level 21

Android SDK 5.1 (Lollipop) API level 22

Android SDK 6.0 (Marshmallow) API level 23

Android SDK 7.0 (Nougat) API level 24

Android SDK 7.1 (Nougat) API level 25

Android SDK 8.0.0 (Oreo) API level 26

Android SDK 8.1.0 (Oreo) API level 27

Android SDK 9.0 (Pie) API level 28

Android SDK 10.0 (Android 10) API level 29

Android NDK r10e (C:ProgramDataMicrosoftAndroidNDK64android-ndk-r10e)

Android NDK r11c (C:ProgramDataMicrosoftAndroidNDK64android-ndk-r11c)

Android NDK r16b (C:MicrosoftAndroidNDK64android-ndk-r16b)

Android NDK r17 (C:ProgramDataMicrosoftAndroidNDK64android-ndk-r17)

.NET Framework

.NET Framework 2.0, 3.0, 3.5, 4.0, 4.5.1, 4.5.2

.NET Framework 4.6.0, 4.6.1, 4.6.2

.NET Framework 4.7.0

.NET Framework 4.7.1

.NET Framework 4.7.2

.NET Framework 4.8

.NET Core SDK 1.0.0-preview2-003121

.NET Core SDK 1.0.0-preview2-003131

.NET Core SDK 1.0.0-preview2-003156

.NET Core SDK 1.0.0-preview2-1-003177

.NET Core SDK 1.0.0

.NET Core SDK 1.0.1

.NET Core SDK 1.0.2

.NET Core SDK 1.0.3

.NET Core SDK 1.0.4

.NET Core SDK 1.1.14

.NET Core SDK 2.0.0

.NET Core SDK 2.0.2

.NET Core SDK 2.0.3

.NET Core SDK 2.1.14

.NET Core SDK 2.1.4

.NET Core SDK 2.1.101

.NET Core SDK 2.1.103

.NET Core SDK 2.1.104

.NET Core SDK 2.1.105

.NET Core SDK 2.1.200

.NET Core SDK 2.1.201

.NET Core SDK 2.1.202

.NET Core SDK 2.1.300

.NET Core SDK 2.1.301

.NET Core SDK 2.1.302

.NET Core SDK 2.1.400

.NET Core SDK 2.1.401

.NET Core SDK 2.1.402

.NET Core SDK 2.1.403

.NET Core SDK 2.1.500

.NET Core SDK 2.1.503

.NET Core SDK 2.1.507

.NET Core SDK 2.1.603

.NET Core SDK 2.1.604

.NET Core SDK 2.1.701

.NET Core SDK 2.1.803

.NET Core SDK 2.1.806

.NET Core SDK 2.2.100

.NET Core SDK 2.2.103

.NET Core SDK 2.2.107

.NET Core SDK 2.2.108

.NET Core SDK 2.2.109

.NET Core SDK 2.2.203

.NET Core SDK 2.2.204

.NET Core SDK 2.2.206

.NET Core SDK 2.2.301

.NET Core SDK 2.2.402

.NET Core SDK 3.0.103

.NET Core SDK 3.1.202

.NET Core SDK 3.1.422

.NET 5 SDK 5.0.408

.NET 5 SDK 5.0.413

.NET 6 SDK 6.0.403

.NET 7 SDK 7.0.100

Silverlight

Silverlight 5 x64 Developer Runtime

Microsoft SilverLight 5 SDK

Microsoft SilverLight 4 SDK

Boost

Boost 1.77.0 (C:Librariesboost_1_77_0)

Boost 1.73.0 (C:Librariesboost_1_73_0)

Boost 1.69.0 (C:Librariesboost_1_69_0)

Boost 1.67.0 (C:Librariesboost_1_67_0)

Boost 1.66.0 (C:Librariesboost_1_66_0)

Boost 1.65.1 (C:Librariesboost_1_65_1)

Boost 1.64.0 (C:Librariesboost_1_64_0)

Boost 1.63.0 (C:Librariesboost_1_63_0)

Boost 1.62.0 (C:Librariesboost_1_62_0)

Boost 1.60.0 (C:Librariesboost_1_60_0)

Boost 1.59.0 (C:Librariesboost_1_59_0)

Boost 1.58.0 (C:Librariesboost_1_58_0)

Boost 1.56.0 (C:Librariesboost)

Node.js

Node.js 19.0.1

Node.js 18.12.0

Node.js 17.9.1

Node.js 16.18.1

Node.js 15.14.0

Node.js 14.21.1

Node.js 13.14.0

Node.js 12.22.12

Node.js 11.15.0

Node.js 10.24.1

Node.js 9.11.2

Node.js 8.17.0 — default on VS 2015 and VS 2017 images

Node.js 7.10.1

Node.js 6.16.0

Node.js 4.9.1

Go (Golang)

• Go 1.19.2 x64 (C:go — default in PATH)
• Go 1.19.2 x86 (C:go-x86)
• Go 1.19.2 x64 (C:go119)
• Go 1.19.2 x86 (C:go119-x86)
• Go 1.18.7 x64 (C:go — default in PATH)
• Go 1.18.7 x86 (C:go-x86)
• Go 1.18.7 x64 (C:go118)
• Go 1.18.7 x86 (C:go118-x86)
• Go 1.17.13 x64 (C:go117)
• Go 1.17.13 x86 (C:go117-x86)
• Go 1.16.14 x64 (C:go116)
• Go 1.16.14 x86 (C:go116-x86)
• Go 1.15.15 x64 (C:go115)
• Go 1.15.15 x86 (C:go115-x86)
• Go 1.14.15 x64 (C:go114)
• Go 1.14.15 x86 (C:go114-x86)
• Go 1.13.15 x64 (C:go113)
• Go 1.13.15 x86 (C:go113-x86)

• Go 1.13.10 x64 (C:go — default in PATH)
• Go 1.13.10 x86 (C:go-x86)
• Go 1.13.10 x64 (C:go113)
• Go 1.13.10 x86 (C:go113-x86)
• Go 1.12.12 x64 (C:go112)
• Go 1.12.12 x86 (C:go112-x86)
• Go 1.11.13 x64 (C:go111)
• Go 1.11.13 x86 (C:go111-x86)
• Go 1.10.8 x64 (C:go110)
• Go 1.10.8 x86 (C:go110-x86)
• Go 1.9.7 x64 (C:go19)
• Go 1.9.7 x86 (C:go19-x86)
• Go 1.8.7 x64 (C:go18)
• Go 1.8.7 x86 (C:go18-x86)
• Go 1.7.6 x64 (C:go17)
• Go 1.7.6 x86 (C:go17-x86)
• Go 1.6.4 x64 (C:go16)
• Go 1.6.4 x86 (C:go16-x86)
• Go 1.5.4 x64 (C:go15)
• Go 1.5.4 x86 (C:go15-x86)
• Go 1.4.3 x64 (C:go14)
• Go 1.4.3 x86 (C:go14-x86)

Java SE Development Kit (JDK)

JDK 1.6 Update 45 (x64) (C:Program FilesJavajdk1.6.0bin — default in PATH)

JDK 1.6 Update 45 (x86) (C:Program Files (x86)Javajdk1.6.0bin)

JDK 1.7 Update 80 (x64) (C:Program FilesJavajdk1.7.0bin — default in PATH)

JDK 1.7 Update 80 (x86) (C:Program Files (x86)Javajdk1.7.0bin)

JDK 1.8 Update 162 (x64) (C:Program FilesJavajdk1.8.0)

JDK 1.8 Update 162 (x86) (C:Program Files (x86)Javajdk1.8.0)

JDK 1.8 Update 221 (x64) (C:Program FilesJavajdk1.8.0)

JDK 1.8 Update 221 (x86) (C:Program Files (x86)Javajdk1.8.0)

JDK 9.0.4 (x64) (C:Program FilesJavajdk9)

JDK 10.0.1 (x64) (C:Program FilesJavajdk10)

JDK 11.0.2 (x64) (C:Program FilesJavajdk11)

JDK 12 (x64) (C:Program FilesJavajdk12)

JDK 13 (x64) (C:Program FilesJavajdk13)

JDK 14 (x64) (C:Program FilesJavajdk14)

JDK 15 (x64) (C:Program FilesJavajdk15)

JDK 16 (x64) (C:Program FilesJavajdk16)

JDK 17 (x64) (C:Program FilesJavajdk17)

JDK 18 (x64) (C:Program FilesJavajdk18)

JDK 19 (x64) (C:Program FilesJavajdk19)

Apache Maven 3.5.4

Apache Maven 3.8.6

Mono

Mono 4.0.2 SR2

Ruby (with DevKit)

• Ruby 1.9.3-p551 (C:Ruby193bin — default in PATH)
• Ruby 2.0.0-p648 x86 (C:Ruby200bin)
• Ruby 2.0.0-p648 x64 (C:Ruby200-x64bin)
• Ruby 2.1.9 x86 (C:Ruby21bin)
• Ruby 2.1.9 x64 (C:Ruby21-x64bin)
• Ruby 2.2.6 x86 (C:Ruby22bin)
• Ruby 2.2.6 x64 (C:Ruby22-x64bin)
• Ruby 2.3.3 x86 (C:Ruby23bin)
• Ruby 2.3.3 x64 (C:Ruby23-x64bin)
• Ruby 2.4.6-1 x86 (C:Ruby24bin)
• Ruby 2.4.6-1 x64 (C:Ruby24-x64bin)
• Ruby 2.5.5-1 x86 (C:Ruby25bin)
• Ruby 2.5.5-1 x64 (C:Ruby25-x64bin)
• Ruby 2.6.3 x86 (C:Ruby26bin)
• Ruby 2.6.3 x64 (C:Ruby26-x64bin)

• Ruby 1.9.3-p551 (C:Ruby193bin)
• Ruby 2.0.0-p648 x86 (C:Ruby200bin)
• Ruby 2.0.0-p648 x64 (C:Ruby200-x64bin)
• Ruby 2.1.9 x86 (C:Ruby21bin)
• Ruby 2.1.9 x64 (C:Ruby21-x64bin)
• Ruby 2.2.6 x86 (C:Ruby22bin)
• Ruby 2.2.6 x64 (C:Ruby22-x64bin)
• Ruby 2.3.3 x86 (C:Ruby23bin)
• Ruby 2.3.3 x64 (C:Ruby23-x64bin)
• Ruby 2.4.10 x86 (C:Ruby24bin)
• Ruby 2.4.10 x64 (C:Ruby24-x64bin)
• Ruby 2.5.9 x86 (C:Ruby25bin)
• Ruby 2.5.9 x64 (C:Ruby25-x64bin)
• Ruby 2.6.9 x86 (C:Ruby26bin)
• Ruby 2.6.9 x64 (C:Ruby26-x64bin)
• Ruby 2.7.5 x86 (C:Ruby27bin)
• Ruby 2.7.5 x64 (C:Ruby27-x64bin)
• Ruby 3.0.4 x86 (C:Ruby30bin)
• Ruby 3.0.4 x64 (C:Ruby30-x64bin)
• Ruby 3.1.2 x86 (C:Ruby31bin)
• Ruby 3.1.2 x64 (C:Ruby31-x64bin — default in PATH)

Python

Python 2.6.6 x86 (C:Python26)

Python 2.6.6 x64 (C:Python26-x64)

Python 2.7.15 x86 (C:Python310 — default in PATH)

Python 2.7.15 x64 (C:Python27-x64)

Python 2.7.18 x86 (C:Python27 — default in PATH)

Python 2.7.18 x64 (C:Python27-x64)

Python 3.3.5 x86 (C:Python33)

Python 3.3.5 x64 (C:Python33-x64)

Python 3.4.4 x86 (C:Python34)

Python 3.4.4 x64 (C:Python34-x64)

Python 3.5.4 x86 (C:Python35)

Python 3.5.4 x64 (C:Python35-x64)

Python 3.6.6 x86 (C:Python36)

Python 3.6.6 x64 (C:Python36-x64)

Python 3.6.8 x86 (C:Python36)

Python 3.6.8 x64 (C:Python36-x64)

Python 3.7.0 x86 (C:Python37)

Python 3.7.0 x64 (C:Python37-x64)

Python 3.7.5 x86 (C:Python37)

Python 3.7.5 x64 (C:Python37-x64)

Python 3.7.9 x86 (C:Python37)

Python 3.7.9 x64 (C:Python37-x64)

Python 3.8.0 x86 (C:Python38)

Python 3.8.0 x64 (C:Python38-x64)

Python 3.8.10 x86 (C:Python38)

Python 3.8.10 x64 (C:Python38-x64)

Python 3.9.13 x86 (C:Python39)

Python 3.9.13 x64 (C:Python39-x64)

Python 3.10.8 x86 (C:Python310)

Python 3.10.8 x64 (C:Python310-x64)

Python 3.11.0 x86 (C:Python311)

Python 3.11.0 x64 (C:Python311-x64)

pip 19.3.1

pip 21.2.4

Visual C++ Compiler for Python 2.7

Miniconda

Miniconda2 4.7.12 (Python 2.7.16): C:Miniconda

Miniconda2 4.7.12 x64 (Python 2.7.16): C:Miniconda-x64

Miniconda2 4.5.11 (Python 2.7.15): C:Miniconda

Miniconda2 4.5.11 x64 (Python 2.7.15): C:Miniconda-x64

Miniconda3 3.16.0 (Python 3.4.3): C:Miniconda34

Miniconda3 3.16.0 x64 (Python 3.4.3): C:Miniconda34-x64

Miniconda3 4.2.12 (Python 3.5.2): C:Miniconda35

Miniconda3 4.2.12 x64 (Python 3.5.2): C:Miniconda35-x64

Miniconda3 4.5.4 (Python 3.6.5): C:Miniconda36

Miniconda3 4.5.4 x64 (Python 3.6.5): C:Miniconda36-x64

Miniconda3 4.7.12 (Python 3.7.4): C:Miniconda37 or C:Miniconda3

Miniconda3 4.7.12 x64 (Python 3.7.4): C:Miniconda37-x64 or C:Miniconda3-x64

Miniconda3 4.5.11 (Python 3.7.0): C:Miniconda37 or C:Miniconda3

Miniconda3 4.5.11 x64 (Python 3.7.0): C:Miniconda37-x64 or C:Miniconda3-x64

Miniconda3 4.8.2 (Python 3.7.6): C:Miniconda38

Miniconda3 4.8.2 x64 (Python 3.7.6 and Python 3.8.1): C:Miniconda38-x64

Perl

Strawberry Perl 5.32.1.1 (C:Strawberryperlbin)

Perl 5.26.2 (C:Program FilesGitusrbin in PATH)

Perl 5.20.1.2000 x86 (C:Perl in PATH)

Erlang

Erlang OTP runtime 20.2 x64 installed into C:Program Fileserl9.2

Erlang OTP runtime 22.3 x64 installed into C:Program Fileserl10.7

LLVM

LLVM 14.0.6 x64 (C:Program FilesLLVMbin in PATH)

LLVM 9.0.1 x64 (C:Program FilesLLVMbin in PATH)

LLVM 4.0.0 Compiler Infrastructure libraries (C:Librariesllvm-4.0.0)

LLVM 5.0.0 Compiler Infrastructure libraries (C:Librariesllvm-5.0.0)

MinGW, MSYS, Cygwin

• MinGW 32-bit 5.3.0 (core components and compilers — C:MinGW)
  • MinGW root directory: C:MinGW
  • MinGW bin directory: C:MinGWbin
  • MSYS root directory: C:MinGWmsys1.0

• MinGW-w64
  • 5.3.0: C:mingw-w64i686-5.3.0-posix-dwarf-rt_v4-rev0
  • 6.3.0 i686: C:mingw-w64i686-6.3.0-posix-dwarf-rt_v5-rev1
  • 6.3.0 x86_64: C:mingw-w64x86_64-6.3.0-posix-seh-rt_v5-rev1

• MinGW-w64
  • 7.2.0 x86_64: C:mingw-w64x86_64-7.2.0-posix-seh-rt_v5-rev1

• MinGW-w64
  • 7.3.0 x86_64: C:mingw-w64x86_64-7.3.0-posix-seh-rt_v5-rev0

• MinGW-w64
  • 8.1.0 x86_64: C:mingw-w64x86_64-8.1.0-posix-seh-rt_v6-rev0

• MinGW-w64
  • 8.1.0 i686: C:mingw-w64i686-8.1.0-posix-dwarf-rt_v6-rev0

Cygwin 3.1.7 (C:cygwin)

Cygwin 3.1.7 x64 (C:cygwin64)

Cygwin 3.0.7 (C:cygwin)

Cygwin 3.0.7 x64 (C:cygwin64)

MSYS2 (C:msys64)

Qt

• Qt 6.4.0: C:Qt6.4.0 (C:Qt6.4 mapped to C:Qt6.4.0 for backward compatibility)
  • MinGW 9.0.0 64 bit: C:Qt6.4.0mingw_64
  • msvc2019 64-bit: C:Qt6.4.0msvc2019_64
  • ARM 64-bit: C:Qt6.4.0msvc2019_arm64

• Qt 6.3.2: C:Qt6.3.2 (C:Qt6.3 mapped to C:Qt6.3.2 for backward compatibility)
  • MinGW 9.0.0 64 bit: C:Qt6.3.2mingw_64
  • msvc2019 64-bit: C:Qt6.3.2msvc2019_64
  • ARM 64-bit: C:Qt6.3.2msvc2019_arm64

• Qt 6.2.4: C:Qt6.2.4 (C:Qt6.2 mapped to C:Qt6.2.4 for backward compatibility)
  • MinGW 9.0.0 64 bit: C:Qt6.2.4mingw_64
  • msvc2019 64-bit: C:Qt6.2.4msvc2019_64

• Qt 5.15.2: C:Qt5.15.2 (C:Qt5.15 mapped to C:Qt5.15.2 for backward compatibility)
  • MinGW 8.1.0 64 bit: C:Qt5.15.2mingw81_64
  • MinGW 8.1.0 32 bit: C:Qt5.15.2mingw81_32
  • msvc2019 32-bit: C:Qt5.15.2msvc2019
  • msvc2019 64-bit: C:Qt5.15.2msvc2019_64

• Qt 5.13.2: C:Qt5.13.2 (C:Qt5.13 mapped to C:Qt5.13.2 for backward compatibility)
  • MinGW 7.3.0 64 bit: C:Qt5.13.2mingw73_64
  • MinGW 7.3.0 32 bit: C:Qt5.13.2mingw73_32
  • msvc2017 32-bit: C:Qt5.13.2msvc2017
  • msvc2017 64-bit: C:Qt5.13.2msvc2017_64

• Qt 5.13.2: C:Qt5.13.2 (C:Qt5.13 mapped to C:Qt5.13.2 for backward compatibility)
  • MinGW 7.3.0 64 bit: C:Qt5.13.2mingw73_64
  • MinGW 7.3.0 32 bit: C:Qt5.13.2mingw73_32
  • msvc2015 64-bit: C:Qt5.13.2msvc2015_64

• Qt 5.12.6: C:Qt5.12.6 (C:Qt5.12 mapped to C:Qt5.12.6 for backward compatibility)
  • MinGW 7.3.0 64 bit: C:Qt5.12.6mingw73_64
  • MinGW 7.3.0 32 bit: C:Qt5.12.6mingw73_32
  • msvc2017 32-bit: C:Qt5.12.6msvc2017
  • msvc2017 64-bit: C:Qt5.12.6msvc2017_64

• Qt 5.12.6: C:Qt5.12.6 (C:Qt5.12 mapped to C:Qt5.12.6 for backward compatibility)
  • MinGW 7.3.0 64 bit: C:Qt5.12.6mingw73_64
  • MinGW 7.3.0 32 bit: C:Qt5.12.6mingw73_32
  • msvc2015 64-bit: C:Qt5.12.6msvc2015_64

• Qt 5.11.3: C:Qt5.11.3 (C:Qt5.11 mapped to C:Qt5.11.3 for backward compatibility)
  • MinGW 5.3.0 32 bit: C:Qt5.11.3mingw53_32
  • msvc2015 32-bit: C:Qt5.11.3msvc2015

• Qt 5.11.3: C:Qt5.11.3 (C:Qt5.11 mapped to C:Qt5.11.3 for backward compatibility)
  • msvc2015 64-bit: C:Qt5.11.3msvc2015_64

• Qt 5.10.1: C:Qt5.10.1 (C:Qt5.10 mapped to C:Qt5.10.1 for backward compatibility)
  • msvc2017 64-bit: C:Qt5.10.1msvc2017_64
  • WinRT ARM v7: C:Qt5.10.1winrt_armv7_msvc2017
  • WinRT 32-bit: C:Qt5.10.1winrt_x86_msvc2017
  • WinRT 64-bit: C:Qt5.10.1winrt_x64_msvc2017

• Qt 5.10.1: C:Qt5.10.1 (C:Qt5.10 mapped to C:Qt5.10.1 for backward compatibility)
  • MinGW 5.3.0 32 bit: C:Qt5.10.1mingw53_32
  • msvc2015 32-bit: C:Qt5.10.1msvc2015

• Qt 5.10.1: C:Qt5.10.1 (C:Qt5.10 mapped to C:Qt5.10.1 for backward compatibility)
  • msvc2015 64-bit: C:Qt5.10.1msvc2015_64
  • msvc2013 64-bit: C:Qt5.10.1msvc2013_64

• Qt 5.9.9: C:Qt5.9.9 (C:Qt5.9 mapped to C:Qt5.9.9 for backward compatibility)
  • MinGW 5.3.0 32 bit: C:Qt5.9.9mingw53_32
  • msvc2015 32-bit: C:Qt5.9.9msvc2015
  • msvc2017 64-bit: C:Qt5.9.9msvc2017_64

• Qt 5.9.9: C:Qt5.9.9 (C:Qt5.9 mapped to C:Qt5.9.9 for backward compatibility)
  • msvc2017 64-bit: C:Qt5.9.9msvc2017_64

• Qt 5.9.9: C:Qt5.9.9 (C:Qt5.9 mapped to C:Qt5.9.9 for backward compatibility)
  • MinGW 5.3.0 32 bit: C:Qt5.9.9mingw53_32
  • msvc2015 32-bit: C:Qt5.9.9msvc2015

• Qt 5.9.9: C:Qt5.9.9 (C:Qt5.9 mapped to C:Qt5.9.9 for backward compatibility)
  • msvc2015 64-bit: C:Qt5.9.9msvc2015_64
  • msvc2013 64-bit: C:Qt5.9.9msvc2013_64

• Qt 5.7.0: C:Qt5.7.0
  • MinGW 5.3.0 32 bit: C:Qt5.7.0mingw53_32
  • msvc2015 32-bit: C:Qt5.7.0msvc2015

• Qt 5.6.3: C:Qt5.6.3 (C:Qt5.6 mapped to C:Qt5.6.3 for backward compatibility)
  • MinGW 4.9.0 32 bit: C:Qt5.6.3mingw49_32
  • msvc2015 64-bit: C:Qt5.6.3msvc2015_64
  • msvc2015 32-bit: C:Qt5.6.3msvc2015

• Qt 5.6.3: C:Qt5.6.3 (C:Qt5.6 mapped to C:Qt5.6.3 for backward compatibility)
  • msvc2013 64-bit: C:Qt5.6.3msvc2013_64
  • msvc2013 32-bit: C:Qt5.6.3msvc2013

• Qt 5.8.0: C:Qt5.8
• Qt 5.7.1: C:Qt5.7
• Qt 5.6.2: C:Qt5.6
• Qt 5.5: C:Qt5.5
• Qt 5.4: C:Qt5.4
• Qt 5.3: C:Qt5.3

Qt Installer Framework 2.0.5

Qt Installer Framework 3.0.6

Qt Installer Framework 3.1.1

• Qt tools:
  • MinGW 8.1.0: C:QtToolsmingw810_32
  • MinGW 7.3.0: C:QtToolsmingw730_32
  • MinGW 5.3.0: C:QtToolsmingw530_32
  • MinGW 4.9.2: C:QtToolsmingw492_32

Tools

curl 7.84.0

7-Zip 19.00

7-Zip 22.01

Microsoft Web Platform Installer 5.0

CMake 3.24.2

CMake 3.16.2

CMake 3.12.2

NuGet 2.8.6

NuGet 4.9.2

NuGet 6.3.1

Chocolatey v0.11.2

GitVersion 4.0.0

GitVersion 5.10.3

Ninja 1.9.0

Ninja 1.11.1

Meson 0.52.1

Meson 0.63.3

FxCop 10.0

OpenSSL 1.0.2p (32-bit) (C:OpenSSL-Win32bin)

OpenSSL 1.0.2p (64-bit) (C:OpenSSL-Win64bin)

OpenSSL 1.1.0i (32-bit) (C:OpenSSL-v11-Win32bin)

OpenSSL 1.1.0i (64-bit) (C:OpenSSL-v11-Win64bin)

OpenSSL 1.1.1 (32-bit) (C:OpenSSL-v111-Win32bin)

OpenSSL 1.1.1 (64-bit) (C:OpenSSL-v111-Win64bin)

OpenSSL 1.0.2u (32-bit) (C:OpenSSL-Win32bin)

OpenSSL 1.0.2u (64-bit) (C:OpenSSL-Win64bin)

OpenSSL 1.1.0L (32-bit) (C:OpenSSL-v11-Win32bin)

OpenSSL 1.1.0L (64-bit) (C:OpenSSL-v11-Win64bin)

OpenSSL 1.1.1d (32-bit) (C:OpenSSL-v111-Win32bin)

OpenSSL 1.1.1d (64-bit) (C:OpenSSL-v111-Win64bin)

OpenSSL 1.1.1s (32-bit) (C:OpenSSL-v111-Win32bin)

OpenSSL 1.1.1s (64-bit) (C:OpenSSL-v111-Win64bin)

OpenSSL 3.0.7 (32-bit) (C:OpenSSL-v30-Win32bin)

OpenSSL 3.0.7 (64-bit) (C:OpenSSL-v30-Win64bin)

NSIS 3.08 (C:Program Files (x86)NSIS)

NSIS 3.04 (C:Program Files (x86)NSIS)

InnoSetup 5.5.9 Unicode (C:Program Files (x86)Inno Setup 5)

InnoSetup 6.1.2 Unicode (C:Program Files (x86)Inno Setup 6)

Coverity Scan 2017.07

Coverity Scan 2021.12

Yarn 1.22.19

Yarn 1.21.1

vcpkg 2019.09.12-nohash

vcpkg 2020.02.04-nohash

Doxygen 1.9.5

Graphviz 2.38

Octopus Tools 6.2.3

Octopus Tools 6.17.0

Google Cloud SDK (`gcloud.exe` tool)

Test runners

NUnit 2.6.4 in C:ToolsNUnitbin

NUnit 2.7.1 in C:ToolsNUnitbin

NUnit 3.7.0 in C:ToolsNUnit3

NUnit 3.13.0 in C:ToolsNUnit3

xUnit 1.9.2 in C:ToolsxUnit

xUnit 2.0.0 RTM in C:ToolsxUnit20

xUnit 2.4.1 in C:ToolsxUnit20

Machine.Specifications (MSpec)

Web browsers

Internet Explorer 11

Firefox 62

Firefox 72

Firefox 106.0.3

Chrome 69

Chrome 79

Chrome 107.0.5304.62

Microsoft Edge 79.0.309.65

Microsoft Edge 107.0.1418.26

Selenium testing

Chrome Web Driver 2.41

Chrome Web Driver 79

Chrome Web Driver 107.0.5304.62

Edge Web Driver 107.0.1418.26

Internet Explorer Web Driver 3.14

Internet Explorer Web Driver 3.150.1

Firefox Web Driver (geckodriver) 0.21.0

Firefox Web Driver (geckodriver) 0.26

Databases

SQL Server 2008 R2 SP2 Express Edition with Advanced Services (x64)

SQL Server 2012 SP1 Express with Advanced Services

SQL Server 2014 Express with Advanced Services

SQL Server 2016 Developer with SP1

SQL Server 2017 Developer

SQL Server 2019 Developer

Visual Studio 2019 SQL Server Integration and Analysis projects

PostgreSQL 9.3 x64

PostgreSQL 9.4 x64

PostgreSQL 9.5 x64

PostgreSQL 9.6.9 x64

PostgreSQL 10.4 x64

PostgreSQL 10.18 x64

PostgreSQL 11.13 x64

PostgreSQL 12.8 x64

PostgreSQL 13.4 x64

PostgreSQL 14.5 x64

PostgreSQL 15.0 x64

PostgreSQL ODBC drivers

MySQL 5.7

MySQL ODBC drivers

MongoDB 4.0.1

Services

Internet Information Services (IIS) 8.5

Internet Information Services (IIS) 10

MSMQ

This page lists the functions and variables that are newly exported
by name from the Windows kernel in the 1903 release
for Windows 10. Two functions that are new to this release are exported only by
ordinal and are listed among the Ordinal-Only Kernel Exports
Added for Version 10.0.

For the table below, documentation status is summarised by colour coding so that
more detail can be given as Remarks with less text. (If you read this website with
scripts enabled, then hovering the mouse over any coloured text will produce a tooltip
that shows why the text is coloured.) Functions that have their own non-trivial
documentation are shown with no background colour. If the function is documented
as reserved or obsolete, it is shaded red or
shaded grey, respectively. Functions that appear to
be completely undocumented are highlighted yellow.
If a function is documented now but was not documented in the first contemporaneous
Device Driver Kit (DDK), Windows Driver Kit (WDK) or Installable File System (IFS)
Kit, then it is shaded yellow to retain some of its
previous status. Many undocumented functions do at least have C-language declarations
in one or another header file from the WDK. These are shaded
orange, except for one special case. Some declarations are known only from
“minwin” headers that Microsoft published in early editions of the WDK for Windows
10 which seem since to have been withdrawn. These are highlighted
orange to indicate that public knowledge even of the declaration is exceptional.

It’s not the ordinary practice for this survey to say anything for the Documentation
History or Declaration History if what Microsoft says is correct or if Microsoft
says nothing. Either ought to be completely unremarkable. But of the functions that
are newly exported from the kernel in Version 1903, so few are documented or have
declarations in any WDK header, and of these few almost all are said by Microsoft
to be available in Version 1809. So, perhaps it’s as well to spell out that for
RtlFillMemoryNonTemporal Microsoft gives no version
information but that versions are specified for RtlFillNonVolatileMemory
and are correct!

The WheaAddErrorSourceDeviceDriver function
that is documented at Microsoft’s website today, 14th October 2020, is not the same-named
function that is newly exported from the Version 1903 kernel. It is instead what
the function was changed to for the 2004 release. In this sense, Microsoft’s documentation,
dated 1st April 2020, is correct that the function requires at least Version 2004.
This is a very rare case of a documented function being changed incompatibly. The
original has four arguments. The new has three. The original continues to be exported
from the kernel in Version 2004 but with the new name WheaAddErrorSourceDeviceDriverV1.

Having not looked for WheaAddErrorSourceDeviceDriver
at Microsoft’s website in 2019, I can’t say certainly that its original form wasn’t
documented for the 1903 release, but I detect a strong suggestion. The function’s
obvious partner, WheaRemoveErrorSourceDeviceDriver,
did not change for the 2004 release yet Microsoft dates this function’s documentation
to 28th April 2020, not to 2019. Contrast with WheaReportHwErrorDeviceDriver,
whose documentation is dated 5th March 2019 (and says correctly that the function’s
availabilty starts at 1903).

From Microsoft’s own dates, documentation of four new
Whea functions as reserved did not happen until
19th August 2019. This is too late to count as documentation for the 1903 release.
They do all have declarations, however, in NTDDK.H from the WDK for Windows 10 Version
1903.

As with many Zw functions,
ZwSystemDebugControl has earlier history as
a user-mode export from NTDLL.DLL—indeed, in this case all the way back to version
3.10. A declaration thus appears in the ZWAPI.H header that Microsoft published
only in early editions of the WDK for Windows 10. It would otherwise be
undocumented.

Discontinued

The 1903 release of the Windows 10 kernel stops exporting three functions. All
had only brief lives. The versions in parentheses tells when the functions were
first exported:

• PoFxCompleteDirectedPowerTransition
  (1809);
• PoFxRegisterInternalDevice (1809);
• PoReportDirectedDripsCandidateDevice
  (1803).

This topic summarizes the new features and improvements for Windows Driver Frameworks (WDF) drivers in WindowsВ 10.

WindowsВ 10, version 1903 (March 2019 Update, 19H1) includes Kernel-Mode Driver Framework (KMDF) version 1.29 and User-Mode Driver Framework (UMDF) version 2.29.

You can use these framework versions to build drivers for:

• WindowsВ 10 (all SKUs)
• Windows Server, version 1809

For version history, see KMDF Version History and UMDF Version History. Except where noted, UMDF references on this page describe version 2 functionality that is not available in UMDF version 1.

New in WDF for Windows 10, version 1903

No functionality added or changed.

New in WDF for Windows 10, version 1809

• Added new API WdfDriverRetrieveDriverDataDirectoryString

New in WDF for Windows 10, version 1803

New in WDF for Windows 10, version 1709

New in WDF for Windows 10, version 1703

In Windows 10, version 1703, WDF includes the following enhancements:

New WDF Verifier settings to detect excessive object creation

In some cases, framework objects are incorrectly parented and not deleted after use. With this feature, you can specify a maximum number of objects and what should happen when this threshold is exceeded.

To start monitoring, add the following registry values under: HKEY_LOCAL_MACHINESystemCurrentControlSetServices Parameterswdf

Add a DWORD value named ObjectLeakDetectionLimit with the threshold value. This is the maximum number of objects of the types described in the ObjectsForLeakDetection key.

Add a new REG_MULTI_SZ value named ObjectsForLeakDetection that lists each type name to verify. For example, you could specify WDFDMATRANSACTION WDFDEVICE . To specify all handle types, use * as the string.

To control whether exceeding this threshold should cause a debug break or a bugcheck, set the DbgBreakOnError key.

By default, if the ObjectsForLeakDetection key is not specified, the framework monitors WDFREQUEST, WDFWORKITEM, WDFKEY, WDFSTRING, WDFOBJECT, and WDFDEVICE.

The limit scales with the number of devices installed, so if the driver creates three WDFDEVICE objects, the WDF Verifier limit is three times the value specified in ObjectLeakDetectionLimit.

If you specify WDFREQUEST, the verifier only counts WDFREQUEST objects that the driver creates.

This feature does not currently support tracking the WDFMEMORY object type.

SleepStudy tool provides info on KMDF drivers

The SleepStudy software tool reports the number of power references that a KMDF driver has that are preventing the system from going to sleep. For more info, see Modern standby SleepStudy.

The rest of this page describes functionality that was added in Windows 10, version 1507.

WDF source code is publicly available

The WDF source code is now available as open source on GitHub. This is the same source code from which the WDF runtime library that ships in WindowsВ 10 is built. You can debug your driver more effectively when you can follow the interactions between the driver and WDF. Download it from https://github.com/Microsoft/Windows-Driver-Frameworks.

The private symbol files for WDF on WindowsВ 10 are now available through the Microsoft Symbol Server.

The Windows Driver Kit (WDK)В 10 samples are also now published to GitHub. Download them from https://github.com/Microsoft/Windows-Driver-Samples.

Automatic Source Level Debugging of Framework Code

When you use WinDbg to debug a WDF driver on WindowsВ 10, WinDbg automatically retrieves the framework source code from Microsoft’s public GitHub repository. You can use this feature to step through the WDF source code while debugging, and to learn about framework internals without downloading the source code to a local machine. For more information, see New support for source-level debugging of WDF code in Windows 10, Debugging with WDF Source, and Video: Debugging your driver with WDF source code.

Universal Driver Compliance

All WDF driver samples and Visual Studio driver templates are Universal Windows driver compliant.

All KMDF and UMDF 2 functionality is Universal Windows driver compliant.

Note that UMDF 1 drivers run only on WindowsВ 10 for desktop editions and earlier versions of desktop Windows. Want to benefit from the universal capabilities of UMDF 2? To learn how to port your old UMDF 1 driver, see Porting a Driver from UMDF 1 to UMDF 2.

Debugging and Diagnosability

All KMDF and UMDF 2 drivers can use an always on, always available Inflight Trace Recorder (IFR). When a driver provides a custom trace, the driver IFR log contains the trace messages. Note that the new driver IFR log is separate from the framework IFR log that WDF creates for each driver.

The IFR maintains a circular buffer of WPP traces in non-pageable memory. If a driver crashes, the logs are frequently included in the crash dump file.

If you turn on the IFR in your driver binary, the IFR is present and running during the lifetime of your driver. You don’t need to start an explicit trace collection session.

IFR logs are included in minidump files except when the responsible driver is undetermined or if the crash was a host timeout.

If you have a debugger connected, you can access both the driver and framework IFR logs by issuing !wdfkd.wdflogdump.

If you do not have a debugger connected, you can still access both logs. To learn how, see Video: Accessing driver IFR logs without a debugger.

When debugging a UMDF driver, you can merge framework logs with driver logs by issuing: !wdfkd.wdflogdump -m

UMDF logs (WudfTrace.etl) and dumps are now located in %ProgramData%MicrosoftWDF instead of %systemDrive%LogFilesWudf.

New debugger command: !wdfkd.wdfumtriage provides a kernel-centric view of all UMDF devices on the system.

You can run !analyze to investigate UMDF verifier failures or UMDF unhandled exceptions. This works for live kernel debugging as well as debugging user crash dump files from %ProgramData%MicrosoftWDF.

In KMDF and UMDF 2, you can monitor power reference usage in the debugger. For info, see Debugging Power Reference Leaks in WDF.

You can use !wdfkd.wdfcrashdump to display error information about UMDF 2 drivers. For more information, see !wdfkd.wdfcrashdump.

Performance Tracing tool for WDF drivers

You can use the Windows Performance Toolkit (WPT) to view performance data for a given KMDF or UMDF 2 driver. When tracing is enabled, the framework generates ETW events for I/O, PnP, and Power callback paths. You can then view graphs in the Windows Performance Analyzer (WPA) that show I/O throughput rates, CPU utilization, and callback performance. The WPT is included in the Windows Assessment and Deployment Kit (ADK).

Additional support for HID drivers in UMDF

UMDF now fully supports HID filters (enumerated by HIDClass) and minidrivers. Simply port your existing KMDF driver or write a new UMDF 2 filter; the functionality is automatically enabled.

UMDF HID minidrivers that are enumerated by ACPI can perform selective suspend. For more information, see Creating WDF HID Minidrivers.

UMDF drivers can now be installed in the HID stack for low latency input devices such as touch and mouse. A driver for an input device should specify the UmdfHostPriority INF directive. For information, see Specifying WDF Directives in INF Files.

Support for interrupts for GPIO-backed devices

• UMDF 2 supports interrupts for GPIO-backed devices like hardware push-buttons. KMDF supports these devices natively, without the workaround described in Handling Active-Both Interrupts. For more information, see Creating an Interrupt Object.

UMDF no longer requires WinUSB

New support has been added for USB drivers in UMDF. A UMDF 2 USB driver no longer uses WinUSB. To use the new functionality, the driver sets the UmdfDispatcher directive to NativeUSB, instead of WinUSB. See Specifying WDF Directives in INF Files.

Improved Performance

UMDF system components consume less disk space.

KMDF and UMDF drivers use less non-paged memory.

Improved framework version checking reduces header/library mismatches.

UMDF provides improved buffer mapping for HID transfers.

Kernel Mode Driver Framework Runtime by Microsoft Corporation.

This service also exists in Windows 7, 8 and Vista.

Startup Type

Default Properties

Default Behavior

The Kernel Mode Driver Frameworks service is a kernel mode driver. If Kernel Mode Driver Frameworks service fails to start, the error is logged. Windows 10 startup proceeds, but a message box is displayed informing you that the Wdf01000 service has failed to start.

Restore Default Startup Type for Kernel Mode Driver Frameworks service

Automated Restore

1. Select your Windows 10 edition and release, and then click on the Download button below.

2. Save the RestoreKernelModeDriverFrameworksserviceWindows10.bat file to any folder on your hard drive.

3. Right-click the downloaded batch file and select Run as administrator.

4. Restart the computer to save changes.

Note. Make sure that the Wdf01000.sys file exists in the %WinDir%system32drivers folder. If this file is missing you can try to restore it from your Windows 10 installation media.

Содержание статьи

Процессорные архитектуры x86 и x64 имеют четыре кольца защиты, из которых в Windows по факту используются всего два — это ring 3 (режим пользователя) и ring 0 (режим ядра). Бытует мнение, что код режима ядра — самый привилегированный и «ниже» ничего нет. На самом деле архитектура x86/x64 позволяет опускаться еще ниже: это технология виртуализации (hypervisor mode), которая считается кольцом −1 (ring −1), и режим системного управления (System Management Mode, SMM), считающийся кольцом −2 (ring −2), которому доступна память режима ядра и гипервизора.

Итак, мы решили писать собственный драйвер. Начнем с выбора инструментария. Я советую использовать Microsoft Visual Studio, как наиболее user-friendly IDE. Также необходимо будет установить Windows SDK и Windows Driver Kit (WDK) для твоей версии ОС. Кроме того, я крайне рекомендую запастись такими утилитами, как DebugView (просмотр отладочного вывода), DriverView (позволяет получить список всех установленных драйверов) и KmdManager (удобный загрузчик драйверов).

Драйверы в Windows начиная с Vista могут быть как режима пользователя (User-Mode Driver Framework, UMDF), так и режима ядра (Kernel-Mode Driver Framework, KMDF). Более ранние драйверы Windows Driver Model (WDM) появились в Windows 98 и сейчас считаются устаревшими.

Драйверы UMDF имеют намного более ограниченные права, чем KMDF, однако они используются, например, для управления устройствами, подключенными по USB. Помимо ограничений, у них есть очевидные плюсы: их намного проще отлаживать, а ошибка в их написании не вызовет глобальный системный сбой и синий экран смерти. Такие драйверы имеют расширение dll.

Что до драйверов режима ядра (KMDF), то им дозволено куда больше, а расширение файлов, закрепленное за ними, — это sys. В этой статье мы научимся писать простые драйверы режима ядра, напишем драйвер для скрытия процессов методом DKOM (Direct Kernel Object Manipulation) и его загрузчик.

Создание драйвера KMDF

После того как ты создашь проект драйвера, Visual Studio автоматически настроит некоторые параметры. Проект будет компилироваться в бинарный файл в соответствии с тем, какая выбрана подсистема. Наш вариант — это NATIVE, подсистема низкого уровня, как раз для того, чтобы писать драйверы.

Точка входа в драйвер

Строго говоря, точка входа в драйвер может быть любой — мы можем сами ее определить, добавив к параметрам компоновки проекта -entry:[DriverEntry] , где [DriverEntry] — название функции, которую мы хотим сделать стартовой. Если в обычных приложениях основная функция обычно называется main, то в драйверах точку входа принято называть DriverEntry.

Выглядеть это будет так:

Давай пройдемся по параметрам, которые передаются DriverEntry . pDriverObject имеет тип PDRIVER_OBJECT , это значит, что это указатель на структуру DRIVER_OBJECT , которая содержит информацию о нашем драйвере. Мы можем менять некоторые поля этой структуры, тем самым меняя свойства драйвера. Второй параметр имеет тип PUNICODE_STRING , который означает указатель на строку типа UNICODE . Она, в свою очередь, указывает, где в системном реестре хранится информация о нашем драйвере.

WARNING

Любая ошибка в драйвере может вызвать общесистемный сбой и BSOD. Вероятна потеря данных и повреждение системы. Все эксперименты я рекомендую проводить в виртуальной машине.

Interrupt Request Level (IRQL)

IRQL — это своеобразный «приоритет» для драйверов. Чем выше IRQL, тем меньшее число других драйверов будут прерывать выполнение нашего кода. Существует несколько уровней IRQL: Passive, APC, Dispatch и DIRQL. Если открыть документацию MSDN по функциям WinAPI, то можно увидеть примечания, которые регламентируют уровень IRQL, который требуется для обращения к каждой функции. Чем выше этот уровень, тем меньше WinAPI нам доступно для использования. Первые три уровня IRQL используются для синхронизации программных частей ОС, уровень DIRQL считается аппаратным и самым высоким по сравнению с программными уровнями.

Пакеты запроса ввода-вывода (Input/Output Request Packet)

IRP — это запросы, которые поступают к драйверу. Именно при помощи IRP один драйвер может «попросить» сделать что-то другой драйвер либо получить запрос от программы, которая им управляет. IRP используются диспетчером ввода-вывода ОС. Чтобы научить программу воспринимать наши IRP, мы должны зарегистрировать функцию обратного вызова и настроить на нее массив указателей на функции. Код весьма прост:

А вот код функции-заглушки, которая всегда возвращает статусный код STATUS_SUCCESS . В этой функции мы обрабатываем запрос IRP.

Теперь любой запрос к нашему драйверу вызовет функцию-заглушку, которая всегда возвращает STATUS_SUCCESS . Но что, если нам нужно попросить драйвер сделать что-то конкретное, например вызвать определенную функцию? Для этого регистрируем управляющую процедуру:

Здесь мы объявили процедуру с именем IRP_MY_FUNC и ее кодом — 0x801 . Чтобы драйвер ее обработал, мы должны настроить на нее ссылку, создав таким образом дополнительную точку входа в драйвер:

После этого нам нужно получить указатель на стек IRP, который мы будем обрабатывать. Это делается при помощи функции IoGetCurrentIrpStackLocation , на вход которой подается указатель на пакет. Кроме этого, необходимо будет получить от диспетчера ввода-вывода размеры буферов ввода-вывода, чтобы иметь возможность передавать и получать данные от пользовательского приложения. Шаблонный код каркаса обработчика управляющей процедуры:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Driver Verifier (DV) may return an error when /volatile flag is used on Windows 10, version 1903

In Windows 10 version 1903 performance improvements were made that indirect calls in driver’s Import Address Table (IAT) were converted direct calls when Import Optimization (IO) is enabled. If DV is enabled at boot, then IO auto-disables itself by detecting
DV is on. This causes a perf degradation since IO is turned off. If IO is enabled at boot, then attempting application of DV volatile setting fails by detecting IO is on. The failure message will state: “Failed to start the verification for ‘<driver name
here>’ driver. The request is not supported.”

In general DV should not change behavior of the OS and in future release the focus will be to run IO and DV together with no perf degradation.

Work around:
Use 1803 on a separate machine if Deploy driver  feature is needed.

«Warning MSB8038 Spectre mitigations is enabled but Spectre mitigated libraries are not found. Verify that the Visual Studio Workload includes the Spectre mitigated libraries. See
https://aka.ms/0fhn4c for more information.» 

Resolution: 

For each architecture you intend to build drivers for, install the Spectre mitigated libraries thru Individual Components -> Compilers, build tools, and runtimes -> MSVC v142 — VS 2019 C+ x64/x86 Spectre-mitigated libs (v14.21).

Once WDK is installed all C++ projects require Spectre mitigations to be installed

WDK enables Spectre mitigations by default for all drivers, this is by design. There is a known issue where once WDK is installed all C++ projects, regardless if the project is a driver project or not,
at build time this message will be seen:

Error seen when Provisioning a computer for driver deployment and testing when using WDK 1903 and Visual Studio 16.1 +

Нажать на кнопку создания нового проекта (Create a new project), в списке типов проекта выбрать KMDF Driver, Empty, нажать Next.

Я назову проект HelloWorldDriver.

Добавить файл исходного кода Project->Add new Item->C++ File (.cpp). Дать название файлу, например, HelloWorldDriver.c

При вводе имени файла укажите расширение *.c. Visual Studio определяет целевой язык по расширению файла, таким образом исходный код, расположенный в файлах с расширением *.c воспринимается как код на языке Си.

Далее приведен исходный код нашего учебного драйвера с короткими комментариями.

Вообще говоря, исходный код несколько избыточен. Функция выгрузки драйвера не является обязательной, однако без нее драйвер будет считаться невыгружаемым, что существенно усложняет установку новой версии. Так, при возможности выгрузки драйвера для его обновления достаточно остановки, замены бинарного файла и запуска, тогда как для невыгружаемого драйвера придется перезагружать систему.

Также не является обязательным примение макроса UNREFERENCED_PARAMETER. По умолчанию (и это правильно) проекты типа Windows Driver компилируются с флагом /WX — Treat Warnings As Errors, что не позволяет скомпилировать драйвер даже с предупреждениями, одним из которых является C4100: unreferenced formal parameter —
неиспользуемый параметр. Можно либо отключить этот флаг в настройках проекта Project->Properties->C/C++->General, параметр Threat Warnings As Errors, однако применение макроса более предпочтительно, так как заставляет разработчика в большей степени отдавать отчет своим действиям.

// Основной файл WDK
#include <ntddk.h>

// Объявление функции выгрузки драйвера
VOID DriverUnload(PDRIVER_OBJECT driverObject);

// Точка входа в драйвер (аналог функции main)
NTSTATUS DriverEntry(IN PDRIVER_OBJECT driverObject, IN PUNICODE_STRING registryPath)
{
  // Отметка параметра неиспользуемым
  UNREFERENCED_PARAMETER(registryPath);

  // Печать отладочного сообщения
  DbgPrint("Hello from Windows kernel mode!!");

  // Регистрация функции выгрузки драйвера
  driverObject->DriverUnload = DriverUnload;

  return STATUS_SUCCESS;
}

// Функция выгрузки драйвера
VOID DriverUnload(IN PDRIVER_OBJECT driverObject)
{
  // Отметка параметра неиспользуемым
  UNREFERENCED_PARAMETER(driverObject);
  // Вывод отладочного сообщения
  DbgPrint("Goodbye!");
}

Теперь можно скомпилировать драйвер Build->Build Solution и посмотреть, какие файлы сгенерированы. Необходимо учитывать платформу тестовой системы и осуществлять сборку правильно. У меня в качестве тестовой системы будет 64-разрядная версия Windows, поэтому мне нужно изменить конфигурацию на x64.

В выходной директории (по умолчанию это $SolutionDirx64Debug) появились файлы. Краткое описание каждого из них:

1. HelloWorldDriver.cer — сертификат.

   Каждый драйвер должен иметь цифровую подпись (начиная с 2017 года все драйверы должны быть подписаны самой Microsoft, обязательное условие — прохождение тестов WHQL), хотя в сегодняшнем примере сертификат не нужен совсем. Вопросы сертификации выходят за рамки данной статьи.

2. HelloWorldDriver.inf — вспомогательный файл для установки драйвера с
   использованием Мастера установки Windows.

3. HelloWorldDriver.pdb — отладочные символы.

4. HelloWorldDriver.sys — сам драйвер.

Для установки драйвера при помощи системной утилиты SC нужно исполнить команду SC CREATE <название_драйвера> binPath= <путь_до_sys_файла> type=kernel

Запустить VMWare, открыть настройки виртуальной машины (нажатием Edit virtual machine settings).

В окне настроек виртуальной машины нажать кнопку Add.

В появившемся окне выбрать Serial Port, нажать Finish.

Для добавленного последовательного порта задать следующие настройки: Connection: Use named pipe, в поле для ввода ввести имя канала: \.pipe<pipename>, а в выпадающих списка выбрать соответственно This end is the server и The other end is an application.

Открыть конфигуратор тестовых устройств можно нажатием кнопки меню Extensions->Driver->Test->Configure Devices.

В первую очередь необходимо открыть окно конфигуратора нажатием кнопки Add New Device.

В окне ввести отображаемое имя тестовой системы, сетевое имя (можно ввести просто IP-адрес, либо включить сетевое обнаружение на тестовой системе), в Provisioning Options выбрать пункт Provision device and choose debugger settings, нажать Next.

В следующем окне раскрыть вкладку Windows Debugger — Kernel Mode и настроить опции:

1. Connection Type: Serial

2. Baud Rate: 115200

3. Pipe: Checked (отметить)

4. Reconnect: Checked (отметить)

5. Pipe name: \.pipeWin10

6. Target Port: com2 (или иной, должен совпадать с номером в настройках
   виртуальной машины)

Нажать Next.

Подождать выполнения настройки системы. В виртуальной машине вы можете наблюдать процессы создания нового пользователя, установку пакетов, выполнение скриптов. Это нормально. По окончании настройки виртуальная машина будет перегружена, а в Visual Studio появится сообщение об окончании настройки. В моем случае возникла одна ошибка при создании точки восстановления системы. Это можно проигнорировать. Нажать Finish.

В Visual Studio открыть конфигуратор тестовых устройств, однако на первом шаге выбрать вариант Manual configure debuggers and do not provision, нажать Next, в следующем окне настроить все идентично, как на рисунке.

Содержание

1. What’s New for WDF Drivers in WindowsВ 10
2. New in WDF for Windows 10, version 2004
3. New in WDF for Windows 10, version 1903
4. New in WDF for Windows 10, version 1809
5. New in WDF for Windows 10, version 1803
6. New in WDF for Windows 10, version 1709
7. New in WDF for Windows 10, version 1703
8. WDF source code is publicly available
9. Automatic Source Level Debugging of Framework Code
10. Universal Driver Compliance
11. Debugging and Diagnosability
12. Performance Tracing tool for WDF drivers
13. Additional support for HID drivers in UMDF
14. Support for interrupts for GPIO-backed devices
15. UMDF no longer requires WinUSB
16. Improved Performance
17. Как скачать Windows 10 May 2019 Update (версия 1903)
18. Как скачать Windows 10 May 2019 Update (версия 1903)
19. Способ 1 – с помощью Центра обновления Windows
20. Способ 2 – использование Media Creation Tool
21. Способ 3 – Помощник по обновлению до Windows 10
22. Способ 4 – скачать образ диска с Windows 10 (файл ISO) с сайта Microsoft
23. Способ 5 – Сервис TechBench by WZT
24. Способ 6 – Windows ISO Downloader
25. Способ 7 – Утилита Rufus

1. ^ Enrico Perla; Massimiliano Oldani (2010). A Guide to Kernel Exploitation; Attacking the Core. Elsevier Science. p. 277. ISBN 9781597494878.
2. ^ BHATT, PRAMOD CHANDRA P. (2019). AN INTRODUCTION TO OPERATING SYSTEMS : CONCEPTS AND PRACTICE (GNU/LINUX AND WINDOWS), FIFTH EDITION. PHI Learning Pvt. Ltd. p. 529. ISBN 9789387472884.
3. ^ Bill Blunden (2009). The Rootkit Arsenal; Escape and Evasion. Jones & Bartlett Learning. p. 142. ISBN 9781449661229.
4. ^ MSDN: Products Unavailable due to Java-related Settlement
5. ^ [1] Windows Driver Kit Version 7.1.0
6. ^ WDF co-installer issue
7. ^ Kraig Brockschmidt (2014). Programming Windows Store Apps with HTML, CSS, and JavaScript. Pearson Education. p. 1002. ISBN 9780735695702.
8. ^ Liu, Zhifeng; Zheng, Desheng; Wu, Xinlong; Chen, Jixin; Tang, Xiaolan; Ran, Ziyong (2021). VABox: A Virtualization-Based Analysis Framework of Virtualization-Obfuscated Packed Executables. International Conference on Artificial Intelligence and Security. Springer International Publishing. pp. 73–84. ISBN 9783030786212. We use Visual Studio 2017 and WDK for Windows 10, version 1809 for development.

Join the Chocolatey Team on our regular monthly stream where we discuss all things Community, what we do, how you can get involved and answer your Chocolatey questions.

Join the Chocolatey Team on our regular monthly stream where we put a spotlight on the most recent Chocolatey product releases. You’ll have a chance to have your questions answered in a live Ask Me Anything format.