Windows kernel mode driver visual studio

Время на прочтение16 мин

Количество просмотров22K

Системные программисты, в частности под ОС 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.

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

Окно создания нового проекта

Окно создания нового проекта

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

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

Настройки при создании проекта

Настройки при создании проекта

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

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

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

Добавление файла в проект

Добавление файла в проект

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

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

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

Также не является обязательным примение макроса 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!");
}

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

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

Выбор платформы

Выбор платформы

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

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

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

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

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

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

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

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

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

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

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

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

Скопированный на целевую систему драйвер

Скопированный на целевую систему драйвер

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

Командная строка

Командная строка

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

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

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

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

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

Драйвер установлен и остановлен

Драйвер установлен и остановлен

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

Утилита DbgView

Утилита DbgView

Запустить драйвер можно командой 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. Открыть настройки виртуальной машины.

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

Главное окно VMWare

Главное окно VMWare

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

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

Окно настроек

Окно настроек

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

Окно редактирования устройств

Окно редактирования устройств

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

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

Настройки последовательного порта

Настройки последовательного порта

Отладка с использованием 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 Preview

Скриншот новой версии отладчика WinDbg Preview
Стартовое окно классического WinDbg

Стартовое окно классического WinDbg

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

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

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

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

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

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

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

  3. -y srv*C:\ProgramData\Microsoft\Symbols*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 автоматически загрузил исходный код драйвера.

Установленный breakpoint

Установленный breakpoint

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

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

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

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

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

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

Окно Visual Studio

Окно Visual Studio

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

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

Запуск конфигуратора устройств

Запуск конфигуратора устройств

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

В первую очередь необходимо открыть окно конфигуратора нажатием кнопки 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: \\.\pipe\Win10

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

Нажать Next.

Настройка отладчика

Настройка отладчика

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

Процесс настройки тестовой системы

Процесс настройки тестовой системы

Настройка тестовой системы почти закончена. На нее установлены средства 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 Kits\10\Testing\Runtimes. Если там содержатся поддиректории TAEF и WDTF, то все в порядке, а если только TAEF, как в моем случае, то нужно отдельно установить WDTF из пакета WDK версии, совпадающей с версией тестовой системы (напомню, у меня это Windows 10 1709). На тестовую систему из директории WDK\Installers необходимо скопировать файл 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, а среди них много полезных.

Подключенный отладчик

Подключенный отладчик
Содержимое окон Locals и memory

Содержимое окон Locals и memory

Еще один способ установки драйвера, который я использую — это Custom Command Line. Можно создать простой bat-скрипт, содержащий команды по установке и запуску драйвера. Visual Stuio позволяет указать дополнительные файлы, которые нужно скопировать на тестовую систему, однако эта функция не работает. Поэтому создаем файл createandstart.bat на диске C, который содержит две строки: SC CREATE HelloWorldDriver binPath= C:\DriverTest\Drivers\HelloWorldDriver.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.

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

Ручная настройка

Ручная настройка
Настройка отладчика

Настройка отладчика

Теперь на тестовой системе можно запустить драйвер командой 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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

The Build Tools for Windows Kernel-Mode Driver 10.0

The Windows Kernel-Mode Driver 10.0 build tools are a set of software development tools that allow you to create and debug kernel-mode drivers for the Windows operating system. Kernel-mode drivers are responsible for interacting with the Windows kernel and providing low-level access to hardware devices. The build tools include a compiler, a debugger, and a library of headers and libraries that you can use to develop your drivers.

This article provides an overview of the Windows Kernel-Mode Driver 10.0 build tools. It covers the following topics:

  • The components of the build tools
  • How to install the build tools
  • How to use the build tools to create and debug a kernel-mode driver

If you’re interested in developing kernel-mode drivers for Windows, this article is a good place to start.

Tool Version Download
Windows Driver Kit (WDK) 10.0.19041.0 Download
Windows Assessment and Deployment Kit (ADK) 10.0.19041.0 Download
Windows Driver Verfication Kit (DVRK) 10.0.19041.0 Download

The build tools for Windows kernel-mode driver 10.0 are a set of tools that you can use to build and test Windows kernel-mode drivers. These tools include:

  • The Windows Driver Kit (WDK): The WDK provides a set of tools, libraries, and documentation that you can use to develop Windows kernel-mode drivers.
  • The Windows Hardware Lab Kit (HLK): The HLK provides a set of tests that you can use to test your Windows kernel-mode drivers.
  • The Windows Driver Verfication Kit (DVCK): The DVCK provides a set of tests that you can use to verify the security of your Windows kernel-mode drivers.

The build tools for Windows kernel-mode driver 10.0 are available from the Microsoft Download Center.


Getting started with the build tools for Windows kernel-mode driver 10.0


To get started with the build tools for Windows kernel-mode driver 10.0, you need to install the WDK. You can install the WDK from the Microsoft Download Center.

Once you have installed the WDK, you can start developing your Windows kernel-mode driver. To do this, you can use the WDK’s tools and libraries to create a driver project. You can then use the WDK’s debugger to debug your driver.

**

Building and testing your Windows kernel-mode driver

Once you have developed your Windows kernel-mode driver, you need to build and test it. To build your driver, you can use the WDK’s build tools. You can then test your driver by using the WDK’s tests or by using your own tests.

**

Deploying your Windows kernel-mode driver

Once you have tested your Windows kernel-mode driver, you need to deploy it. To deploy your driver, you can use the WDK’s deployment tools. You can also use the Windows Hardware Dev Center to deploy your driver.

**

The build tools for Windows kernel-mode driver 10.0 are a powerful set of tools that you can use to develop, test, and deploy Windows kernel-mode drivers. By using these tools, you can create high-quality Windows kernel-mode drivers that are secure and reliable.

Installing the build tools for Windows kernel-mode driver 10.0

The build tools for Windows kernel-mode driver 10.0 are a set of tools that you can use to develop, build, and test kernel-mode drivers for Windows 10. The tools include the following:

  • The Windows Driver Kit (WDK)
  • The Windows Assessment and Deployment Kit (ADK)
  • The Windows Performance Toolkit (WPT)

You can install the build tools for Windows kernel-mode driver 10.0 from the Microsoft Download Center.

To install the build tools for Windows kernel-mode driver 10.0:

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Driver Kit.”
2. Click the link to download the latest version of the WDK.
3. Follow the instructions on the screen to install the WDK.

To install the Windows Assessment and Deployment Kit (ADK):

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Assessment and Deployment Kit.”
2. Click the link to download the latest version of the ADK.
3. Follow the instructions on the screen to install the ADK.

To install the Windows Performance Toolkit (WPT):

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Performance Toolkit.”
2. Click the link to download the latest version of the WPT.
3. Follow the instructions on the screen to install the WPT.

Once you have installed the build tools for Windows kernel-mode driver 10.0, you can start developing, building, and testing kernel-mode drivers for Windows 10.

For more information:

  • [Windows Driver Kit documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers/)
  • [Windows Assessment and Deployment Kit documentation](https://docs.microsoft.com/en-us/windows-hardware/test/)
  • [Windows Performance Toolkit documentation](https://docs.microsoft.com/en-us/windows-hardware/test/wpt/)

Prerequisites

Before you install the build tools for Windows kernel-mode driver 10.0, you need to have the following prerequisites:

  • A 64-bit version of Windows 10
  • The Microsoft Visual Studio 2019 or later
  • The Windows Driver Kit (WDK) 10.0
  • The Windows Assessment and Deployment Kit (ADK) 10.0
  • The Windows Performance Toolkit (WPT) 10.0

To install the prerequisites:

1. Install the latest version of the Microsoft Visual Studio.
2. Install the Windows Driver Kit (WDK) 10.0.
3. Install the Windows Assessment and Deployment Kit (ADK) 10.0.
4. Install the Windows Performance Toolkit (WPT) 10.0.

Once you have installed the prerequisites, you can install the build tools for Windows kernel-mode driver 10.0.

Installing the build tools

To install the build tools for Windows kernel-mode driver 10.0, follow these steps:

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Driver Kit.”
2. Click the link to download the latest version of the WDK.
3. Follow the instructions on the screen to install the WDK.

To install the Windows Assessment and Deployment Kit (ADK):

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Assessment and Deployment Kit.”
2. Click the link to download the latest version of the ADK.
3. Follow the instructions on the screen to install the ADK.

To install the Windows Performance Toolkit (WPT):

1. Go to the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51268) and search for “Windows Performance Toolkit.”
2. Click the link to download the latest version

Q: What are the build tools for Windows kernel-mode driver 10.0?

The build tools for Windows kernel-mode driver 10.0 are a set of software development tools that can be used to build Windows kernel-mode drivers. These tools include the Microsoft Visual Studio 2019 kernel debugger, the Windows Driver Kit (WDK), and the Windows Driver Foundation (WDF).

Q: What do I need to install the build tools for Windows kernel-mode driver 10.0?

To install the build tools for Windows kernel-mode driver 10.0, you will need the following:

  • A copy of Microsoft Visual Studio 2019
  • The Windows Driver Kit (WDK) for Windows 10
  • The Windows Driver Foundation (WDF)

**Q: How do I build a Windows kernel-mode driver with the build tools?

To build a Windows kernel-mode driver with the build tools, you will need to follow these steps:

1. Create a new project in Visual Studio.
2. Select the “Windows Driver” project type.
3. Specify the location of the Windows Driver Kit (WDK).
4. Specify the location of the Windows Driver Foundation (WDF).
5. Write the code for your driver.
6. Build the driver.
7. Install the driver on a Windows 10 system.

**Q: What are some common problems that I might encounter when building a Windows kernel-mode driver?

Some common problems that you might encounter when building a Windows kernel-mode driver include:

  • Errors in the driver code.
  • Problems with the Windows Driver Kit (WDK).
  • Problems with the Windows Driver Foundation (WDF).

**Q: Where can I get help if I encounter problems building a Windows kernel-mode driver?

If you encounter problems building a Windows kernel-mode driver, you can get help from the following resources:

  • The Microsoft Windows Driver Development Center
  • The Microsoft Windows Driver Kit (WDK) forums
  • The Microsoft Windows Driver Foundation (WDF) forums

**Q: What are the benefits of using the build tools for Windows kernel-mode driver 10.0?

The build tools for Windows kernel-mode driver 10.0 provide a number of benefits, including:

  • They allow you to build Windows kernel-mode drivers for Windows 10.
  • They include a number of tools that can help you to debug and troubleshoot your drivers.
  • They are supported by Microsoft.

**Q: Are there any other resources that I can use to learn more about building Windows kernel-mode drivers?

Yes, there are a number of other resources that you can use to learn more about building Windows kernel-mode drivers. These include:

  • The Microsoft Windows Driver Development Center
  • The Microsoft Windows Driver Kit (WDK) documentation
  • The Microsoft Windows Driver Foundation (WDF) documentation
  • The Microsoft Windows Driver Development Blog

    In this blog post, we have discussed the build tools for Windows Kernel Mode Driver 10.0. We have covered the installation process, the different tools available, and how to use them to build a kernel mode driver. We have also provided some tips and tricks to help you get started.

We hope that this blog post has been helpful. If you have any questions or feedback, please feel free to leave a comment below.

Here are some key takeaways from this blog post:

  • The build tools for Windows Kernel Mode Driver 10.0 can be installed from the Microsoft Download Center.
  • The different tools available include the Driver Development Kit (DDK), the Windows Driver Kit (WDK), and the Windows Assessment and Deployment Kit (ADK).
  • To build a kernel mode driver, you must first create a driver project in Visual Studio.
  • You can then use the WDK to build and test your driver.
  • For more information on building kernel mode drivers, please refer to the Microsoft documentation.

Author Profile

Hatch, established in 2011 by Marcus Greenwood, has evolved significantly over the years. Marcus, a seasoned developer, brought a rich background in developing both B2B and consumer software for a diverse range of organizations, including hedge funds and web agencies.

Originally, Hatch was designed to seamlessly merge content management with social networking. We observed that social functionalities were often an afterthought in CMS-driven websites and set out to change that. Hatch was built to be inherently social, ensuring a fully integrated experience for users.

Now, Hatch embarks on a new chapter. While our past was rooted in bridging technical gaps and fostering open-source collaboration, our present and future are focused on unraveling mysteries and answering a myriad of questions. We have expanded our horizons to cover an extensive array of topics and inquiries, delving into the unknown and the unexplored.

Latest entries

Распознавание голоса и речи на C#

UnmanagedCoder 05.05.2025

Интеграция голосового управления в приложения на C# стала намного доступнее благодаря развитию специализированных библиотек и API. При этом многие разработчики до сих пор считают голосовое управление. . .

Реализация своих итераторов в C++

NullReferenced 05.05.2025

Итераторы в C++ — это абстракция, которая связывает весь экосистему Стандартной Библиотеки Шаблонов (STL) в единое целое, позволяя алгоритмам работать с разнородными структурами данных без знания их. . .

Разработка собственного фреймворка для тестирования в C#

UnmanagedCoder 04.05.2025

C# довольно богат готовыми решениями – NUnit, xUnit, MSTest уже давно стали своеобразными динозаврами индустрии. Однако, как и любой динозавр, они не всегда могут протиснуться в узкие коридоры. . .

Распределенная трассировка в Java с помощью OpenTelemetry

Javaican 04.05.2025

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

Шаблоны обнаружения сервисов в Kubernetes

Mr. Docker 04.05.2025

Современные Kubernetes-инфраструктуры сталкиваются с серьёзными вызовами. Развертывание в нескольких регионах и облаках одновременно, необходимость обеспечения низкой задержки для глобально. . .

Создаем SPA на C# и Blazor

stackOverflow 04.05.2025

Мир веб-разработки за последние десять лет претерпел коллосальные изменения. Переход от традиционных многостраничных сайтов к одностраничным приложениям (Single Page Applications, SPA) — это. . .

Реализация шаблонов проектирования GoF на C++

NullReferenced 04.05.2025

«Банда четырёх» (Gang of Four или GoF) — Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес — в 1994 году сформировали канон шаблонов, который выдержал проверку временем. И хотя C++ претерпел. . .

C# и сети: Сокеты, gRPC и SignalR

UnmanagedCoder 04.05.2025

Сетевые технологии не стоят на месте, а вместе с ними эволюционируют и инструменты разработки. В . NET появилось множество решений — от низкоуровневых сокетов, позволяющих управлять каждым байтом. . .

Создание микросервисов с Domain-Driven Design

ArchitectMsa 04.05.2025

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

Многопоточность в C++: Современные техники C++26

bytestream 04.05.2025

C++ долго жил по принципу «один поток — одна задача» — как старательный солдатик, выполняющий команды одну за другой. В то время, когда процессоры уже обзавелись несколькими ядрами, этот подход стал. . .

Microsoft always does significant changes in windows kernel and the way to communicate with kernel in every new release and make it difficult to follow the old method of doing certain stuff. Over that, the scattered and less interactive official documentation is always painful to follow. Same goes with windows driver development and loading of driver. The old methods available online doesn’t work anymore due to introduction of multiple new features and handling tools like code signing etc.

Since I myself have faced a lot of difficulties in finding a correct way to compile and load the windows driver. I have decided to write a quick guide to help others to do that job in less than 10 minutes for windows 10(excluding downloading and installation time).

Installation

Note: I am using visual studio 2019 for this tutorial.

  • For kernel driver development it is obvious that you need to have Visual Studio installed on your machine. Inside visual studio installer you need to select the «Desktop development with C++» checkbox(other workload packages are optional according to your need).

Note: Don’t forget to check the package named MSVC’s latest version with Specter-mitigation( as shown in last 3rd checkbox in right list of above image) rather than the one without specter-mitigation. Otherwise while compiling your driver, you will get a dependency missing error .

  • Install SDK: link
  • Install WDK from here.

Setup and development

Since we have already installed the dependencies by now. We can create our first test driver. For this, follow these steps.

  • Open visual studio and click on «Create a new project«

  • Select the Driver option in project type.
  • Select the Kernel Mode Driver(KMDF). Enter the details on the next prompt.

If you can’t see the Driver option then you must have not installed one of the component mentioned in Installation section. Also verify that the sdk and wdk package have same version and try to install the WDK extension again from %programfiles(x86)%\Windows Kit\{WDK version}\Vsix\{Vs Version}\WDK.exe location.

  • Add a new file by right clicking on source files in upper right box. Then Add-> New item ->C++ file. Give the name filename with extension .c.
  • Choose correct target architecture.

  • Now start the coding

Let’s put a minimal code here that will just print a string on driver loading and unloading.

#include <ntddk.h>
#include <wdf.h>
DRIVER_INITIALIZE DriverEntry;
EVT_WDF_DRIVER_DEVICE_ADD KmdfHelloWorldEvtDeviceAdd;



_Use_decl_annotations_
VOID
DriverUnload(
)
{
    KdPrint(("This is driver Exit \r\n"));
}


NTSTATUS
DriverEntry(
    _In_ PDRIVER_OBJECT     DriverObject,
    _In_ PUNICODE_STRING    RegistryPath
)
{
    UNREFERENCED_PARAMETER(DriverObject);
    UNREFERENCED_PARAMETER(RegistryPath);
    // NTSTATUS variable to record success or failure
    NTSTATUS status = STATUS_SUCCESS;
    KdPrint(("This is driver entry \r\n"));
 
    return status;
}

DriverEntry is the entry point, that will going to execute when you will load the driver.

DriverUnload is the exit function that will execute when you unload the driver.

  • Compile the code by clicking Build->Build Solution.

Configuration

Configuration is the most important part to make driver loading work. Usually it is recommended to do the testing of driver on other machine then the development one, but we will do everything in same machine because that’s what most people do on their initial development phase(also we are too lazy to use two machines).

  • Turn on loading of our test signed drivers.

bcdedit /set testsigning on

  • Turn on kernel debugging.

bcdedit -debug on

  • Create a DWORD value IHVDRIVER under HKLM\SYSTEM\CCS\Control\Session Manager\Debug Print Filter and set the value to 0xf.
  • Reboot the machine.

Deployment/Loading

To load our driver we will be using devcon tool that is part of WDK. devcon require following driver related file in the same directory.

  • .sys — driver file
  • .inf — configuration file
  • .cat -catalog file

They must have been already generated after you have build the driver.

In case there is no catalog file created, you can use inf2cat to generate one. You can use following command for this Inf2Cat /driver:C:\MyDriver /os:2000,XP_X86,XP_X64,Server2003_X86,Server2003_X64,Vista_X86,Vista_X64. The tool will look for a .cer certificate file in the same folder which should be created while building the driver. Refer here for more info.

you can run the following devcon command from the folder having all above mentioned file to load the driver

& 'C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon.exe' install .\KMDFDriver.inf Root\MyDriver

Use admin privilege for above command.

Root\mydriver is your hardware id that will be present in the .inf file.

[Standard.NTamd64]
%KMDFDriver1.DeviceDesc%=KMDFDriver_Device, Root\MyDriver ; TODO: edit hw-id

To unload the driver you can use following command

& 'C:\Program Files (x86)\Windows Kits\10\Tools\x64\devcon.exe' remove Root\MyDriver

Debug logs

You can check the debug logs using dbgview which is part of sysinternal suite. Run it as admin and check following options(you may require to do a restart to make it work) .

Now next time when you install the driver, make sure dbgview is running in the background. After loading, you will see the string from DriverEntry in dbgview.

Deploying/Loading a filter driver

Most of the time our driver is just a mini filter driver which doesn’t require the use of devcon to get loaded. For minifilter drivers follow below steps after build

  • Open filter’s ini file and update all the TODO values with the values mentioned in the comment.For example: updating Class and ClassGuid

  • In the same file update Instance1.Altitude with the value 361000 or refer following link for other possible values range.
  • Install the .ini file with right click-> install
  • load the driver with net install drivername and unload using net stop drivername

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Cold fear не запускается на windows 10
  • Не запускается средство создания носителя windows 10
  • Блокировка телеметрии windows 10
  • Год предшествующий году выпуска oc windows
  • Как убрать прозрачность меню пуск в windows 10