Вот как можно изменять параметры (показаны в [ ... ] ), согласно вашем ожиданиям:

• -Online : указывает, что действие выполняется в операционной системе, которая работает на локальном компьютере.
• -All : включает отображение информации о стандартных драйверах. Если Вы не укажете этот параметр, то будут перечислены только сторонние драйверы. Например, PS C:\> Get-WindowsDriver –Online -All
• -Driver : указывает.inf файл или папку, содержащую.inf файлы драйверов, о котором Вы хотите получить подробную информацию. При указании папки.inf файлов, которые не являются действительными пакетами драйверов, параметр игнорируется.
  Например, PS C:\> –Driver "OEM1.inf
• -LogLevel : задает максимальное значение выходного уровня в журналах. Уровень протоколирования по умолчанию – 3.

Допустимые значения:

• 1 = только ошибки
• 2 = ошибки и предупреждения
• 3 = ошибки, предупреждения и информация
• 4 = вся информация, указанная выше, и отладочный вывод

Например, PS C:\> Get-WindowsDriver –Path "c:\offline" –LogLevel "1"

• -LogPath : указывает полный путь и имя файла журнала. Если не задано, по умолчанию - %WINDIR%\Logs\Dism\dism.log.
  Например, PS C:\> Get-WindowsDriver –Path "c:\offline" –LogPath "C:\DriversInfo"
• -Path : Вы можете изменить этот параметр, чтобы указать полный путь к корневому каталогу автономного образа Windows с драйверами, которые загружаются.

  Например, чтобы получить получает подробные сведения о USB.inf драйвере включенном в образ Windows, используйте эту команду:

  PS C:\> Get-WindowsDriver –Path "c:\offline" –Driver "c:\drivers\Usb\Usb.inf"
• -ScratchDirectory : этот параметр указывает временный каталог, который будет использован при извлечении файлов для использования при техническом обслуживании. Этот каталог должен существовать локально. Если не указан, будет использоваться Windows\%Temp% (подкаталог со случайным шестнадцатеричным именем при каждом запуске системы dism ). Элементы каталога удаляются после каждой операции.
  Например, PS C:\> -ScratchDirectory "C:\Temp"
• -SystemDrive :это необходимый параметр, чтобы найти загрузчик bootmgr файлов , если эти файлы находятся на разделе, из которого вы запускаете команду.

  Например, чтобы найти загрузчик bootmgr фалов на С: , когда вы работаете в PowerShell с диска D: , используйте этот командлет:

  PS C:\> Get-WindowsDriver –Online -All -SystemDrive "C:"

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

Вот и пришло время второй статьи из цикла о написании драйверов под Windows. Сейчас я тебя немного расстрою: в предыдущей статье я обещала, что в этой мы приступим собственно к практике. Но данная статья это, скорее, «полупрактика». Глупо «с места в карьер» бросаться разрабатывать драйвера режима ядра
(так как, если ты не забыл, в данном цикле мы разбираем именно этот тип драйверов), хотя бы поверхностно не изучив особенности и приёмы программирования в режиме ядра, что мы и сделаем в первой части этой статьи. Ну а во второй мы наконец — то разберём структуру настоящего драйвера под Windows
(Legacy и немного WDM) : его основные функции, их взаимодействие, а также параметры, принимаемые ими. Так что к третьей статье этого цикла ты уже, надо думать, будешь основательно подготовлен к написанию своего первого драйвера. Начинаем.

Особенности и приёмы программирования в режиме ядра

Программирование в режиме ядра имеет массу особенностей, для прикладников очень непривычных, а для новичков довольно сложных. Во-первых, у режима ядра своё, отличное от такового в пользовательском режиме, API. Кроме того, для кода, выполняющегося в режиме ядра, имеет очень большое значение его уровень IRQL, так как приложениям, выполняющимся на высоких уровнях IRQL, недоступны многие функции, к которым имеют доступ приложения низких IRQL уровней, и наоборот. Всё это необходимо учитывать.
Во-вторых, в режиме ядра есть свои дополнительные описатели типов. Полный их список можно найти в заголовочном файле ntdef.h. Его содержание примерно таково:

typedef unsigned char USHAR
typedef unsigned short USHORT
typedef unsigned long ULONG
…………

Зачем это нужно? Ну, во-первых, для красоты… тьфу, для унификации стиля классических C — типов данных и нововведённых — таких, как WCHAR
(двухбайтный Unicode символ), LARGE_INTEGER (который, на самом деле, является объединением) и т.д. А также для унификации исходников для 32 — разрядных платформ и надвигающихся 64 — разрядных.

В исходниках драйверов часто встречаются макроопределения
IN, OUT, OPTIONAL. Что они означают? А ровным счётом ничего, и введены они только для повышения удобочитаемости исходника. OPTIONAL обозначает необязательные параметры, IN — параметры, передаваемые внутрь функции, например, OUT — соответственно, наоборот. А вот IN OUT означает, что параметр передаётся внутрь функции, а затем возвращается из неё обратно.

Есть изменения и в типах возвращаемых значений функций. Ты наверняка знаешь, что C-ишные функции либо не возвращают значения
(void), либо возвращают значение определённого типа
(char, int etc). При программировании драйверов ты столкнёшься с ещё одним типом — NT_STATUS. Этот тип включает в себя информацию о коде завершения функции
(определение этого типа можно посмотреть в файле ntdef.h). NT_STATUS является переопределённым типом long integer. Неотрицательные значения переменных этого типа
соответствуют успешному завершению функции, отрицательные — наоборот
(файл NTSTATUS содержит символьные обозначения всех кодов возврата). Сообщение об удачном завершении имеет код 0 и символьное обозначение STATUS_SUCCESS. Остальные коды возврата, соответствующие разнообразным вариантам ошибок, транслируются в системные коды ошибок и передаются вызывающей программе. Для работы с типом NT_STATUS существует несколько макроопредений
(описанные в файле ntdef.h), например NT_SUCCESS(), проверяющий код возврата на успешность завершения.

Функции драйвера, за исключением DriverEntry (главная процедура драйвера, подробнее см. во второй части статьи), могут называться как угодно, тем не менее, существуют определённые «правила хорошего тона» при разработке драйверов, в том числе и для именования процедур: например, все функции, относящиеся к HAL, желательно предварять префиксом HAL и т.д. Сама Microsoft практически постоянно следует этому правилу. А имена типов данных и макроопределения в листингах DDK написаны сплошь заглавными буквами. Советую тебе поступать также при разработке своих драйверов. Это и в самом деле во много раз повышает удобство работы с листингом.

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

Начнём с функций для работы с памятью, а для начала поговорим собственно об устройстве и работе с памятью в Windows. Единое 4-х гигабайтное адресное пространство памяти Windows
(я имею в виду 32-х разрядные версии Windows) делится на две части: 2 гигабайта для пользовательского пространства и 2 гигабайта для системного. 2 гигабайта системного пространства доступны для всех потоков режима ядра. Системное адресное пространство делится на следующие части:

Видов адресов в режиме ядра три: физические
(реально указывающие на область физической памяти), виртуальные
(которые перед использованием транслируются в физические), и логические
(используемые HAL уровнем при общении с устройствами; он же и отвечает за работу с такими адресами). Функции режима ядра, отвечающие за выделение и освобождение виртуальной памяти, отличаются от таковых в пользовательском режиме. Также, находясь на уровне режима ядра, становится возможным использовать функции выделения и освобождения физически непрерывной памяти. Разберём все эти функции поподробнее.

1) PVOID ExAllocatePool (уровень IRQL, на котором может выполняться эта функция — < DISPATCH_LEVEL) — выделяет область памяти. Принимает два параметра: параметр
(POOL_TYPE) , в котором содержится значение, означающее, какого типа область памяти нужно выделить: PagedPool — страничная, NonPagedPool — нестраничная
(в этом случае функцию можно вызвать с любого IRQL уровня). Второй параметр
(ULONG) — размер запрашиваемой области памяти. Функция возвращает указатель на выделенную область памяти, и NULL, если выделить память не удалось.

2) VOID ExFreePool (IRQL (PVOID) — указатель на освобождаемую область памяти. Если высвобождается нестраничная память, то данная функция может быть вызвана с
DISPATCH_LEVEL. Возвращаемое значение — void.

3) PVOID MmAllocateContiguousMemory (IRQL==PASSIVE_LEVEL) — выделяет физически непрерывную область памяти. Принимает два параметра. Первый параметр
(ULONG) — размер запрашиваемой области памяти, второй — параметр
(PHYSICAL_ADDRESS), означающий верхний предел адресов для запрашиваемой области. Возвращаемое значение: виртуальный адрес выделенной области памяти или NULL
(при неудаче).

4) VOID MmFreeContiguousMemory (IRQL==PASSIVE_LEVEL) — освобождает физически непрерывную область памяти. Принимает единственный параметр
(PVOID) — указатель на область памяти, выделенную ранее с использованием функции MmAllocateContiguousMemory. Возвращаемое значение —
void.

5) BOOLEAN MmIsAddressValid (IRQL<=DISPATCH_LEVEL) — делает проверку виртуального адреса. Принимает параметр
(PVOID) — виртуальный адрес, нуждающийся в проверке. Функция возвращает TRUE, если адрес «валидный»
(т.е. присутствует в виртуальной памяти), и FALSE — в противном случае.

6) PHYSICAL_ADDRESS MmGetPhysicalAddress (IRQL — любой) — определяет физический адрес по виртуальному. Принимает параметр
(PVOID), содержащий анализируемый виртуальный адрес. Возвращаемое значение — полученный физический адрес.

Основные функции для работы с памятью рассмотрели, перейдём к таковым для работы с реестром. Сначала поговорим о функциях доступа к реестру, предоставляемых диспетчером ввода — вывода, потом о драйверных функциях прямого доступа к реестру, а затем о самом богатом по возможностям и удобству семействе функций для работы с реестром —
Zw~.

Драйверные функции, предоставляемые диспетчером ввода — вывода.

1) IoRegisterDeviceInterface — данная функция регистрирует интерфейс устройства. Диспетчер ввода — вывода создаёт подразделы реестра для всех зарегистрированных интерфейсов. После этого можно создавать и хранить в этом подразделе нужные драйверу параметры с помощью вызова функции IoOpenDeviceInterfaceRegistryKey, которая возвращает дескриптор доступа к подразделу реестра для зарегистрированного интерфейса устройства.

2) IoGetDeviceProperty — данная функция запрашивает из реестра установочную информацию об устройстве.

3) IoOpenDeviceRegistryKey — возвращает дескриптор доступа к подразделу реестра для драйвера или устройства по указателю на его объект.

4) IoSetDeviceInterfaceState — с помощью данной функции можно разрешить или запретить доступ к зарегистрированному интерфейсу устройства. Компоненты системы могут получать доступ только к разрешённым интерфейсам.

Драйверные функции для прямого доступа к реестру.

1) RtlCheckRegistryKey — проверяет, существует ли указанный
подраздел внутри подраздела, переданного первым параметром. Что и каким
образом передавать в первом параметре — в рамках статьи всё не перечислить, отсылаю к ntddk.h и wdm.h. Если существует — возвращается
STATUS_SUCCESS.

2) RtlCreateRegistryKey — создаёт подраздел внутри раздела реестра, указанного вторым параметром. Далее — всё то же самое, что и у
RtlCheckRegistryKey.

3) RtlWriteRegistryValue — записывает значение параметра реестра. Первый параметр — куда пишем, второй — в какой подраздел
(если его нет, то он будет создан), а третий — какой параметр создаём.

4) RtlDeleteRegistryValue — удаляет параметр из подраздела. Параметры те же самые, что и у RtlWriteRegistryValue
(только с необходимыми поправками, конечно).

5) RtlQueryRegistryValues — данная функция позволяет за один вызов получить значения сразу нескольких параметров указанного подраздела.

И напоследок функции для работы с реестром семейства
Zw~.

1) ZwCreateKey — открывает доступ к подразделу реестра. Если такового нет — создаёт новый. Возвращает дескриптор открытого объекта.

2) ZwOpenKey — открывает доступ к существующему подразделу реестра.

3) ZwQueryKey — возвращает информацию о подразделе.

4) ZwEnumerateKey — возвращает информацию о вложенных подразделах уже открытого ранее подраздела.

5) ZwEnumerateValueKey — возвращает информацию о параметрах и их значениях открытого ранее подраздела.

6) ZwQueryValueKey — возвращает информацию о значении параметра в открытом ранее разделе реестра. Полнота возвращаемой информации определяется третьим параметром, передаваемым функции, который может принимать следующие значения
(дополнительные разъяснения не требуются, так как они имеют «говорящие» имена):
KeyValueBasicInformation, KeyValuePartialInformation и KeyValueFullInformation.

7) ZwSetValueKey — создаёт или изменяет значение параметра в открытом ранее подразделе реестра.

8) ZwFlushKey — принудительно сохраняет на диск изменения, сделанные в открытых функциями ZwCreateKey и ZwSetValueKey подразделах.

9) ZwDeleteKey — удаляет открытый подраздел из реестра.

10) ZwClose — закрывает дескриптор открытого ранее подраздела реестра, предварительно сохранив сделанные изменения на диске.

Практически все вышеперечисленные функции для работы с реестром должны вызываться с уровня IRQL
PASSIVE_LEVEL.

Думаю, пока достаточно. Конечно, у всех вышеперечисленных функций есть масса нюансов в применении. Да и вообще функций режима ядра — великое множество, их ничуть не меньше, чем в пользовательском режиме. Но моя задача была не рассказать обо всех API — функциях режима ядра
(что даже в рамках цикла невозможно сделать), а продемонстрировать отличия функций режима ядра, от таковых в пользовательском режиме, и хоть немного рассказать о нюансах их применения
(взять, к примеру, то, что в пользовательском режиме не имеет значения, в потоке какого приоритета будет выполняться приложение: оно будет иметь такой же полный доступ ко всем API функциям пользовательского режима, как и любые другие приложения; на уровне ядра, как ты только что, убедился, это не так). Ну а за более или менее полным списком и описанием всех этих API — функций советую обратиться к библии Гарри Нэббета.
Ну вот и всё, теперь ты готов к разговору о структуре драйвера, который мы сейчас и начнём.

Структура драйвера

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

Входная точка любого драйвера — функция DriverEntry
(по поводу названий вообще всех функций — смотри соглашение в первой части статьи), которая фактически играет ту же самую роль для драйвера, что и main для проги на C. Эта функция вызывается при загрузке драйвера
(неважно, загружается ли он динамически или при запуске системы). Данная функция выполняет некоторые действия, нужные для нормальной работы драйвера
(например, регистрирует в специальном массиве адреса всех остальных функций драйвера, чтобы диспетчер ввода — вывода мог вызывать их по этим адресам). Если это не WDM драйвер, то в этой функции происходит локализация обслуживаемого оборудования, выделение и/или подтверждение используемых аппаратных ресурсов, выдача видимых для системы имён всем найденным обслуживаемым устройствам и т.д. WDM драйвера эту работу перекладывают на функцию AddDevice. Функция DriverEntry может вызываться с уровня IRQL == PASSIVE_LEVEL. Функция возвращает значение типа NTSTATUS, и принимает два параметра: адрес объекта драйвера
(PDRIVER_OBJECT) и путь в реестре к подразделу драйвера
(PUNICODE_STRING). Получив от диспетчера ввода — вывода указатель на структуру DRIVER_OBJECT драйвер должен заполнить в ней некоторые поля:

1) Поле DriverUnload — для регистрации собственной функции Unload, вызываемой при выгрузке драйвера. Подробнее о ней.
Эта функция вызывается только при динамической выгрузке драйвера
(т.е. происшедшей не в результате завершения работы системы). Legacy драйвера в этой функции выполняют полное освобождение всех занятых драйвером системных ресурсов. WDM драйвера выполняют такое освобождение в функции RemoveDevice при удалении каждого устройства
(если драйвер обслуживает несколько устройств). Функция Unload вызывается с уровня IRQL PASSIVE_LEVEL, принимает единственный параметр
(PDRIVER_OBJECT) — указатель на объект драйвера, и возвращает
void.

2) Поле DriverStartIo — для регистрации собственной функции
StartIo. Вкратце, регистрация функции StartIo нужна для участия в System Queuing — создании очередей необработанных запросов системными средствами, в отличие от DriverQueuing — когда то же самое реализуется средствами самого драйвера.

3) Поле AddDevice в подструктуре DriverExtension — для регистрации WDM драйвером своей процедуры
AddDevice.

4) Поле MajorFunction — для регистрации драйвером точек входа в свои рабочие процедуры.

Бывают ситуации, когда при первоначальной загрузке драйвер не может до конца окончить процедуру инициализации
(например, если необходимы какие-либо системные объекты или другие драйвера, ещё не загруженные). В этом случае драйвер регистрирует свою процедуру для завершения инициализации позднее. Регистрация этой процедуры выполняется вызовом IoRegisterDriverReinitialization с уровня IRQL PASSIVE_LEVEL, принимающей следующие параметры: указатель на объект драйвера
(PDRIVER_OBJECT), указатель на процедуру реинициализации, предоставляемую драйвером
(PDRIVER_REINITIALIZE) и контекстный указатель, получаемый регистрируемой функцией при вызове, и возвращающей
void.

Если выгрузка драйвера происходит в результате завершения работы системы, то функция Unload не вызывается. Это понятно: при выключении системы можно не заботиться об освобождении памяти и т.д. Поэтому вызывается функция Shutdown, которая просто предоставляет драйверу возможность оставить устройство в приемлемом состоянии покоя.

Может случиться так, что твоему драйверу необходимо будет получить управление при крахе системы. В этом случае ему нужно зарегистрировать callback процедуру Bugcheck. Если драйвер правильно выполнил регистрацию этой функции, то он будет вызван во время исполнения crash процесса.

Я перечислила основные функции драйвера для его загрузки и выгрузки. Теперь перейдём к рабочим процедурам драйвера.
Поговорим о следующих рабочих процедурах: обслуживания ввода — вывода
(включающих в себя процедуры передачи данных и обслуживания прерываний), callback процедуры для синхронизации доступа к объектам и некоторые другие.

Все драйверы должны иметь обработчик CreateDispatch, обрабатывающий пользовательский запрос CreateFile. Если драйверу нужно обрабатывать пользовательский запрос CloseHandle, то он должен иметь обработчик
CloseDispatch.

Перейдём к процедурам передачи данных. Это обработчики пользовательских запросов ReadFile, WriteFile и
DeviceIoControl.

Процедуру StartIo я уже рассмотрела, поэтому перейдём к процедуре обслуживания прерываний
(ISR — Interrupt Service Routine, напоминаю на всякий случай). Данная процедура вызвается диспетчером прерываний ядра
(Kernel`s Interrupt Dispatcher) при каждой генерации прерывания устройством, и она обязана полностью обслужить это прерывание.

Теперь о callback процедурах сихронизации доступа к объектам. Для начала разберёмся, в чём различия принципов сихронизации доступа к объектам в пользовательском и ядерном режимах. Например, в пользовательском режиме, если какой — либо поток обратился к объекту, уже занятому другим потоком, то он
(первый поток) запросто может быть заблокирован до лучших времён. Как ты сам понимаешь, в режиме ядра такая внеплановая «заморозка» потоков неприемлема, поэтому и применяется другая технология сихронизации. И заключается она в следующем. Когда какой-либо поток обращается к объекту, уже занятому другим потоком, то он оставляет свой запрос в очереди запросов. Если драйвер предварительно зарегистрировал особую callback функцию, то диспетчер ввода — вывода при освобождении
требуемого ресурса, уведомит об этом драйвер, вызвав callback — функцию. Таким образом, обеспечивается гарантия ответа на любой запрос к ресурсу, даже если он
(ответ) будет состоять только в том, чтобы уведомить о задержке в обработке и помещении запроса в очередь. Функции, это реализующие: IoAllocateController
(использующаяся для синхронизации доступа к контроллеру), AdapterControl
(использующаяся для синхронизации доступа к DMA каналам
(чаще всего)) и SynchCritSection (использующаяся для корректного обращения к ресурсам; точнее — эта функция позволяет коду с низким уровнем IRQL сделать работу при уровне DIRQL устройства без опасения возникновения конфликтов с ISR).

Также можно упомянуть ещё таймерные процедуры
(нужные для драйверов, выполняющих точный отсчёт временных интервалов; обычно реализуется с использованием IoTimer
(но не всегда)), процедуру IoCompletion (позволяющую WDM драйверу, работающему внутри многослойной драйверной структуры, получать уведомление о завершении обработки IRP запроса, направленного к драйверу нижнего уровня) и CancelRoutine
(если драйвер зарегистрирует эту callback процедуру при помощи вызова IoSetCancelRoutine, то диспетчер ввода — вывода сможет уведомить его об удалении IRP запросов, находящихся в ожидании обработки, что может понадобиться диспетчеру, если пользовательское приложение, инициировавшее эти IRP запросы, неожиданно завершит свою работу после снятия задачи диспетчером задач
(прошу прощения за необходимую тавтологию)).

Ну вот и всё, мы закончили обзор структуры драйвера и основных его процедур. Примеры их практического применения
(а также некоторых других функций) ты увидишь в третьей, заключительной статье этого цикла, в которой мы напишем свой полноценный Legacy драйвер.

Заключение

Уфф, наконец-то мы покончили со скучной теорией. В этой статье ты узнал про некоторые приёмы программирования в режиме ядра, изучил структуру драйвера и его основные функции. Теперь ты полностью подготовлен
(на сей раз уже окончательно) к написанию своего первого
(или двадцать первого — не знаю) полноценного Legacy драйвера под Windows. Это мы проделаем в заключительной части моего рассказа о программировании драйверов под Windows. А пока что слегка отдохнём. Да не облысеют твои пятки!

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

Как получить список драйверов

В Windows есть очень простая встроенная утилита, которая показывает список всех установленных в системе драйверов. Достаточно открыть командную строку и выполнить вот такую команду:

Появится список установленных драйверов с датами выпуска. Если требуются более подробные сведения – например, путь к файлу драйвера, можно добавить параметр /V:

При желании можно также дополнить его параметром |more, чтобы информация выводилась построчно по нажатию :

driverquery /V |more

Есть и другие полезные опции. Можно, например, сохранить список в файл CSV или посмотреть, у каких драйверов есть подписи. Узнать весь набор опций можно с помощью параметра /?:

Использование InstalledDriversList

Если вы не любитель командной строки, можно воспользоваться бесплатной утилитой (). Замечательно, что разработчик не прикладывает к своим программам никакого дополнительного мусора типа браузерных панелей и шпионских приложений. Мы давние фанаты NirSoft.

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

Зеленым значком отмечены драйверы, которые в данный момент используются системой, а желтым – установленные, но не активированные. Красная отметка означает, что с драйвером какие-то проблемы – это очень пригодится при диагностике.

    Команда DriverQuery позволяет администратору просмотреть список установленных драйверов устройств. Отображаемые данные могут быть представлены в виде списка, таблицы, или CSV (Comma-Separated Values - значения, разделённые запятыми).

Формат командной строки:

driverquery ]]]

Параметры командной строки:

/S система - IP-адрес или имя подключаемого удаленного компьютера.

/U [домен\]пользователь - имя пользователя для учетной записи, в контексте которой должна выполняться эта команда.

/P [пароль] - пароль для этого пользовательского контекста.

/FO формат - формат выводимых данных. Допустимые значения - таблица (TABLE), список (LIST), значения с разделителями (CSV).

/NH - не отображать заголовки столбцов в выходных данных, представляемых в формате "TABLE" и "CSV".

/SI - отображение информации о цифровых подписях драйверов.

/V - максимальный уровень подробностей в отображаемой информации. Несовместим с параметром /SI

. /? - отобразить справку по использованию команды.

Примеры использования: DRIVERQUERY - отобразить список драйверов на локальном компьютере. По умолчанию, информация представляется в табличном формате:

Модуль                   Название                                   Тип драйвера         Дата ссылки
============ ====================== ============= ======================

1394ohci             1394 OHCI-совместимый          Kernel                   14.07.2009 2:51:59
ACPI                   Драйвер Microsoft ACPI              Kernel                   14.07.2009 2:11:11
AcpiPmi             ACPI Power Meter Drive             Kernel                   14.07.2009 2:16:36

Колонки таблицы списка драйверов:

Модуль содержит имена файлов драйверов (без расширения.sys).
Название - краткое описание драйвера.
Тип драйвера - тип Kernel - драйвер ядра, File System - драйвер файловой системы.
Дата ссылки - дата создания (модификации) файла драйвера. Можно считать временем установки или обновления драйвера.

Для получения списка драйверов в виде текстового файла, можно воспользоваться перенаправлением вывода в команде:

DRIVERQUERY > C:\DriverList.txt - вывести список драйверов в файл C:\DriverList.txt

Для отображения строк, содержащих конкретный признак, можно использовать команду DriverQuery в цепочке с командой FIND:

driverquery | FIND /I "wmi" - отобразить информацию о драйвере, в имени которого есть строка символов "wmi" . Ключ /I команды FIND используется для игнорирования различий в строчных и заглавных символах.

driverquery | FIND "2012" - отобразить список драйверов, установленных в 2012 году.

DRIVERQUERY /FO CSV /SI - вывести список в формате CSV с отображением цифровых подписей драйверов.

DRIVERQUERY /S 192.168.1.1 /U Mydomain\admin /P MyPassword /FO LIST - вывести информацию об установленных драйверах в формате "список" на компьютере с IP-адресом 192.168.1.1. При подключении к удаленной системе используется имя пользователя admin в домене Mydomain с паролем MyPassword

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

1. Общие сведения о драйверах устройств в системе Windows.

Естественно, каждая операционная система имеет собственную архитектуру и свои особенности функционирования драйверов. Но практически во всех современных ОС можно выделить следующие особенности, характерные для работы подсистемы ввода-вывода:

Фактически, пользовательские программы либо системные утилиты не могут напрямую обращаться к аппаратуре, используя порты ввода-вывода, DMA либо подобные низкоуровневые механизмы напрямую. Этот факт следует из самой идеологии защищенного режима современных ОС: все программы пользователя и часть ОС работают в 3-м кольце защиты компьютера (наименее привилегированном). При этом любая команда обращения к порту из данной программы может быть замаскирована и повлечет за собой аппаратное исключение (Exception). Напрямую к аппаратуре может обратится программа, работающая в самом приоритетном, 0-м кольце защиты.

В настоящее время практически все устройства используют технологию автоматического распределения ресурсов (портов ввода-вывода, запросов на прерывания и т.п.) - Plug and Play (PnP). Когда новое устройство, например, та же звуковая карта, будет добавлена в систему, ей будут выделены те ресурсы, которые в данный момент свободны - незадействованные линии запросов на прерывание (IRQ), свободные адреса портов ввода-вывода. Поэтому драйвер изначально "не знает", какие именно адреса портов и IRQ ему будут выделены - эти данные будут различными для разных компьютеров. При этом задача распределения ресурсов ложится на ОС.

В ОС Windows, как и в большинстве современных ОС, драйвера управляют буквально всем: работой с аппаратурой, поддержкой файловых систем различных типов, сетевых протоколов и т.п. Это дает определенные преимущества и делает систему более гибкой: например, для того, чтобы ОС стала "понимать" другой сетевой протокол, нужно всего лишь установить соответствующий драйвер. 1.1 Система ввода-вывода в Windows.

На данный момент наиболее распространены два семейства ОС Windows: Windows NT, куда относятся Windows NT, 2000, XP, и Windows 9x (Win 95, 98, ME). При этом отмечается тенденция к отмиранию ветки 9х, хотя такие системы будут встречаться еще достаточно долго. Каждая ветка использует свою архитектуру ядра и подсистемы ввода-вывода. Поэтому естественно, написание драйверов для этих систем должно отличаться.

В Windows 9x долгое время использовались.vxd–драйвера. Эта модель драйверов начинает свою историю еще с Windows 3.1. Для.vxd–драйверов сохранилась совместимость "снизу вверх": т.е. драйвер, написанный под Windows 3.1, будет нормально работать и под Windows 95, а может быть, и 98. Функции драйверов.vxd используются как Win32, так и Win16 приложениями.

В Windows NT 4.0 появилась своя архитектура драйверов. Она ставила перед собой цели повышения устойчивости работы драйвера, переносимости с одной платформы на другую, поддержки многопроцессорности т.п. Вместе с тем архитектура драйверов Windows NT 4.0 была, что называется, "сырой" и недоработанной, хотя и очень перспективной. С выходом систем Win98 и Win2000 появилась новая архитектура драйверов - WDM (Windows Driver Model). Она развилась из архитектуры драйверов Windows NT 4.0 с небольшими изменениями. WDM – драйвера с равным успехом могут быть использованы как в Win 98, так и в Win 2000.

Система Win 98 состоит как бы из двух слоев: User Mode (режим пользователя) и Kernel Mode (режим ядра). В режиме пользователя функционируют пользовательские приложения. Они работают в 3-м кольце защиты; каждая программа работает в своем виртуальном адресном пространстве. Для каждого DOS или Windows–приложения создается своя виртуальная машина (Virtual Machine, VM), задачей которой является виртуализация аппаратуры компьютера для данного приложения. Т.е. каждое приложение считает, что вся оперативная память и все остальные аппаратные ресурсы принадлежат только ему и приложение может обратиться к ним в любой момент. Ядро ОС содержи диспетчер виртуальных машин (Virtual Machine Manager, VMM). Задача VMM - корректно разрешать конфликты, возникающие при доступе к ресурсам системы из разных VM. Ядро, VMМ, виртуальные машины и драйвера виртуальных устройств (Virtual Device Drivers), естественно, работают в режиме ядра (Kernel Mode).

Рис. 1. Подсистема ввода-вывода Win 98.

В Windows 98 обработка запросов на ввод-вывод от приложений DOS и от старых Win16–приложений отличается от обработки запросов новых Win32–приложений. Для DOS–приложений создается своя виртуальная машина (DOS virtual machine), Win 16 и Win32 - приложения используют виртуальную машину Windows (System Virtual Machine). Обычно, когда приложение запрашивает операцию ввода-вывода (например, вызывает функцию API ReadFile - чтение из файла), этот запрос поступает в одну из системных DLL (в нашем случае - kernel32.dll). Оттуда запрос на операцию с внешним устройством передается сразу системным драйверам. Такая организация запроса Приложение?dll?Драйвер получила наибольшее распространение.

Система Windows 2000 имеет другую архитектуру, отличную от Win98. Это обусловлено повышенными требованиями к надежности, защите и переносимости этой системы (теоретически, Win2000 - переносимая система, и существуют реализации Win2000 под системы Alpha, MIPS и др.). В настоящее время именно благодаря этим особенностям Win2000 завоевывает все большую популярность, поэтому стоит рассмотреть особенности ее архитектуры подробнее.

Рис. 2 - главные компоненты Windows2000.

Окружение Win2000 включает компоненты, которые работают в режиме пользователя (User mode) и в режиме ядра (Kernel mode). В режиме пользователя работают подсистема защиты, подсистема Win32-архитектуры (обеспечивает стандартные API - вызовы Windows), подсистема POSIX (обеспечение кроссплатформенности). В режиме ядра работают все основные компоненты системы: диспетчер ввода-вывода (I/O manager), диспетчер конфигурации (Configuration Manager), подсистема PnP, диспетчер управления энергопотреблением (Power Manager), диспетчер памяти (Memory Manager) и прочие жизненно необходимые службы. Драйвера в Win2000 включены в подсистему ввода-вывода. При этом драйвера тесно взаимодействуют практически со всеми компонентами ядра. Драйвера взаимодействуют с аппаратурой при помощи Hardware Abstraction Level, HAL (уровень абстракции аппаратуры). HAL - программный компонент ядра Win2000, который обеспечивает интерфейс ядра (в том числе и некоторых драйверов) с аппаратурой. Т.к. Win2000 – платформенно независимая система (уже сейчас есть версии Win2000 для процессоров Alpha и RISC), то HAL избавляет ядро от непосредственного общения с кэшем, прерываниями, шинами ввода-вывода и большинством прочих устройств, оставляя эту работу драйверам, специально написанным для данной системы. Таким образом, ядро системы представляется набором отдельных изолированных модулей с четко определенными внешними интерфейсами.

Все драйвера NT имеют множество стандартных методов драйвера, определенных системой, и, возможно, несколько специфических методов, определенных разработчиком. Драйвера Windows 2000 используют архитектуру WDM (Windows Driver Model). В Windows 2000 драйвера бывают следующих типов:

Kernel mode drivers (драйверы режима ядра). Основной тип драйвера. Такие драйвера используются для решения общих задач: управление памятью, шинами, прерываниями, файловыми системами, устройствами хранения данных и т.п.

Graphics drivers (драйверы видеокарт). Как правило, создаются одновременно с самой видеокартой. Очень сложны в написании, так как должны учитывать множество противоречивых требований и поддерживать множество стандартов. Скорее всего, вам не потребуется создавать ничего подобного.

Multimedia drivers (мультимедиа-драйверы). Драйверы для:

Аудиоустройств - считывание, воспроизведение и компрессия аудиоданных.

Устройств работы с видео - захват и компрессия видеоданных.

Позиционных устройств - джойстики, световые перья, планшеты и пр.

Network drivers (сетевые драйвера) - работа с сетью и сетевыми протоколами на всех уровнях.

Virtual DOS Drivers - драйверы для виртуальных машин MS-DOS. Постепенно переходят в раздел рудиментарных.

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

Device drivers (драйвера устройств), такие как драйвер клавиатуры или дисковый драйвер, напрямую общающийся с дисковым контроллером. Эти драйвера также называются драйверами низкого уровня, т. к. они находятся в самом низу цепочки драйверов Windows NT.

Intermediate drivers (промежуточные драйвера), такие как драйвер виртуального или зеркального диска. Они используют драйверы устройств для обращения к аппаратуре.

File system drivers (FSDs). Драйверы файловых систем, таких как FAT, NTFS, CDFS, для доступа к аппаратуре используют Intermediate drivers и Device drivers.

Драйвера Windows 2000 должны удовлетворять следующим требованиям:

Переносимы с одной платформы на другую.

Конфигурируемые программно.

Всегда прерываемые.

Поддерживающие мультипроцессорные платформы.

Объектно-ориентированные.

Поддерживать пакетный ввод-вывод с использванием I/O request packets (IRPs, запросы ввода-вывода).

Поддерживать асинхронный ввод-вывод.

Система ввода-вывода Windows 2000 имеет следующие особенности:

Менеджер ввода-вывода NT представляет интерфейс для всех kernel-mode драйверов, включая драйвера физических устройств, драйвера логических устройств и драйвера файловых систем.

Операции ввода-вывода послойные. Это значит, что вызов, сделанный пользователем, проходит через несколько драйверов, генерируя несколько пакетов запросов на ввод-вывод и "по пути" обращаясь к необходимым драйверам. К примеру, когда приложение пытается открыть файл, подсистема ввода-вывода Windows делает запрос к драверу файловой системы; драйвер файловой системы обращается к промежуточному драйверу; и лишь промежуточный драйвер обращается непосредственно к винчестеру. Такая архитектура построения системы существенно повышает ее гибкость и снижает общую стоимость разработки.

Разработчик драйвера обязан реализовать несколько стандартных функций, к которым будет обращаться диспетчер ввода-вывода (I/O manager).

msinfo32.exe (Сведения о системе) Местонахождение: C:Program FilesCommon FilesMicrosoft SharedMSInfo Описание: System InformationПрограмма Сведения о системе собирает и отображает данные о конфигурации системы как для локальных, так и для удаленных компьютеров. Сюда входит информация о конфигурации

Общие сведения о Проводнике Windows Vista Для просмотра содержимого папок используется программа Проводник. Ее не нужно запускать специально – достаточно открыть любую папку, и ее содержимое будет отображено в окне Проводника. Вы можете также встретить термин окно папки,

Основные сведения об устройствах и драйверах Современный компьютер состоит из большого количества различных устройств, от правильной работы которых зависит его работа в целом. Чтобы операционная система могла использовать устройство, для него необходим драйвер –

Глава 1 Windows Vista. Общие сведения Начнем знакомство с новой операционной системой компании Microsoft – Windows Vista. С 2001 года, то есть появления Windows XP, Microsoft не обновляла линейку клиентских операционных систем. Появление новой, значительно переработанной версии Windows Vista ожидалось с