Использование NuMega DriverStudio для написания WDM-драйверов - Александр Тарво

Если же Вы разрабатываете драйвер, который не управляет каким-либо устройством или это устройство не является PnP — необходимо просто установить драйвер стандартными средствами Windows: Пуск→Настройка→Панель управления→Установка оборудования. Когда Windows выведет полный список типов устройств и спросит, какое устройство Вы хотите установить, выберите свой тип устройства.

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

После того, как драйвер будет установлен, нужно будет проверить его функционирование. Запустите скомпилированный файл test_xdsp.exe с параметрами test_xdsp r 32 (команда прочитать 32 байта из устройства). Должно появиться сообщение, похожее на это:

C:XDSPexeobjchki386>Test_XDSP.exe r 32

Test application Test_XDSP starting…

Device found, handle open.

Reading from device – 0 bytes read from device (32 requested).

–, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –, –,

–, –, –, –, –, –,

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

C:…ProjectsXDSPdrvexeobjchki386>Test_XDSP.exe r 32

Test application Test_XDSP starting…

ERROR opening device: (2) returned from CreateFile

Exiting…

 — то приложение не смогло установить связь с драйвером. Следует попробовать переустановить драйвер.

2.3 Наращивание функциональных возможностей драйвера.

Рассмотрим подробно текст драйвера, сгенерированного DriverWizard и внесем в него необходимые изменения.

В проекте пристствуют всего два класса:

XDSP

 класс драйвера;

XDSPDevice

 класс устройства.

Также есть несколько глобальных функций и переменных:

PNPMinorFunctionName — возвращает строку с текстовым названием кода функции IOCTL. Эта функция используется при отладке, когда надо перевести числовое значение кода IOCTL в строку с его названием.

POOLTAG DefaultPoolTag('PSDX') — используется совместно с BoundsChecker для отслеживания возможных переполнений буфера и утечек памяти.

KTrace t("XDSPdrv") — глобальный объект трассировки драйвера. Этот объект используется для вывода сообщений трассировки при работе драйвера. Использование объекта трассировки аналогично использованию класса iostream в С++. Вывод отладочных сообщений производится при помощи оператора <<. Примеры использования объекта трассировки неоднократно встречаются в тексте драйвера, например:

t << "m_bBreakOnEntry loaded from registry, resulting value: [" << m_bBreakOnEntry << "]n";

В данном примере объект трассировки используется для вывода строки "m_bBreakOnEntry loaded from registry, resulting value: [" и значения логической переменной m_bBreakOnEntry. Все сообщения трассировки можно прочитать в отладчике SoftIce.

Начнем анализ текста драйвера с класса XDSP (класс драйвера). В строке 31 при помощи макроса DECLARE_DRIVER_CLASS декларируется класс драйвера XDSP. Далее следует метод DriverEntry, который вызывается при инициализации драйвера:

NTSTATUS XDSPdrv::DriverEntry(PUNICODE_STRING RegistryPath)

//В строке RegistryPath содержится ключ реестра, в котором система хранит информацию о драйвере.

{

 //Далее выводится трассировочное сообщение, информирующее о вызове метода DriverEntry:

 t << "In DriverEntryn";

 //После этого драйвер создает объект Params класса KRegistryKey и считывает данные из

 //реестра для этого драйвера:

 KRegistryKey Params(RegistryPath, L"Parameters");

 //Далее производится проверка на успех:

 if ( NT_SUCCESS(Params.LastError()) ) {

  //Текст, заключенный в макрос препроцессора DBG будет откомпилирован только в отладочной версии

  //драйвера.

#if DBG

  ULONG bBreakOnEntry = FALSE;

  // Читается значение переменной BreakOnEntry реестра:

  Params.QueryValue(L"BreakOnEntry", &bBreakOnEntry);

  // Если она принимает значение true,то инициировать точку останова в отладчике.

  if (bBreakOnEntry) DbgBreakPoint();

#endif

  //Загрузить остальные параметры реестра.

  LoadRegistryParameters(Params);

 }

 m_Unit = 0;

 //Вернуть успех

 return STATUS_SUCCESS;

}

Метод LoadRegistryParameters зaгружает из реестра все остальные параметры, необходимые для драйвера. Впрочем, в нашем драйвере таковых нет, и поэтому функция не выполняет никаких полезных действий (просто загружает значение переменной m_bBreakOnEntry).

void XDSPdrv::LoadRegistryParameters(KRegistryKey &Params) {

 m_bBreakOnEntry = FALSE;

 Params.QueryValue(L"BreakOnEntry", &m_bBreakOnEntry);

 t << "m_bBreakOnEntry loaded from registry, resulting value: [" << m_bBreakOnEntry << "]n";

}

На этом заканчивается секция инициализации драйвера. Далее следует метод AddDevice. Он вызывается, когда система обнаруживает устройство, за которое отвечает драйвер (обычно это происходит при загрузке драйвера). В метод ситема передает указатель на физический объект устройства (Physical Device Object, PDO). Этот объект представляет собой некий блок информации о физическом устройстве, который используется ОС. Данный метод создает объект устройства XDSPDevice. С точки зрения системы, создается функциональный объект устройства (Functional Device Object, FDO).

NTSTATUS XDSPdrv::AddDevice(PDEVICE_OBJECT Pdo) {

 t << "AddDevice calledn";

 //Здесь вызывается конструктор класса XDSPDevice.

 XDSPdrvDevice* pDevice = new(

  static_cast(KUnitizedName(L"XDSPdrvDevice", m_Unit)),

  FILE_DEVICE_UNKNOWN,

  static_cast(KUnitizedName(L"XDSPdrvDevice", m_Unit)),

  0,

  DO_DIRECT_IO)

 XDSPDevice(Pdo, m_Unit);

 //m_Unit – количество таких устройств в системе.

 if (pDevice == NULL) //Не удалось создать объект устройства. Похоже, произошла какая-то ошибка.

 {

  t << "Error creating device XDSPdrvDevice" << (ULONG) m_Unit << EOL;

  return STATUS_INSUFFICIENT_RESOURCES;

 }

 //Получить статус создания устройства.

 NTSTATUS status = pDevice->ConstructorStatus();

 if ( !NT_SUCCESS(status) ) //Похоже, устройство создано, но неудачно; произошла ошибка.

 {

  t << "Error constructing device XDSPdrvDevice" << (ULONG) m_Unit << " status " << (ULONG) status << EOL;

  delete pDevice;

 } else {

  m_Unit++; //Устройство создано удачно

 }

 //Вернуть статус устройства.

 return status;

}

Все. Работа объекта драйвера на этом окончена. Как мы можем видеть, объект драйвера практически не выполняет каких-либо функций управления аппаратурой, но он жизненно необходим для правильной инициализации драйвера. В нашем случае НЕ ТРЕБУЕТСЯ вносить какие-либо изменения в текст, сформированный DriverWizard.

Основным классом драйвера является класс устройства. Класс устройства XDSPdrvDevice является подклассом класса KpnpDevice. Конструктор получает два параметра: указатель на PDO и номер драйвера в системе.

XDSPdrvDevice::XDSPdrvDevice(PDEVICE_OBJECT Pdo, ULONG Unit) : KPnpDevice(Pdo, NULL) {

 t << "Entering XDSPdrvDevice::XDSPdrvDevice (constructor)n";

 //Здесь проверяется код ошибки, которую вернул конструктор суперкласса. В случае

 //успешного создания объекта базового класса значение переменной m_ConstructorStatus

 //будет NT_SUCCESS.

 if ( ! NT_SUCCESS(m_ConstructorStatus) ) {

  //Ошибка в создании объекта устройства

  return;

 }

 //Запомнить номер драйвера

 m_Unit = Unit;

 //Инициализация устройства нижнего уровня. В роли устройства нижнего уровня в нашем

 //драйвере выступает PDO. Но в случае стека драйверов в качестве устройства нижнего

 //уровня может выступать объект устройства другого драйвера.

 m_Lower.Initialize(this, Pdo);

 // Установить объект нижнего уровня для нашего драйвера.

 SetLowerDevice(&m_Lower);

 // Установить стандартную политику PnP для данного устройства.

 SetPnpPolicy();

}

Порядок вызова методов m_Lower.Initialize(this, Pdo), SetLowerDevice(&m_Lower) и SetPnpPolicy() является жизненно важным. Его нарушение может вызвать серьезные сбои в работе драйвера. Не стоит редактировать текст конструктора, сгенерированный DriverWizard.

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