Wdm integrated driver что это

Стратегия разработки аудио драйверов WDM

драйверы аудиоподсистемы основаны на модели Windows driver (WDM).

Чтобы создать звуковой драйвер WDM, выполните следующие действия.

сведения об архитектуре Windows и драйверах.

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

Узнайте об основах аудио драйверов WDM.

аудио драйверы в Windows версии операционной системы с Windows XP до Windows Vista соответствуют WDM и используют компоненты потоковой передачи ядра. Чтобы понять, какие решения по проектированию драйверов необходимо внести, см. раздел потоковая передача ядра, драйверы WDM Audio и общие сведения одрайверах WDM Audio.

Определите дополнительные решения по проектированию аудио драйвера WDM.

Сведения о том, как принимать решения по проектированию, см. в разделе пользовательские аудио драйверы, форматы звуковых данных и диапазоны данных. Если вам нужна помощь по принятию решения о типе звукового драйвера для изучения, см. раздел Пользовательский драйвер тип пользовательского драйвера дерево принятия решений.

Сведения об объектах обработки звука.

объекты обработки звука (APOs) обеспечивают настраиваемую обработку цифровых сигналов на основе Windows звуковых потоков. дополнительные сведения см. в разделе Windows Audio processing objects.

сведения о сборках, тестировании и отладке драйверов Windows.

Ознакомьтесь с примерами драйверов аудио в WDK.

Чтобы получить доступ к примерам аудио драйверов и ознакомиться с ними в WDK, см. статью примеры аудио драйверов.

Принятие решений по проектированию аудио драйвера WDM.

Разрабатывайте, создавайте, тестируйте и отлаживать аудио-драйвер WDM.

Создайте пакет драйверов для аудио-драйвера WDM.

Дополнительные сведения см. в разделе Создание пакета драйверов. Сведения о том, как установить звуковой адаптер, см. в статье Установка класса порта аудио адаптер.

Подпишите и распределите аудио драйвер WDM.

Последним этапом является подписывание (необязательно) и распространение драйвера. если драйвер соответствует стандартам качества, определенным для программы Windows сертификации, его можно распространить с помощью программы Microsoft Центр обновления Windows. Дополнительные сведения см. в разделе распространение пакета драйверов.

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

Источник

Простейший WDM-драйвер

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

Подготовка стенда

Установка необходимого ПО для написания простейшего драйвера

Настройка рабочего места

Установка DDK

Установка предельно проста. Единственное на что необходимо обратить внимание — это диалог, в котором Вам предлагается выбрать компоненты, которые будут установлены. Настоятельно рекомендую отметить всю документацию и примеры.

Установка и настройка Microsoft® Visual Studio 2005

Установка и настройка DDKWizard

Установка необходимого ПО для запуска драйверов

Постановка задачи

Задача: написать драйвер, который будет выводить в дебаг скан-коды нажатых клавиш и их комбинаций.

Немного теории

IRP — это структура, которая используется драйверами для обмена данными.

Отличия между верхними и нижними фильтрующими драйверами

Через верхние фильтрующие драйверы проходят все запросы, а это значит, что они могут изменять и/или фильтровать информацию, идущую к функциональному драйверу, ну и далее, возможно, к устройству.
Пример использования верхних фильтрующих драйверов:
Фильтр-хук драйвер, который устанавливает свою хук-функцию для системного драйвера IpFilterDirver, для отслеживания и фильтрации траффика. Такие драйверы используются в брандмауэрах.

Через нижние фильтрующие драйверы проходит меньше запросов потому что большинство запросов выполняет и завершает функциональный драйвер.

Проблемы синхронизации

В драйвере, который мы будем писать, есть несколько «проблемных» секций. Для нашего драйвера вполне достаточно использования ассемблерных вставок:

Префикс lock позволяет безопасно выполнить идущую за ним команду. Она блокирует остальные процессоры, пока выполняется команда.

Экшен

Для начала необходимо включить заголовочные файлы «ntddk.h», «ntddkbd.h»

Также необходимо описать структуру DEVICE_EXTENSION

Объект pLowerDO это объект устройства, который находится ниже нас в стеке. Он нужен нам для того чтобы знать кому дальше отправлять IRP-пакеты.
Еще для работы нашего драйвера нам нужна переменная, в которой будет храниться количество не завершенных запросов.

Начнем с функции, которая является главной точкой входа нашего драйвера.

theDriverObject – объект драйвера, содержит указатели на все необходимые операционной системе функции, которые мы должны будем инициализировать.
ustrRegistryPath – имя раздела в реестре, где хранится информация о данном драйвере.
Для начала необходимо объявить и обнулить переменные:

Далее, как я и писал выше, нужно инициализировать указатели на функции

Функция DispatchRead будет обрабатывать запросы на чтение. Она будет вызываться, когда нажата или отпущена клавиша клавиатуры.
Функция DriverUnload вызывается, когда драйвер уже не нужен и его можно выгрузить из памяти, или когда пользователь сам выгружает драйвер. В данной функции должна производиться «зачистка», т.е. освобождаться ресурсы, которые использовались драйвером, завершаться все незавершенные запросы и т.д.
Функция DispatchThru это функция-заглушка. Все что она делает это передача IRP-пакета следующему драйверу (драйверу который находится под нашим в стеке, т.е. pLowerDO из DEVICE_EXTENSION ).
Далее мы вызываем нашу функцию, для создания и установки нашего устройства в стек устройств:

Эта функция создает объект устройства, настраивает его и включает в стек устройств поверх \\Device\\KeyboardClass0

pKeyboardDevice – это объект устройсва, которое мы должны создать.
Вызываем IoCreateDevice для создания нового устройства

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

Функция IoAttachDevice внедряет наше устройство в стек. В pdx->pLowerDO будет храниться объект следующего (нижнего) устройства.

Далее разберем функцию DispatchRead с прототипом:

Данная функция будет вызываться операционной системой при нажатии или отпускании клавиши клавиатуры
Увеличиваем счетчик незавершенных запросов

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

где ReadCompletionRoutine наша функция.
Передаем IRP следующему драйверу:

Структура PKEYBOARD_INPUT_DATA используется для описания нажатой клавиши.

Проверяем, удачно завершен запрос или нет

Узнаем количество клавиш

И выводим каждую клавишу:

И не забываем уменьшать количество не обработанных запросов

Возвращаем статус запроса

Разберем функцию завершения работы. Прототип:

Извлекаем устройство из стека:

Проверяем есть незавершенные запросы или нет. Если мы выгрузим драйвер без этой проверки, при первом нажатии на клавишу после выгрузки будет БСоД.

Как запустить драйвер и просмотреть отладочную информацию

Для запуска драйвера я использовал утилиту KmdManager. Для просмотра отладочной информации использовалась утилита DbgView.

P. S. Статью писал давно, ещё на третьем курсе, сейчас уже почти ничего не помню. Но если есть вопросы, постараюсь ответить.
P. P. S. Прошу обратить внимание на комментарии, в частности на этот

Источник

Windows Driver Model

Windows Driver Model (WDM) – фреймворк для драйверов устройств (также известен как Win32 Driver Model и Windows NT Driver Model), был введен в Windows 98 и Windows 2000 для замены устаревшего VxD, который использовался в старых версиях Windows таких как Windows 95 и Windows 3.1.

Содержание

Обзор

Microsoft Windows Driver Model определяет унифицированную модель драйвера для операционных систем Windows 98, Windows 2000 и старше, стандартизируя требования и уменьшая количество кода, необходимое для написания драйвера. В соответствии с концепцией WDM, драйверы могут быть бинарно совместимы. Так, например, драйвер для платформы x86, написанный для Windows 98 может подойти и к Windows Me, и к Windows 2000, и даже к Windows Vista. WDM-драйвера спроектированы для прямой совместимости, поэтому такой драйвер может быть запущен на более поздней версии Windows, чем та, для которой он был изначально написан. Но это также означает, что драйвер не сможет использовать новые возможности новой версии WDM-фреймворка. WDM-драйвера, главным образом, обратно не совместимы. Это означает, что нет никаких гарантий, что такой драйвер запустится на версии Windows, более старой чем та, для которой он был написан. Например, Windows XP может использовать драйвер, написанный для Windows 2000, но этот драйвер не может использовать новые возможности, добавленные в Windows XP. Однако, драйвер, написанный для Windows XP, может работать в Windows 2000, а может и не работать.

Технология WDM была разработана для увеличения функциональности и облегчения написания драйверов для Windows. Хотя WDM в основном был разработан для бинарной совместимости и совместимости на уровне исходного кода между Windows 98 и Windows 2000, зачастую это не всегда ожидаемо и поэтому специфические драйвера разрабатываются для каждой операционной системы отдельно.

WDM драйвера предназначены в общем для расширения стандартных возможностеи основного драйвера.

VxD, WDM и Windows 98

Критика

Windows Driver Model, даже несмотря на значительные улучшения по сравнению с предшествующими ему VxD и Windows NT driver model, критикуется разработчиками драйверов [1], в основном по следующим причинам:

Было также много проблем из-за качества документации и примеров, предоставляемых Microsoft.

Из-за этих проблем Microsoft выпустила новый фреймворк, заменяющий WDM, названный Windows Driver Foundation, который включает в себя Kernel-Mode Driver Framework (KMDF) и User-Mode Driver Framework (UMDF). Windows Vista поддерживает оба стандарта: и WDM, и новый Windows Driver Foundation. KMDF также доступен для скачивания для Windows XP и даже Windows 2000, в то время, как UMDF доступен начиная только с Windows XP.

Источник

Writing WDM Drivers

This section discusses the Microsoft Windows Driver Model (WDM) architecture. This architecture started in Windows 2000 as an enhancement to previous Windows NT device drivers.

NoteВ В Drivers for versions of Windows NT-based operating systems before Windows 2000 are not supported, and you should update these drivers. The WDM architecture does not support drivers for non-Windows NT-based operating systems (such as Windows 98), and you should rewrite such drivers.

This section is divided into three parts:

Windows Driver Model describes the Windows Driver Model (WDM), including types of WDM drivers, device configuration, and WDM versioning.

Device Objects and Device Stacks describes device objects and device stacks. The section includes information about physical device objects (PDOs), functional device objects (FDOs), and filter device objects (filter DOs). Drivers are often built from a set of device objects that work together. This set of device objects is called a stack. Stacks can help you understand the flow of information to and from a driver and how different parts of the driver communicate internally.

Kernel-Mode Driver Components describes which routines you must implement to have a functional driver and which routines are optional.

A device driver is a set of software code that must integrate into the operating system. To complete this integration, you must write a set of handler routines in your driver that process calls from the operating system. These routines can be simple function calls, but many of them implement the processing of I/O request packets (IRPs), which facilitate communication between drivers and the operating system.

NoteВ В WDM drivers can also use the Windows Driver Frameworks (WDF) library to make some parts of a device driver easier to write. Specifically, kernel-mode drivers can use the Kernel-Mode Driver Framework (KMDF), which is part of WDF. For more information about KMDF for kernel-mode drivers, see Kernel-Mode Driver Framework Overview. Note that KMDF does not replace WDM. You must still understand many parts of WDM to write a KMDF driver.

Источник

Модель драйверов Windows (WDM)

В Windows 2000 была добавлена поддержка технологии Plug and Play, настроек электропитания и расширение модели драйверов Windows NT, названной моделью драйверов Windows (WDM). Windows 2000 и более поздние версии могут запускать драйверы, унаследованные у Windows NT 4, но, поскольку они не поддерживают технологию Plug and Play настройки электропитания, системы, запускающие эти драйверы, будут вынуждены ограничивать возможности в этих двух областях.

С точки зрения WDM, существуют драйверы трех типов:

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

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

В большинстве случаев драйверы фильтра, находящиеся на нижнем уровне, изменяют поведение устройства. Например, если устройство сообщает своему драйверу шины, что ему нужно 4 порта ввода-вывода, в то время как ему фактически нужно 16 портов ввода-вывода, функциональный драйвер фильтра для данного конкретного устройства может перехватить перечень аппаратных ресурсов, о котором драйвер шины сообщает диспетчеру PnP, и исправить количество портов ввода-вывода.

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

Источник