Wdm driver что это
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.
Обзор аудио драйверов WDM
аудио-драйверы WDM (WDM) используют компоненты потоковой передачи ядра (KS), которые работают в режиме ядра и являются частью операционной системы.
производители оборудования должны принять несколько решений по проектированию, прежде чем начинать разработку устройства аудио с использованием Windows.
Первое решение — необходимость разработки звукового устройства, для которого требуется пользовательский драйвер, предоставленный поставщиком. Windows содержит поддержку операционной системы для устройств PCI, USB и IEEE 1394, которые соответствуют рекомендациям по архитектуре Microsoft универсального аудио-архитектуры (UAA). Поставщику не требуется предоставлять пользовательский драйвер для устройства, совместимого с UAA.
Однако если требуется пользовательский звуковой драйвер, предоставленный поставщиком, поставщик должен выбрать, должен ли драйвер работать совместно с драйвером системы Портклс (Portcls.sys) или системным драйвером класса Австреам (Ks.sys). портклс и австреам являются частью Windows операционной системы. Портклс является верным выбором для большинства звуковых адаптеров. Дополнительные сведения о Портклс см. в разделе Введение в класс порта. Дополнительные сведения о Австреам см. в разделе Обзор австреам.
При проектировании пользовательского драйвера адаптера, использующего Портклс, устройства на аудио адаптере становятся доступными для приложений, использующих Ваверт. Дополнительные сведения см. в статье Введение в драйвер порта ваверт.
Два дополнительных решения предполагают, как представлять топологию адаптера и закреплять диапазоны данных в звуковых приложениях. Топология — это логическая карта путей к данным и управляющих узлов в цепи адаптеров. Диапазоны данных определяют форматы данных, которые устройства могут поддерживать в потоках Wave и MIDI. Оба решения влияют на то, как устройства звукового адаптера отображаются в приложениях.
При выполнении всех упомянутых выше решений поставщик оборудования должен оценить ценность улучшений производительности относительно затрат на их реализацию. другой вопрос заключается в том, можно ли выполнить определенное решение для работы с несколькими продуктами в семействе Windows. В этом разделе приводятся общие сведения об этих проблемах, а также ссылки на более подробную документацию по конкретным темам.
Общие сведения о драйверах WDM Audio
Службы потоковой передачи ядра (KS) поддерживают обработку потоков данных в режиме ядра для аудио и других типов непрерывного носителя. По сути, поток проходит обработку, так как он проходит по пути к данным, содержащему некоторое количество обрабатывающих узлов. Набор связанных узлов объединяется в группу, образуя Фильтр KS, который представляет собой независимый блок функций потоковой обработки. Более сложные функции могут быть созданы с помощью модульного представления каскадом нескольких фильтров для формирования графа фильтра.
Типичная плата звукового адаптера может содержать звуковые устройства для воспроизведения волнового потока с помощью набора динамиков, преобразования звукового сигнала из микрофона в поток звукозаписи и синтезирования звука из потока MIDI. Драйвер адаптера может заключить каждое из этих звуковых устройств в фильтр KS, который предоставляется операционной системе. Операционная система подключает фильтры к другим фильтрам для формирования графов фильтров, обрабатывающих звуковые потоки от имени программ приложений.
Фильтры KS соединяются друг с другом через свои ПИН-коды. ПИН-код в фильтре аудио можно рассматривать как аудиоразъемы. Клиент создает экземпляр входного или выходного ПИН-кода для фильтра, когда клиенту требуется направить поток данных в этот фильтр или из него. В некоторых контекстах термин » ПИН-код » и » поток » могут быть взаимозаменяемы.
Выходной контакт вышестоящего фильтра соединен с входным закреплением подчиненного фильтра. Поток данных из выходного ПИН-кода должен иметь формат данных, который может принимать входной ПИН-код. Буферизация данных обычно требуется для смягчения несовпадений в скорости, с которой закрепление вывода создает данные, а входной ПИН-код использует их.
Фильтр KS реализуется как объект драйвера режима ядра, который инкапсулирует некоторое количество связанных функций обработки потока. Функциональность может быть реализована в программном обеспечении или оборудовании. В этой модели звуковой адаптер можно просмотреть как набор аппаратных устройств, а драйвер адаптера — для каждой из этих устройств в качестве отдельного фильтра.
Драйвер адаптера предоставляет набор фабрик фильтров для звуковой системы. Каждая фабрика фильтров поддерживает создание экземпляров фильтров определенного типа:
Если адаптер содержит одно или несколько устройств, которые похожи или идентичны, драйвер группирует фильтры для этих устройств вместе в одну фабрику фильтров.
Если адаптер содержит несколько типов устройств, эти устройства представляются несколькими различными фабриками фильтров.
Фильтр KS предоставляет набор фабрик закрепления для звуковой системы. Каждая фабрика закрепления может создавать экземпляры ПИН-кодов определенного типа. Если фильтр может предоставить один или несколько ПИН-кодов, одинаковых или одинаковых в функции, фильтр группирует эти контакты в одну фабрику. Например, фильтр, выполняющий микширование звука, может иметь одну фабрику закрепления, которая может создавать экземпляры одного выходного ПИН-кода и вторую фабрику закрепления, которая может создавать экземпляры нескольких входных ПИН-кодов.
службы KS создаются на основе WDM. Обратите внимание, что термин Фильтр KS должен отличаться от драйвера фильтратермина, который является другой концепцией WDM. Драйвер фильтра находится в стеке драйвера WDM и может перехватывать и изменять пакеты запросов ввода-вывода (IRP), распространяемые через стек. Драйверы фильтров верхнего и нижнего уровней располагаются выше и ниже драйвера функции соответственно. В этом разделе Фильтр терминов ссылается на фильтр KS, а не на драйвер фильтра, если не указано иное. Дополнительные сведения о драйверах фильтров см. в разделе Типы драйверов WDM.
В этом разделе рассматриваются следующие вопросы.
Простейший 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. Прошу обратить внимание на комментарии, в частности на этот
Стратегия разработки аудио драйверов 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. Дополнительные сведения см. в разделе распространение пакета драйверов.
Ниже приведены основные шаги. Дополнительные действия могут быть необходимы в зависимости от потребностей конкретного драйвера.