Поделиться через

Перенос драйвера из UMDF 1 в UMDF 2

  • Статья

В этом разделе описывается перенос драйвера User-Mode Driver Framework (UMDF) 1 в UMDF 2. Вы можете начать с драйвера UMDF 1, который использует файлы Sources/Dirs (не проект Visual Studio), или преобразовать драйвер UMDF 1, содержащийся в проекте Visual Studio. Результатом будет проект драйвера UMDF 2 в Visual Studio. Драйверы UMDF 2 работают как в Windows 10 для настольных версий (Домашняя, Pro, Корпоративная и Для образовательных учреждений), так и в Windows 10 Mobile.

Пример драйвера Echo — это пример драйвера, который был перенесен из UMDF 1 в UMDF 2.

Приступая к работе

Чтобы начать, откройте новый проект драйвера в Visual Studio. Выберите шаблон Драйвер visual C++->Windows-WDF-User>> Mode Driver (UMDF 2). Visual Studio открывает частично заполненный шаблон, включающий заглушки для функций обратного вызова, которые должен реализовать драйвер. Этот новый проект драйвера станет основой драйвера UMDF 2. Используйте пример UMDF 2 Echo в качестве руководства по типу кода, который следует представить.

Затем просмотрите существующий код драйвера UMDF 1 и определите сопоставления объектов. Каждый COM-объект в UMDF 1 имеет соответствующий объект WDF в UMDF 2. Например, интерфейс IWDFDevice сопоставляется с объектом устройства WDF, который представлен дескриптором WDFDEVICE. Почти все предоставляемые платформой методы интерфейса в UMDF 1 имеют соответствующие методы в UMDF 2. Например, IWDFDevice::GetDefaultIoQueue сопоставляется с WdfDeviceGetDefaultQueue.

Аналогичным образом функции обратного вызова, предоставляемые драйвером, имеют эквиваленты в двух версиях. В UMDF 1 соглашение об именовании интерфейсов, предоставляемых драйвером (за исключением IDriverEntry), — этообратный вызовIObject Xxx, а в UMDF 2 соглашение об именовании для предоставляемых драйвером подпрограмм — EvtObjectXxx. Например, метод обратного вызова IDriverEntry::OnDeviceAdd сопоставляется с EvtDriverDeviceAdd.

Драйвер реализует функции обратного вызова как в UMDF 1, так и в 2, но способ, которым драйвер предоставляет указатели на обратные вызовы, отличается. В UMDF 1 драйвер реализует методы обратного вызова в качестве членов интерфейсов, предоставляемых драйвером. Драйвер регистрирует эти интерфейсы в платформе при создании объектов платформы, например путем вызова IWDFDriver::CreateDevice.

В UMDF 2 драйвер предоставляет указатели на предоставляемые драйвером функции обратного вызова в структурах конфигурации, таких как WDF_DRIVER_CONFIG и WDF_IO_QUEUE_CONFIG.

Управление временем существования объекта

Драйверы, использующие UMDF 1, должны реализовать подсчет ссылок, чтобы определить, когда безопасно удалять объекты. Так как платформа отслеживает ссылки на объекты от имени драйвера, драйверу UMDF 2 не нужно подсчитывать ссылки.

В UMDF 2 каждый объект платформы имеет родительский объект по умолчанию. При удалении родительского объекта платформа удаляет связанные дочерние объекты. Когда драйвер вызывает метод создания объекта, например WdfDeviceCreate, он может принять родительский элемент по умолчанию или указать пользовательский родительский элемент в WDF_OBJECT_ATTRIBUTES структуре. Список объектов платформы и их родительских объектов по умолчанию см. в разделе Сводка по объектам платформы.

Инициализация драйвера

Драйвер UMDF 1 реализует интерфейс IDriverEntry . В методе обратного вызова IDriverEntry::OnDeviceAdd драйвер обычно:

  • Создает и инициализирует экземпляр объекта обратного вызова устройства.
  • Создает объект устройства платформы, вызывая IWDFDriver::CreateDevice.
  • Настраивает очереди устройства и соответствующие им объекты обратного вызова.
  • Создает экземпляр класса интерфейса устройства, вызывая IWDFDevice::CreateDeviceInterface.

Драйвер UMDF 2 реализует DriverEntry и EvtDriverDeviceAdd. В подпрограмме DriverEntry драйвер UMDF 2 обычно вызывает WDF_DRIVER_CONFIG_INIT для инициализации структуры WDF_DRIVER_CONFIG драйвера. Затем эта структура передается в WdfDriverCreate.

В функции EvtDriverDeviceAdd драйвер может выполнять некоторые из следующих действий:

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

При создании проекта драйвера в Visual Studio новый проект содержит INX-файл. При сборке драйвера Visual Studio компилирует INX-файл в INF-файл, который можно использовать в составе пакета драйвера.

Хотя INF-файл для драйвера UMDF 1 должен содержать идентификатор класса драйвера, в INF-файле для драйвера UMDF 2 не требуется идентификатор DriverCLSID.

Кроме того, несмотря на то, что драйвер UMDF 1 должен ссылаться на совместный установщик в СВОЕМ INF-файле, в INF-файле UMDF 2 ссылки на constaller не требуются. Хотя ссылка на coinstaller может отображаться в INF-файле для драйвера UMDF 2, она не является обязательной.

Хранение контекста устройства

В UMDF 1 драйвер обычно сохраняет контекст устройства в созданном драйвером объекте обратного вызова, например путем указания частных членов класса объектов обратного вызова устройства. Кроме того, драйвер UMDF 1 может вызвать метод IWDFObject::AssignContext для регистрации контекста в объекте платформы.

В UMDF 2 платформа выделяет пространство контекста на основе необязательной структуры WDF_OBJECT_ATTRIBUTES , которая предоставляется драйвером при вызове метода создания объекта. После вызова метода create объекта драйвер может вызвать WdfObjectAllocateContext один или несколько раз, чтобы выделить дополнительное пространство контекста для определенного объекта. Шаги, которые драйвер UMDF 2 должен использовать для определения структуры контекста и метода доступа, см. в разделе Пространство контекста объекта платформы.

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

Для отладки драйвера UMDF 2 вы будете использовать расширения в Wdfkd.dll вместо Wudfext.dll. Дополнительные сведения о расширениях в Wudfext.dll см. в разделе Сводка расширений отладчика в Wdfkd.dll.

В UMDF 2 можно также получить дополнительные сведения об отладке драйверов с помощью средства записи трассировки (IFR), как описано в статье Использование средства записи трассировки в драйверах KMDF и UMDF 2. Кроме того, можно использовать собственный самописец платформы (IFR). См . раздел Использование средства ведения журнала событий платформы.

начало работы с помощью UMDF

Контекстное пространство объекта платформы

Журнал версий UMDF

Объекты платформы