Драйверы режима ядра: Часть 15 : Жизненный цикл IRP — Архив WASM.RU
В этой и следующей статье мы рассмотрим принципы фильтрации (перехвата) пакетов запроса в/в (IRP). Для чего нужно перехватывать чужие IRP? Применений этому много. Например, захотелось нам посмотреть, к каким файлам обращается та или иная программа. Что мы сделаем в первую очередь? Правильно — запустим FileMon ( sysinternals.com ), который установит драйвер-фильтр на файловую систему. А поскольку обращение к файлам — это фактически формирование соответствующих IRP (быстрый в/в, при котором формирования IRP не происходит, не в счет) и посылка их драйверам файловой системы, то прежде чем добраться до адресата, IRP попадет в фильтр и FileMon зафиксирует это обращение, после чего перешлет его адресату. При этом воздействовать на перехватываемые пакеты FileMon не может. Его задача — только регистрировать факт посылки IRP. Другой пример. Допустим, вам понадобилось скрыть, например, от ваших ближайших родственников или коллег по работе, наличие некоторых файлов фривольного содержания. Недолго думая, вы наберете в google что-то вроде «Hide Files And Folders» и тут же найдете кучку программ, позволяющих скрывать отдельные файлы и каталоги. Это возможно благодаря тому же самому механизму фильтрации IRP. Получая доступ к пакету, драйвер-фильтр имеет возможность модифицировать передаваемые в нём данные, как на пути к файловой системе, так и обратно. Разумеется, фильтровать можно не только IRP передающиеся в файловую систему, но и любые другие. Фильтрация IRP — это общий и универсальный механизм. Антивирусные мониторы, файерволы, на лету компрессоры/декопрессоры крипторы/декрипторы и т.д. и т.п. используют механизм фильтрации IRP. Фильтр, который мы напишем в следующий раз, будет отслеживать IRP, связанные с клавиатурным вводом.
Фильтрация пакетов запроса в/в — достаточно сложная тема. Поэтому, прежде чем перейти к практической реализации потребуется хотя бы минимальная теоретическая подготовка. Как минимум, надо четко представлять себе жизненный цикл IRP от «рождения до смерти». В этой статье мы, в основном, и будем заниматься исследованием этого вопроса. Поскольку драйверы, обслуживающие клавиатуру, в полной мере поддерживают механизм Plug And Play, то придется, в минимальном объеме, осветить и этот вопрос. При этом наш фильтр не будет драйвером Plug And Play. Это будет по-прежнему унаследованный (legacy), в терминологии Microsoft, драйвер, но подключать мы его будем к Plug And Play драйверу.
Ввиду сложности темы, мне вряд ли удастся осветить этот вопрос со всех сторон. Много дополнительной информации можно получить из раздела DDK «Handling IRPs». В Installable File System Kit (IFS KIT), являющийся надмножеством обычного DDK, имеется также раздел «OSR Technical Articles» куда вошли статьи подготовленные командой Open System Resources ( http://www.osr.com/ ). Если в вашем распоряжении только обычный DDK, то большую часть этих статей, если не все, а также много дополнительной информации можно найти в онлайновом журнале «The NT Insider» ( http://www.osronline.com/ ).
Общая классификация драйверов WDM
Все Plug And Play драйверы должны соответствовать модели драйверов Windows (Windows Driver Model, WDM). В соответствии с этой моделью драйверы подразделяются на три типа:
- Драйверы шин (Bus Drivers). Управляют логическими или физическими шинами. Отвечают за распознавание устройств, подключение их к управляемой ими шине и оповещение о них диспетчера PnP.
- Функциональные драйверы (Function Drivers). Управляют конкретным типом устройств. Экспортируют рабочий интерфейс устройства операционной системе.
- Драйверы фильтров (Filter Drivers). Занимая более высокий логический уровень, чем функциональные драйверы, добавляют функциональность или изменяют поведение устройства либо другого драйвера. Этот тип драйверов не обязателен для нормальной работы устройства.
Драйверы фильтров, в свою очередь, подразделяются на:
- Драйверы фильтров шин (Bus Filter Drivers).
- Низкоуровневые драйверы фильтров (Lower-Level Filter Drivers).
- Высокоуровневые драйверы фильтров (Upper-Level Filter Drivers).
Как вы знаете, каждый драйвер должен создать, как минимум, один объект «устройство», которым он будет управлять. Объекты «устройство» WDM также делит на типы:
- Объект «физическое устройство» (Physical Device Object, PDO) — Создается драйвером шины по заданию диспетчера PnP, когда драйвер шины, перечисляя устройства на своей шине, сообщает о наличии какого-либо устройства. PDO представляет физический интерфейс устройства.
- Объект «функциональное устройство» (Functional Device Object, FDO) — Создается функциональным драйвером, который загружается диспетчером PnP для управления обнаруженным устройством. FDO представляет логический интерфейс устройства.
- Необязательная группа объектов «устройство-фильтр» (Filter Device Object, FiDO). Одна группа таких объектов размещается между PDO и FDO (эти объекты создаются драйверами фильтров шин), вторая — между первой группой FiDO и FDO (эти объекты создаются низкоуровневыми драйверами фильтров), а третья — над FDO (эти объекты создаются высокоуровневыми драйверами фильтров).
Дерево устройств
Имея вышеозначенную классификацию, начнем с того, что определимся, каким образом система, точнее говоря, диспетчер PnP (PnP Manager) — компонент операционной системы, предназначенный для автоматического распознавания установленных устройств, узнает, какие драйверы необходимы для того или иного устройства. Процесс распознавания включает в себя перечисление устройств при загрузке и обнаружение их добавления или удаления во время работы системы.
Во время загрузки системы диспетчер PnP начинает перечисление устройств с виртуальной шины под именем Root. В качестве виртуального драйвера, обслуживающего эту шину, выступает сама система. Логически, всё устройства (физические и виртуальные) подключены к этой шине. Виртуальный драйвер корневой шины (и драйверы других шин тоже) извлекает необходимую информацию из реестра. В реестр сведения об оборудовании заносятся ещё на этапе установки операционной системы. Программа установки обнаруживает установленные устройства и, используя информационные файлы (INF Files), заполняет соответствующие разделы реестра. Перечисляя устройства на корневой шине, её виртуальный драйвер обнаруживает другие шины (физические и виртуальные), например, физическую шину PCI. На основе данных реестра диспетчер PnP определяет, установлен ли в системе драйвер, способный управлять обнаруженным устройством. Если такой драйвер установлен, диспетчер PnP указывает диспетчеру ввода-вывода (I/O Manager) загрузить его. Если подходящий драйвер не установлен, диспетчер PnP пытается его установить. При этом если не обнаружится соответствующего информационного файла или других необходимых файлов, диспетчер PnP взаимодействует с пользователем, который должен указать месторасположение необходимых компонентов. Будучи загруженным, драйвер, обслуживающий обнаруженную шину, перечисляет подключенные к ней устройства. При этом он может обнаружить другие дополнительные шины. Если для работы устройства, обнаруженного на шине, необходим драйвер, он загружается. Такой рекурсивный процесс — перечисление устройств, загрузка драйвера, дальнейшее перечисление — продолжается до тех пор, пока не будут обнаружены и сконфигурированы все устройства в системе. Диспетчер PnP способен обнаруживать добавление/удаление нового устройства и во время работы системы. В результате перечисления образуется так называемое дерево устройств (Device Tree), отражающее иерархические взаимосвязи между всеми установленными в системе устройствами.
Дерево устройств можно просмотреть с помощью диспетчера устройств (Device Manager). Как выглядит дерево устройств на моём компьютере (в меню «Вид» я выбрал «Устройства по подключению» и отметил «Показать скрытые устройства».) показано на Рис. 15.1.
Рис. 15-1. Дерево устройств.
На рисунке вы можете обнаружить некоторые, созданные нами ранее виртуальные устройства, например, ProcessMon (Process creation/destruction monitor), подключенные (также виртуально) к корневой шине. В Windows 2000 диспетчер устройств показывает все установленные ранее виртуальные устройства, а в Windows XP (и в Windows 2003 Server, наверное, тоже) только активные в данный момент. Информация о виртуальных устройствах извлекается диспетчером устройств из разделов реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumRootLEGACY_XXX.
Узлы дерева устройств называются узлами устройств (device nodes или devnodes). Каждый узел обслуживается одним или несколькими драйверами. Каким образом система узнает, какие драйверы, какой узел обслуживают?
Все устройства, обнаруженные в процессе установки системы (а также установленные позже), регистрируются в подразделах реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnum<enumerator><deviceID><instanceID>. Где enumerator — драйвер шины, перечисляющий устройства на шине, deviceID — уникальный идентификатор устройств данного типа, instanceID — уникальный идентификатор экземпляра устройства данного типа (по нему можно различать несколько одинаковых устройств).
В процессе перечисления драйвер шины сообщает диспетчеру PnP идентификаторы обнаруженных устройств: deviceID и instanceID. Используя эту информацию, диспетчер PnP находит в реестре драйверы нужные для узла данного устройства.
Пример подраздела Enum для клавиатуры показан на рис 15-2.
Рис. 15-2. Подраздел реестра ветви Enum для клавиатуры.
Как видно из рисунка, перечислителем является ACPI, идентификатор устройства — PNP0303, а идентификатор экземпляра устройства — 3&13c0b0c5&0. Если заглянуть в %SystemRoot%infkeyboard.inf, то можно обнаружить, что информация в реестр попадает именно из этого информационного файла. К вашей машине, разумеется, может быть подключена клавиатура другого типа.
Функциональный драйвер задается параметром Service. В данном случае это i8042prt. Параметр ClassGUID (Globally Unique Identifier of Class) определяет подраздел класса устройства HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass. Этот подраздел содержит сведения о драйвере класса устройства. Драйвер класса определяет общую функциональность для всех устройств данного типа. Он ничего не знает о том, как управлять конкретным устройством, но, используя стандартизованные сервисы, взаимодействует с функциональным драйвером, который, в свою очередь, знает, как управляет конкретным типом устройств. В данном случае драйвером класса является kbdclass. Он исполняет роль своего рода буфера между функциональным драйвером i8042prt и подсистемой Win32 (подробнее в следующей статье). Пример подраздела Class для клавиатуры показан на рис 15-3.
Рис. 15-3. Подраздел реестра ветви Class для клавиатуры.
Содержимое этих двух разделов дает диспетчеру PnP всю информацию необходимую для загрузки драйверов для узла данного устройства. Имена драйверов указывают на подразделы реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices<drivername>.
Загрузка драйверов для узла устройства происходит в следующем порядке:
- Низкоуровневые драйверы фильтров, указанные в параметрах LowerFilters ветвей реестра Enum и Class.
- Функциональный драйвер, заданный в параметре Service ветви реестра Enum.
- Высокоуровневые драйверы фильтров, указанные в параметрах UpperFilters ветвей реестра Enum и Class.
Стек объектов «устройство»
Всё, вышесказанное не имеет прямого отношения к материалу статьи. Используемый в ней драйвер не является PnP-драйвером, а по-прежнему относится к унаследованным драйверам (legacy drivers). Общее понимание механизма перечисления и знание того, что представляет собой дерево устройств необходимо для ввода следующего, уже непосредственно важного для нас, понятия.
Загружая каждый PnP драйвер, диспетчер PnP вызывает стандартную процедуру драйвера AddDevice. В параметре PhysicalDeviceObject передается указатель на объект «физическое устройство», созданный драйвером шины. Загруженный драйвер, в свою очередь, создает свой объект «устройство» и подключает его к объекту «физическое устройство», вызовом функции IoAttachDeviceToDeviceStack. В эту функцию он передает два указателя: переданный ему диспетчером Pnp указатель на объект «физическое устройство» и указатель на созданный им объект «устройство». При этом новый объект всегда подключается к самому верхнему объекту в этой цепочке, вне зависимости от того, имеется ли над PDO другие объекты или нет. Указатель на объект «физическое устройство», при подключении нового объекта, используется как указатель на цепочку объектов, к которой происходит подключение, а не указатель на конкретный объект «устройство». Функция IoAttachDeviceToDeviceStack сама находит самый верхний объект.
Получившаяся конструкция состоит, как минимум, из двух объектов: объект «физическое устройство», созданный драйвером шины, и объект «функциональное устройство», созданный функциональным драйвером, и называется стеком объектов «устройство» (device stack) или просто стеком. Т.о. каждый узел в дереве устройств представлен своим стеком.
Учитывая всё вышесказанное, и имея содержимое разделов реестра Enum и Class, мы можем предсказать, из каких объектов будет состоять стек для узла устройства «клавиатура» (объекты перечисляются снизу вверх):
- объект «физическое устройство», созданный драйвером шины ACPI.
- объект «функциональное устройство», созданный функциональным драйвером i8042prt.
- объект «устройство-фильтр», созданный высокоуровневым драйвером фильтра nmfilter (NTICE Support File).
- объект «устройство-фильтр», созданный высокоуровневым драйвером фильтра kbdclass.
Оба объекта «устройство-фильтр» созданы высокоуровневыми драйверами фильтров, а драйверов фильтров шины и низкоуровневых драйверов фильтров в данном случае нет.
Просмотреть стеки устройств можно с помощью программы Devide Tree ( osr.com или osronline.com ). Но я избегаю пользоваться этой утилитой, т.к. её работа на трех моих машинах с разными версиями системы неизбежно приводит к появлению «синего экрана смерти» (по крайней мере, в режиме PnP). Удивительно, что эта утилита входит в DDK. Мы воспользуемся более надежной командой !devstack отладчика Kernel Debugger.
Рис. 15-4. Стеки объектов «устройство» для клавиатуры.
На этой машине активна система Terminal Server и у клавиатуры имеется не один, а два стека. Как видите, наши предположения о составе устройств подтвердились. На вашей машине его состав, естественно, может отличаться. Далее мы будем рассматривать классический состав стека для клавиатуры, а именно: Kbdclass сверху, i8042prt посередине, ACPI внизу.
В общем случае стек объектов «устройство» может выглядеть так (см. классификацию драйверов и объектов в WDM выше):
Рис. 15-5. Стек объектов «устройство» для узла устройства (общая схема).
Поскольку каждым объектом «устройство» в стеке управляет драйвер, то очень часто наряду с понятием «стек устройств» употребляют «стек драйверов». Это не совсем верно, но о чём идет речь, надеюсь, понятно. Далее по ходу статьи я тоже буду иногда говорить «стек устройств», и иногда «стек драйверов».
IRP формируется диспетчером в/в или драйвером не принадлежащим стеку и направляется на вершину стека. Если для обработки запроса драйверу требуется помощь нижестоящего драйвера, он перенаправляет IRP ниже по стеку и т.д. IRP всегда идет по стеку сверху вниз. Решение об окончании обработки IRP может быть принято на любом уровне. Мало того, любой драйвер в стеке может сформировать дополнительные IRP (например, разбить запрос чтения из файла на несколько запросов) и разслать его необходимым драйверам. Любой драйвер может отклонить запрос или может модифицировать передаваемые в нем данные. В общем случае, если драйвер получил IRP, то может делать с ним всё что угодно.
Язык с за три минуты
Мне придется использовать исходные коды некоторых системных функций, т.к. по-настоящему разобраться с обработкой IRP без анализа исходного кода, по-моему, невозможно. Эти фрагменты, конечно, не будут истинным кодом операционной системы и будут урезаны, порой весьма значительно. Также опущена вся обработка ошибок: проверки указателей, входных данных и возвращаемых функциями значений, убраны обработчики SEH. Оставлена только самая суть. Для упрощения анализа кода я буду использовать c-подобный псевдоязык (почти чистый с). Вполне допускаю, что вы можете и не знать этого языка, т.к. мы всё же занимаемся разработкой драйверов на ассемблере. Поэтому тезисно приведу базовые конструкции, без которых не обойтись.
На ассемблере место под инициализированную переменную отводится так:
В языке с глобальные и локальные инициализированные переменные определяются так:
Если надо передать адрес переменной в функцию (используя макрос invoke) мы делаем это так:
Программист на с делает это так:
Обратная операция — запись в переменную значения по указателю на переменную — в ассемблере это выглядит так (pwd — указатель на переменную размером в двойное слово):
В с это несколько проще:
Если у нас есть структура FILE_OBJECT, то мы можем записать в её поле DeviceObject указатель на объект «устройство» таким образом:
pDeviceObject PDEVICE_OBJECT ?
mov FileObject.DeviceObject, eax
Программист на с делает это так:
PDEVICE_OBJECT pDeviceObject;
FileObject.DeviceObject = pDeviceObject;
Если же, вместо структуры, в нашем распоряжении указатель на неё, то вышеозначенную операцию нам придется делать примерно так:
pFileObject PFILE_OBJECT ?
pDeviceObject PDEVICE_OBJECT ?
mov (FILE_OBJECT PTR [ecx]).DeviceObject, eax
Программисту на с, как всегда, немного проще:
PFILE_OBJECT pFileObject;
PDEVICE_OBJECT pDeviceObject;
pFileObject->DeviceObject = pDeviceObject;
Если с-программисту надо увеличить значение переменной на единицу, то он может сделать это, как минимум тремя способами, самый очевидный из которых следующий:
Для уменьшения числа IRP циркулирующих в системе можно сделать это и так:
Такой же трюк можно проделать и с другими тремя математическими операциями. Логические операции тоже можно записывать в такой форме. Например:
Эквивилентно
Но, скажу вам по секрету, есть ещё один способ, которым обычно пользуются только гуру или самые ленивые с-программисты для приращения переменных на единицу:
Такой же трюк можно проделывать и с операцией вычитания.
В дальнейшие подробности вдаваться не будем, этого минимума должно хватить. Также имейте в виду, что в DDK есть полный исходный код драйверов kbdclass и i8042prt. Правда, в разных DDK он немного отличается. Соответственно, отличаются и эти драйверы в разных версиях системы.
Мы уже много раз получали IRP, но ещё ни разу не создавали его сами. Поскольку мы собираемся рассмотреть весь жизненный цикл пакета запроса в/в, то без его создания нам никак не обойтись. С этого и начнем.
Допустим, у нас есть имя объекта «устройство», скажем, DeviceKeyboardClass0. Судя по названию, этот объект имеет какое-то отношение к обслуживанию физического устройства «клавиатура». Для чего этот объект нужен и какова его роль, мы подробнее поговорим в следующей статье. Пока нас интересует только одно: у нас есть имя устройства и мы хотим послать ему какой-нибудь IRP. Это можно сделать вызовом функции IoCallDriver, прототип которой выглядит так:
IN PDEVICE_OBJECT DeviceObject,
Несмотря на название функции, первым аргументом является указатель на объект «устройство», а не «драйвер», которому адресован IRP. Обрабатывать же IRP будет, естественно, драйвер, это устройство создавший. Второй параметр — указатель на сам пакет запроса в/в.
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
; I N C L U D E F I L E S
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
include masm32includew2kntstatus.inc
include masm32includew2kntddk.inc
include masm32includew2kntoskrnl.inc
includelib masm32libw2kntoskrnl.lib
include masm32MacrosStrings.mac
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
CCOUNTED_UNICODE_STRING «DeviceKeyboardClass0», g_usTargetDeviceName, 4
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
; D I S C A R D A B L E C O D E
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
IrpComplete proc uses esi edi pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP, pContext:PVOID
assume edi:ptr IO_STATUS_BLOCK
mov eax, [esi].IoStatus.Status
mov eax, [esi].IoStatus.Information
mov [edi].Information, eax
.if [esi].PendingReturned
invoke KeSetEvent, pContext, 0, FALSE
mov eax, STATUS_MORE_PROCESSING_REQUIRED
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
QueryPnpDeviceState proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT
local iosb:IO_STATUS_BLOCK
mov status, STATUS_NOT_SUPPORTED
assume esi:ptr DEVICE_OBJECT
.if ( esi != NULL && [esi]._Type == IO_TYPE_DEVICE )
movzx eax, [esi].StackSize
invoke IoAllocateIrp, eax, FALSE
mov [edi].IoStatus.Status, STATUS_NOT_SUPPORTED
and [edi].IoStatus.Information, 0
mov iosb.Status, STATUS_NOT_SUPPORTED
IoGetNextIrpStackLocation edi
assume ebx:ptr IO_STACK_LOCATION
mov [ebx].MajorFunction, IRP_MJ_PNP
mov [ebx].MinorFunction, IRP_MN_QUERY_PNP_DEVICE_STATE
invoke KeInitializeEvent, addr keEvent, NotificationEvent, FALSE
IoSetCompletionRoutine edi, IrpComplete, addr keEvent, TRUE, TRUE, TRUE
invoke IoCallDriver, esi, edi
.if eax == STATUS_PENDING
invoke DbgPrint, $CTA0(«QueryPnpDeviceState: Request pended. Waiting…n»)
invoke KeWaitForSingleObject, addr keEvent, Executive, KernelMode, FALSE, NULL
.if status == STATUS_SUCCESS
invoke DbgPrint, $CTA0(«QueryPnpDeviceState: Device State: %08Xn»), iosb.Information
mov status, STATUS_INSUFFICIENT_RESOURCES
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
DriverEntry proc pDriverObject:PDRIVER_OBJECT, pusRegistryPath:PUNICODE_STRING
local pTargetDeviceObject:PDEVICE_OBJECT
local pTargetFileObject:PFILE_OBJECT
invoke IoGetDeviceObjectPointer, addr g_usTargetDeviceName, FILE_READ_DATA,
addr pTargetFileObject, addr pTargetDeviceObject
.if eax == STATUS_SUCCESS
invoke QueryPnpDeviceState, pTargetDeviceObject
invoke ObDereferenceObject, pTargetFileObject
mov eax, STATUS_DEVICE_CONFIGURATION_ERROR
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
set drv=QueryPnpDeviceState
masm32binml /nologo /c /coff %drv%.bat
masm32binlink /nologo /driver /base:0x10000 /align:32 /out:%drv%.sys /subsystem:native /ignore:4078 %drv%.obj
Получить указатель на нужное нам устройство по его имени мы можем с помощью IoGetDeviceObjectPointer. В случае успеха, эта функция вернёт даже два указателя: один — собственно указатель на нужное нам устройство в переменной pTargetDeviceObject, а второй — указатель на объект «файл» ассоциированный с этим устройством в переменной pTargetFileObject. Откуда взялся объект «файл»? Заглянем внутрь функции IoGetDeviceObjectPointer, а также двух других, которые она вызывает.
IN PDEVICE_OBJECT pDeviceObject
while pDeviceObject->AttachedDevice
pDeviceObject = pDeviceObject->AttachedDevice
IoGetRelatedDeviceObject(
IN PFILE_OBJECT pFileObject
PDEVICE_OBJECT pDeviceObject
pDeviceObject = pFileObject->Vpb->DeviceObject
pDeviceObject = pFileObject->DeviceObject->Vpb->DeviceObject
pDeviceObject = pFileObject->DeviceObject
if pDeviceObject->AttachedDevice != NULL
pDeviceObject = IoGetAttachedDevice( pDeviceObject )
IoGetDeviceObjectPointer(
IN PUNICODE_STRING pusObjectName,
IN ACCESS_MASK DesiredAccess,
OUT PFILE_OBJECT *out_pFileObject,
OUT PDEVICE_OBJECT *out_pDeviceObject
InitializeObjectAttributes( &oa, pusObjectName, … )
ZwOpenFile( &hFile, DesiredAccess, &oa, … )
ObReferenceObjectByHandle( hFile, 0, IoFileObjectType, KernelMode, &pFileObject, NULL )
*out_pFileObject = pFileObject
*out_pDeviceObject = IoGetRelatedDeviceObject( pFileObject )
Первым делом, функция IoGetDeviceObjectPointer получает описатель объекта «файл» (представлен структурой FILE_OBJECT).
Вспомните, как в программе управления драйвером мы получаем описатель для взаимодействия с его устройством. Мы вызываем функцию CreateFile, которая создает объект «файл», представляющий не собственно файл на диске, а виртуальное устройство (структура DEVICE_OBJECT), созданное драйвером. Т.е. на самом деле, описатель файла используется для ввода-вывода в устройство. Такая схема нужна, во-первых, для разграничения прав доступа, т.к. в структуре DEVICE_OBJECT нет, например, полей WriteAccess и SharedRead, а в FILE_OBJECT такие поля есть, во-вторых, в объекте «файл» можно хранить некоторые другие атрибуты операции ввода-вывода. Адрес истинного получателя пакета запроса в/в, в нашем случае, находится в поле FILE_OBJECT.DeviceObject. Итак, вызов ZwOpenFile, так же как и CreateFile, приводит к созданию объекта «файл», а значит формированию IRP типа IRP_MJ_CREATE и посылке его целевому устройству (в нашем случае устройству DeviceKeyboardClass0). Этот пакет, как вы понимаете, попадает в драйвер обслуживающий это устройство (устройство DeviceKeyboardClass0 обслуживает драйвер kbdclass). Т.е. решение об удовлетворении запроса — вызове IoCompleteRequest со статусом STATUS_SUCCESS — принимает обслуживающий драйвер.
Вот фрагмент функции KeyboardClassCreate драйвера kbdclass:
PIO_STACK_LOCATION pStack;
pStack = IoGetCurrentIrpStackLocation( pIrp )
if pIrp->RequestorMode == UserMode
pStack->Parameters.Create.SecurityContext->DesiredAccess & FILE_READ_DATA {
status = STATUS_ACCESS_DENIED
goto KeyboardClassCreateEnd
Как видите, kbdclass отклоняет попытку режима пользователя получить доступ к его устройствам для чтения.
Кстати, раз уж мы так подробно собрались во всем разбираться, посмотрим на внутренности макроса IoGetCurrentIrpStackLocation, который мы сами уже много раз использовали (полная версия в ntddk.inc).
IoGetCurrentIrpStackLocation MACRO pIrp:REQ
mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
Марос IoGetCurrentIrpStackLocation просто извлекает указатель на текущий блок стека из поля CurrentStackLocation.
Получив описатель объекта «файл», функция IoGetDeviceObjectPointer дополнительно увеличивает счетчик ссылок в объекте «файл», вызовом ObReferenceObjectByHandle. Затем IoGetDeviceObjectPointer пытается получить указатель на целевое устройство, сопоставленное с объектом «файл», вызывая IoGetRelatedDeviceObject. В зависимости от принадлежности объекта «файл» тому или иному типу устройств, IoGetRelatedDeviceObject может извлечь необходимый указатель из разных мест (в нашем случае из поля pFileObject->DeviceObject). Далее, обратите на это особое внимание, если к целевому устройству прикреплено ещё одно устройство (об этом говорит ненулевое значение в поле pDeviceObject->AttachedDevice), функция IoGetAttachedDevice «поднимается» по стеку устройств до самого верха и возвращает указатель на устройство, находящееся на вершине стека. Если же прикрепленных устройств нет, то возвращается указатель на само целевое устройство, т.е. то, имя которого было передано в IoGetDeviceObjectPointer. Запомните: Функция IoGetAttachedDevice всегда возвращает указатель на объект «устройство», находящийся на вершине стека.
После получения указателя IoGetDeviceObjectPointer закрывает описатель объекта «файл» и в этот момент счетчик описателей становится равным нулю, что приводит к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLEANUP. Т.о. функция IoGetDeviceObjectPointer вернет указатели на два объекта: «файл» и «устройство». Причем в объекте «устройство» значение счетчиков указателей и описателей не меняется, а в объекте «файл» равно 1 и 0, соответственно. Единичное значение счетчика указателей достигается благодаря дополнительному вызову ObReferenceObjectByHandle. До тех пор, пока существует объект «файл», объект «устройство», с которым он связан, не будет удален и соответственно драйвер, управляющий устройством, также не может быть выгружен, т.к. в управляемом им объекте «устройство», будет установлен соответствующий флаг и при попытке выгрузить такой драйвер он отмечается как ожидающий выгрузки, а процедура DriverUnload просто не будет вызвана. Только после того, как будут удалены все управляемые драйвером устройства, драйвер сможет отработать DriverUnload.
Т.о. в случае с IoGetDeviceObjectPointer схема точно такая же, какой пользуется режим пользователя, получая описатель объекта «файл» и таким образом блокируя связанный с ним объект. При этом сам объект «файл» относится к любому источнику или приемнику ввода-вывода (собственно файлу или каталогу, именованному каналу, почтовому ящику и др.), который рассматривается как файл. При таком механизме все считываемые или записываемые данные представляются простыми потоками байтов, направляемыми в виртуальные файлы. По окончании работы, программа режима пользователя закрывает описатель файла, а мы должны будем удалить ссылку, вызовом ObDereferenceObject. При этом счетчик указателей в объекте «файл» обнулится, и это приведет к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLOSE. Только после этого объект «файл» будет удален.
Вернемся к исходному коду нашего драйвера.
invoke QueryPnpDeviceState, pTargetDeviceObject
Теперь у нас есть адресат для посылки IRP. Осталось только сформировать сам пакет.
IRP состоит из тела или заголовка (собственно структура IRP) и одного или нескольких блоков стека (stack locations). Тело IRP хранит общую информацию о запросе ввода-вывода: указатели на буферы, данные о состоянии и др. Блоки стека содержат информацию специфичную для конкретного этапа обработки IRP. Передавая IRP на обработку драйверу, диспетчер в/в (или драйвер самостоятельно создающий IRP, как мы в этом примере) заполняет верхний блок стека. Если драйвер, получивший IRP, решает отправить его на дальнейшую обработку нижестоящему драйверу, он заполняет следующий блок стека (т.к. это стек, то в памяти следующий блок стека находится по меньшему адресу — подробнее об этом чуть позже) и передает IRP ниже и т.д. Т.о. блоки стека — по одному на каждый вызываемый драйвер — хранят информацию, необходимую каждому драйверу для обработки своей части запроса.
assume esi:ptr DEVICE_OBJECT
.if ( esi != NULL && [esi]._Type == IO_TYPE_DEVICE )
movzx eax, [esi].StackSize
invoke IoAllocateIrp, eax, FALSE
Создать IRP можно одной из четырех функций: IoBuildSynchronousFsdRequest, IoBuildDeviceIoControlRequest, IoBuildAsynchronousFsdRequest и IoAllocateIrp. Если быть совсем точным, то можно сделать IRP вообще вручную, выделив память из пула или ассоциативного списка, но тогда все его поля придется заполнять самим. Мы воспользуемся самой универсальной из четырех вышеперечисленных функций — IoAllocateIrp. В отличие от трех остальных, с её помощью можно создавать IRP любого типа.
По соображениям лучшей производительности, память под IRP выделяется в одном из двух ассоциативных списков, индивидуальных для каждого процессора (структуры управляющие списками хранятся в специфичной для каждого процессора структуре KPRCB). Если нужен IRP с одним блоком стека, то используется ассоциативный список малых IRP. Если IRP должен содержать более одного блока стека — используется ассоциативный список больших IRP. Такие IRP содержат 8 блоков стека (эта цифра хранится в переменной ядра IopLargeIrpStackLocations). В Windows NT4 эта цифра равнялась 4, но с приходом PnP глубина стеков увеличилась. Если же IRP требует более 8 блоков стека или ассоциативный список пуст, то диспетчеру в/в ничего другого не остается, как выделить память под IRP из неподкачиваемого пула. Перед тем как вернуть управление, IoAllocateIrp обнуляет весь IRP и инициализирует некоторые его поля.
Irp.Size = sizeof(IRP) + StackSize * sizeof(IO_STACK_LOCATION)
Irp.AllocationFlags = <some flags>
Irp.StackCount = StackSize
Irp.CurrentLocation = StackSize + 1
Irp.Tail.Overlay.CurrentStackLocation = &Irp + sizeof(IRP) + StackSize * sizeof(IO_STACK_LOCATION)
Самые важные для нас на данный момент поля это:
- Irp.StackCount — максимально необходимое количество блоков стека в IRP. Это поле будет равно значению первого параметра переданного в IoAllocateIrp. Мы извлекаем его из объекта «устройство», которому собираемся отправить IRP. Каждый объект «устройство» знает, сколько под ним объектов и, соответственно, сколько нужно блоков стека.
- Irp.CurrentLocation — порядковый номер текущего блока стека (отсчет идет в обратном порядке). Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает значение этого поля на единицу. Изначально же, как видите, оно на один больше чем действительно необходимо.
- Irp.Tail.Overlay.CurrentStackLocation — указатель на текущий блок стека. Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает его значение на размер структуры IO_STACK_LOCATION. Изначально оно указывает на недействительный блок стека, т.е. на область памяти сразу за концом IRP. Строго говоря, это не всегда так. Например, если IRP выделен из ассоциативного списка больших IRP, то у него 8 блоков стека, а мы, допустим, заказали 5. Тогда CurrentStackLocation будет указывать на один из лишних блоков стека. Если же мы просили IRP с одним блоком или он выделен из пула, то CurrentStackLocation указывает на «чужую» память.
По возвращении из IoAllocateIrp наш IRP выглядит так (я использовал команду irp отладчика SoftICE с ключом -f):
&ThreadListEntry : 83887018
IoStatus.Status : 00000000
IoStatus.Information : 00000000
CurrentLocation : <b>06</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>8388712C</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
StackLocation 3 at 838870C0:
StackLocation 4 at 838870E4:
StackLocation 5 at 83887108:
CurrentStackLocation at <b>8388712C</b>:
<заполнен нулями> <- недействительный блок стека
IoAllocateIrp делает только заготовку будущего IRP. Кое-какие поля требуется заполнить вручную.
mov [edi].IoStatus.Status, STATUS_NOT_SUPPORTED
and [edi].IoStatus.Information, 0
mov iosb.Status, STATUS_NOT_SUPPORTED
Для формирования IRP разных типов может потребоваться заполнение разных полей. Я заполнил только самые необходимые для нас и вам не следует принимать это за образец. Подробности можно посмотреть в DDK.
После заполнения тела IRP мы должны сформировать блок стека для драйвера, которому мы адресуем запрос. Если использовать нумерацию блоков стека как её использует SoftIce, то мы должны заполнить блок стека за номером 5. Как вы помните, сейчас поле CurrentStackLocation указывает на недействительный блок стека. Для получения указателя на следующий блок стека, принадлежащий драйверу которому мы адресуем запрос, используется макрос IoGetNextIrpStackLocation:
IoGetNextIrpStackLocation MACRO pIrp:REQ
mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
sub eax, sizeof IO_STACK_LOCATION
Пусть вас не смущает слово next в имени макроса. Мы ведь имеем дело со стеком. «Следующий драйвер» означает нижестоящий драйвер, а «следующий блок стека» — блок стека с адресом на sizeof(IO_STACK_LOCATION) меньше чем текущий блок стека. Соответственно «предыдущий драйвер» означает вышестоящий драйвер, а «предыдущий блок стека» — блок стека с адресом на sizeof(IO_STACK_LOCATION) больше чем текущий блок стека. Макрос IoGetNextIrpStackLocation берет значение из поля CurrentStackLocation и уменьшает его на размер структуры IO_STACK_LOCATION. Таким образом, мы движемся в сторону меньших адресов по направлению к телу IRP.
IoGetNextIrpStackLocation edi
assume ebx:ptr IO_STACK_LOCATION
mov [ebx].MajorFunction, IRP_MJ_PNP
mov [ebx].MinorFunction, IRP_MN_QUERY_PNP_DEVICE_STATE
Мы посылаем запрос типа IRP_MJ_PNP, а дополнительный код IRP_MN_QUERY_PNP_DEVICE_STATE определяет какую именно информацию о PnP характеристиках устройства мы хотим получить.
invoke KeInitializeEvent, addr keEvent, NotificationEvent, FALSE
Инициализируем объект «событие». На этом объекте мы будем ждать момента завершения IRP. Тип события может быть и SyncronizationEvent, т.к. всё равно кроме нас, его никто ждать не будет. В исходных кодах драйверов можно встретить оба варианта.
Буквально через одну строку мы собираемся послать IRP драйверу kbdclass. Если мы не предпримем специальных мер, то никогда уже не сможем увидеть наш IRP. Как это не покажется парадоксальным, с первого взгляда, но после вызова IoCallDriver обращаться к IRP нельзя. К концу статьи, надеюсь, будет ясно почему. Единственная возможность вновь получить контроль над IRP — это установить специальную процедуру — процедуру завершения (completion routine). Процедура завершения будет вызвана, в тот момент, когда какой-либо драйвер ниже по стеку завершит IRP вызовом IoCompleteRequest. Одной из задачь функции IoCompleteRequest как раз и является задача вызова всех процедур завершения. Нашу процедуру завершения я назвал IrpComplete, а установить её можно с помощью макроса IoSetCompletionRoutine (полный вариант в ntddk.inc):
IoSetCompletionRoutine MACRO pIrp:REQ, Routine:REQ, CompletionContext:REQ, Success:REQ, Error:REQ, Cancel:REQ
mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
sub eax, sizeof IO_STACK_LOCATION
assume eax:ptr IO_STACK_LOCATION
pop [eax].CompletionRoutine
and byte ptr [eax].Control, 0
or byte ptr [eax].Control, SL_INVOKE_ON_SUCCESS
or byte ptr [eax].Control, SL_INVOKE_ON_ERROR
or byte ptr [eax].Control, SL_INVOKE_ON_CANCEL
Первый параметр — указатель на IRP, при завершении которого должна быть вызвана процедура, указатель на которую передается во втором параметре. Третий параметр — указатель на любые данные. Этот указатель будет передан в процедуру завершения, и в нем мы укажем адрес нашего объекта «событие», которое процедура завершения, при необходимости, должна будет перевести в сигнальное состояние. Три последних параметра определяют, в каком случае будет вызвана процедура. Нам нужно, чтобы она была вызвана в любом случае: при завершении IRP с кодом успеха, при завершении IRP с кодом ошибки, при отмене IRP. Т.е. как бы ни завершился IRP, мы всё равно его перехватим на обратном пути. Обратите внимание, что макрос IoSetCompletionRoutine использует следующий блок стека, т.е. предназначенный для нижестоящего драйвера. Т.е. адрес процедуры завершения и её параметр помещаются не в блок стека драйвера, которому он принадлежит, а в блок стека нижестоящего драйвера. Почему мы лезем в чужой блок стека со своей процедурой завершения? Дело в том, что, во-первых, у нас нет своего блока стека, точнее он нам не нужен. Мы же сами формируем IRP и прекрасно знаем, что в нем содержится. С другой стороны, драйверу, стоящему ниже в стеке, который будет завершать IRP, не нужна процедура завершения. Он же сам его завершает и прекрасно знает как.
И ещё один очень важный момент, касающийся процедур завершения. В общем случае обработка ввода/вывода с физического устройства проходит по следующей схеме. Драйвер инициирует операцию в/в. Когда устройство завершает операцию, то генерирует прерывание, которое обрабатывается процедурой обработки прерывания (Interrupt Service Routine, ISR), зарегистрированной драйвером. Причем обработка будет происходить в контексте того потока, который был текущим на момент прерывания, а это случайный поток. Т.к. ISR работает на повышенном IRQL (больше DISPATCH_LEVEL), работа всех остальных потоков на данном процессоре блокируется. Мало того, блокируются (маскируются) все прерывания с таким же или более низким уровнем. Для того чтобы обработать возможные прерывания от менее приоритетных устройств, необходимо как можно быстрее понизить IRQL. Для этого ISR делает только то, что необходимо сделать немедленно и ставит в очередь так называемый вызов отложенной процедуры (Deferred Procedure Call, DPC). DPC работает при IRQL = DISPATCH_LEVEL. Когда IRQL понижается до DISPATCH_LEVEL, система вызывает отложенную процедуру и она делает дополнительные операции по завершению IRP. В самой последней фазе отложенная процедура вызывает IoCompleteRequest, которая, как я сказал выше, вызывает все процедуры завершения. Поэтому процедура завершения может быть вызвана в контексте случайного потока и при IRQL меньше или равном DISPATCH_LEVEL.
Раз процедура завершения может быть вызвана на повышенном IRQL, то очевидно, что и она сама и все данные, к которым она обращается должны находиться в неподкачиваемой памяти. Наша процедура завершения обращается к двум структурам: IO_STATUS_BLOCK и KEVENT (сам IRP не в счет, т.к. он всегда выделяется из неподкачиваемой памяти), которые располагаются в стеке потока, выполняющего процедуру QueryPnpDeviceState. Если этот поток будет ждать, то его стек может быть выгружен в файл подкачки (то, что, в данном случае, это системный поток не в счет). Чтобы запретить системе это делать, необходимо указывать KernelMode в параметре WaitMode функций ожидания. Я уже как-то раз говорил об этом, но, на всякий случай, повторяю.
IoSetCompletionRoutine edi, IrpComplete, addr keEvent, TRUE, TRUE, TRUE
invoke IoCallDriver, esi, edi
Ну что же. Теперь у нас есть всё необходимое: адресат, сформированный IRP и процедура завершения, готовая перехватить его на обратном пути. Вызовом функции IoCallDriver, посылаем IRP драйверу, обслуживающему объект «устройство», указатель на который содержится в первом параметре.
Реализация функции IoCallDriver на удивление проста:
IN PDEVICE_OBJECT pDeviceObject,
PIO_STACK_LOCATION pStack
PDRIVER_OBJECT pDriverObject
if pIrp->CurrentLocation <= 0 {
KeBugCheckEx( NO_MORE_IRP_STACK_LOCATIONS, pIrp, … )
pIrp->Tail.Overlay.CurrentStackLocation -= sizeof(IO_STACK_LOCATION)
pStack = pIrp->Tail.Overlay.CurrentStackLocation
pStack->DeviceObject = pDeviceObject
pDriverObject = pDeviceObject->DriverObject
status = pDriverObject->MajorFunction[pStack->MajorFunction]( pDeviceObject, pIrp )
Сначала IoCallDriver уменьшает значение CurrentLocation на единицу и если оно вдруг стало равно нулю или ещё меньше, то система показывает «голубой экран смерти», т.к. нулевое значение в поле CurrentLocation говорит о том, что мы исчерпали все блоки стека и если IoCallDriver пойдет дальше, то просто будет «затирать» тело IRP, что рано или поздно всё равно приведет к краху. Затем значение в CurrentStackLocation уменьшается на размер структуры IO_STACK_LOCATION. Вот теперь оба поля: CurrentLocation и CurrentStackLocation соответствуют заполненному нами блоку стека. CurrentLocation равно 5, а CurrentStackLocation — 83887108. Сейчас наш IRP выглядит так:
&ThreadListEntry : 83887018
IoStatus.Status : C00000BB
IoStatus.Information : 00000000
CurrentLocation : <b>05</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>83887108</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
StackLocation 3 at 838870C0:
StackLocation 4 at 838870E4:
CurrentStackLocation at <b>83887108</b>:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852AB0
CompletionRout * : ED5E14C0
Далее IoCallDriver помещает в поле DeviceObject текущего блока стека указатель на вызываемый объект «устройство». Этот указатель может потребоваться процедуре завершения. Затем из объекта «устройство» извлекается указатель на обслуживающий его драйвер и вызывается одна из процедур диспетчеризации драйвера. Т.к. в pStack->MajorFunction находится IRP_MJ_PNP, IoCallDriver берет из соответствующего элемента массива MajorFunction указатель на процедуру и передает ей адреса объекта «устройство» и IRP (вспомните любую функцию диспетчеризации, коих мы написали уже не мало). Если драйвер не занёс в соответствующее поле массива MajorFunction указатель на свою процедуру обработки данного типа IRP, то по умолчанию там находится указатель на системную функцию IopInvalidDeviceRequest, которая просто возвращает STATUS_INVALID_DEVICE_REQUEST и на этом обработка IRP будет завершена, не начавшись. Если же нужная процедура у драйвера имеется, а kbdclass имеет процедуру для обработки запросов IRP_MJ_PNP, то мы в нее и попадем, а IoCallDriver вернет то, что вернет эта процедура.
Теперь, прежде чем мы погрузимся в kbdclass, немного «уйдем в сторону» и представим, что IRP, только что сформированный нами, не IRP типа IRP_MJ_PNP, а гипотетический IRP_MJ_UNKNOWN, и посылаем мы его абстрактному драйверу unknown, процедура диспетчеризации которого выглядит приблизительно так:
DispatchUnknown proc uses esi pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP
lea ecx, [esi].Tail.Overlay.ListEntry
InsertTailList addr g_IrpQueue, ecx
mov status, STATUS_PENDING
mov status, STATUS_SUCCESS
mov [esi].IoStatus.Status, STATUS_SUCCESS
mov [esi].IoStatus.Information, SOME_INFORMATION
fastcall IofCompleteRequest, esi, IO_NO_INCREMENT
Драйвер unknown либо сразу завершает IRP, либо ставит его в очередь, для того чтобы завершить позже. Сначала рассмотрим первый случай.
Прежде чем добавить IRP в очередь, драйвер должен отметить его как ожидающий завершения (pending). Это можно сделать с помощью макроса IoMarkIrpPending, который выглядит так:
IoMarkIrpPending MACRO pIrp:REQ
mov eax, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
or (IO_STACK_LOCATION PTR [eax]).Control, SL_PENDING_RETURNED
Обратите внимание — флаг означающий, что IRP ожидает завершения, помещается не в тело IRP, а в текущий блок стека. Т.е. каждый драйвер независимо от других может проделать эту операцию.
Дальше драйвер помещает IRP в очередь и возвращает код STATUS_PENDING, говорящий вышестоящему драйверу о том, что завершение IRP отложено на неопределенное время. В нашем случае, вышестоящий драйвер — наш драйвер и ему необходимы результаты завершения IRP. Поэтому будем ждать, на созданном нами объекте «событие».
Существует несколько механизмов, которыми драйверы могут пользоваться для постановки IRP в очередь, но в итоге все сводится к добавлению IRP в двусвязный список. В самом простом случае можно использовать поле IRP.Tail.Overlay.ListEntry. Для того чтобы гарантировать себе монопольный доступ к очереди драйверы используют блокировку. Как работает очередь и блокировка, сейчас не важно.
По прошествии некоторого времени драйвер решает удалить IRP из очереди и завершить его.
RemoveHeadList addr g_IrpQueue
sub eax, _IRP.Tail.Overlay.ListEntry
mov esi, eax ; esi -> _IRP
mov [esi].IoStatus.Status, STATUS_SUCCESS
mov [esi].IoStatus.Information, SOME_INFORMATION
fastcall IofCompleteRequest, esi, IO_NO_INCREMENT
Это может произойти в контексте любого потока и в любой момент (в результате прерывания). В данном случае, для нас важно лишь то, что драйвер вызывает IoCompleteRequest.
PIO_STACK_LOCATION pStack
pStack->MinorFunction = 0
pStack->Parameters.Others.Argument1 = 0
pStack->Parameters.Others.Argument2 = 0
pStack->Parameters.Others.Argument3 = 0
pStack->Parameters.Others.Argument4 = 0
pStack->FileObject = NULL
PIO_STACK_LOCATION pStack
if pIrp->CurrentLocation > pIrp->StackCount + 1 {
KeBugCheckEx( MULTIPLE_IRP_COMPLETE_REQUESTS, … )
ASSERT( pIrp->IoStatus.Status != STATUS_PENDING )
pStack = IoGetCurrentIrpStackLocation( pIrp )
pIrp->Tail.Overlay.CurrentStackLocation += sizeof(IO_STACK_LOCATION)
while pIrp->CurrentLocation <= pIrp->StackCount + 1 {
pIrp->PendingReturned = pStack->Control & SL_PENDING_RETURNED
if pIrp->IoStatus.Status == STATUS_SUCCESS && pStack->Control & SL_INVOKE_ON_SUCCESS
pIrp->IoStatus.Status != STATUS_SUCCESS && pStack->Control & SL_INVOKE_ON_ERROR
pIrp->Cancel == TRUE && pStack->Control & SL_INVOKE_ON_CANCEL
ZeroIrpStackLocation( pStack )
PDEVICE_OBJECT pDeviceObject
if pIrp->CurrentLocation == pIrp->StackCount + 1 {
pDeviceObject = IoGetCurrentIrpStackLocation( pIrp )->DeviceObject
status = pStack->CompletionRoutine( pDeviceObject, pIrp, pStack->Context )
if status == STATUS_MORE_PROCESSING_REQUIRED {
if pIrp->PendingReturned && pIrp->CurrentLocation <= pIrp->StackCount {
ZeroIrpStackLocation( pStack )
pStack += sizeof(IO_STACK_LOCATION)
pIrp->Tail.Overlay.CurrentStackLocation += sizeof(IO_STACK_LOCATION)
Рис. 15-6. Блок-схема функции IoCompleteRequest.
IoCompleteRequest должна пройтись по всем блокам стека, участвовавшим в обработке IRP, причем в обратном порядке, и вызвать все процедуры завершения. Когда IRP продвигается вниз, то значения полей CurrentLocation и CurrentStackLocation уменьшаются с каждым вызовом IoCallDriver (исключением является случай, когда драйвер передает свой собственный блок стека нижестоящему драйверу, пользуясь макросом IoSkipCurrentIrpStackLocation). IoCompleteRequest проделывает обратную работу, начиная с текущего блока стека, т.е. того, указатель на который находится в поле CurrentStackLocation (именно этот блок стека был текущим для драйвера вызвавшего IoCompleteRequest).
Когда IoCompleteRequest «поднимется» до самого верха, значения этих двух полей будут такими же, какими они были сразу после вызова IoAllocateIrp. Т.е. значение в поле CurrentLocation должно быть на единицу больше чем StackCount, а CurrentStackLocation будет указывать на недействительный блок стека.
Поэтому если CurrentLocation больше или равно StackCount + 1, это означает, что IRP уже был завершен. А завершать два раза IRP это примерно то же самое, что повторно вызывать ExFreePool с одним и тем же указателем. «Синий экран смерти» тут как нельзя кстати. Поэтому завершать IRP можно только один раз.Дальше идет отладочное утверждение ASSERT. Код, заключенный в макрос ASSERT попадает только в отладочный выпуск (checked build) системы. В свободном выпуске (free build) системы отловить такой баг можно с помощью Driver Verifier. Я специально добавил эту строку, т.к. завершение IRP с кодом STATUS_PENDING — очень распространенная ошибка. IRP может либо завершаться, либо ожидать завершения. Третьего не дано.
Правило:
Завершать IRP с кодом STATUS_PENDING нельзя.
Далее IoCompleteRequest получает указатель на текущий блок стека, вызовом макроса IoGetCurrentIrpStackLocation. А какой блок стека текущий в данном случае? Сейчас текущим является блок стека, принадлежащий драйверу unknown. Ведь IRP продвигался вниз всего на «один шаг». Если бы драйверу unknown понадобился указатель на его блок стека, то вызовом IoGetCurrentIrpStackLocation, он получил бы тот же самый адрес.
Потом IoCompleteRequest крутит цикл, проходя по всем участвовавшим в обработке IRP блокам стека в обратном порядке. Если в блоке стека установлен флаг SL_PENDING_RETURNED, значит драйвер, которому он принадлежит, вызывал IoMarkIrpPending. Если это так, то устанавливается ненулевое значение в поле IRP.PendingReturned. А если флаг SL_PENDING_RETURNED не установлен, то поле IRP.PendingReturned обнуляется. Это нужно для того, чтобы вышестоящий драйвер в своей процедуре завершения смог видеть, что нижестоящий драйвер отмечал IRP как ожидающий завершения. Обращаться к чужим блокам стека драйверы не должны (исключение — копирование/заполнение блока стека при передаче IRP вниз по стеку). IoCompleteRequest даже специально обнуляет некоторые поля обработанного блока стека используя ZeroIrpStackLocation (на самом деле это макрос, а не функция). Поэтому SL_PENDING_RETURNED, как бы «перекладывается» в поле PendingReturned самого IRP. Когда мы доберемся до схемы на рис. 15-7, предназначение поля PendingReturned станет более понятно.
Если вышестоящий драйвер установил процедуру завершения (вы должны помнить, что драйверы устанавливают процедуры завершения в блоке стека, принадлежащем нижестоящему драйверу), она вызывается. В процедуру завершения передается указатель на объект «устройство», принадлежащий драйверу установившему эту процедуру. Поскольку инициатор запроса (наш драйвер, в данном случае) не имеет своего блока стека, то в качестве указателя на объект «устройство» он получит NULL.
Если процедуре завершения потребуется обратиться к текущему блоку стека она тоже может использовать макрос IoGetCurrentIrpStackLocation. А какой блок стека она получит? Процедура завершения получит блок стека, принадлежащий её драйверу. Т.е. и в процедуре диспетчеризации и в процедуре завершения IoGetCurrentIrpStackLocation возвращает один и тот же указатель. Можем ли мы как создатели IRP в нашей процедуре завершения вызвать IoGetCurrentIrpStackLocation? Нет. Точнее указатель то мы получим, но на недействительный блок стека. Ведь своего собственного блока стека у нас нет, т.к. он нам не нужен.
Если процедура завершения вернула STATUS_MORE_PROCESSING_REQUIRED, то IoCompleteRequest, не делая ни одного лишнего движения, сразу возвращает управление, т.к. трогать IRP она уже не имеет права — возможно, IRP уже не существует. В нашем случае это именно так, ведь мы в процедуре завершения вызываем IoFreeIrp и для того, чтобы заставить IoCompleteRequest немедленно прекратить дальнейшие действия по завершению IRP, возвращаем STATUS_MORE_PROCESSING_REQUIRED. Если же процедура завершения возвращает любой другой код, то IoCompleteRequest продолжает работу. DDK рекомендует в качестве «любого другого кода» возвращать STATUS_SUCCESS просто потому, что он равен 0, а это приводит к генерации компилятором более оптимального кода. В более поздних DDK можно найти такие определения:
#define STATUS_CONTINUE_COMPLETION STATUS_SUCCESS
typedef enum _IO_COMPLETION_ROUTINE_RESULT {
ContinueCompletion = STATUS_CONTINUE_COMPLETION,
StopCompletion = STATUS_MORE_PROCESSING_REQUIRED
} IO_COMPLETION_ROUTINE_RESULT, *PIO_COMPLETION_ROUTINE_RESULT;
Имена констант ContinueCompletion и StopCompletion значительно лучше отражают суть, чем STATUS_SUCCESS и STATUS_MORE_PROCESSING_REQUIRED. Т.о., возвращая StopCompletion, мы говорим функции IoCompleteRequest, что она должна немедленно прекратить работу и вернуть управление. Если мы возвращаем ContinueCompletion (точнее говоря, не возвращаем StopCompletion), то IoCompleteRequest продолжает процесс завершения IRP.
Для чего нам нужно остановить IoCompleteRequest? Мы, как создатели IRP, не можем допустить, чтобы диспетчер в/в завершал созданный нами IRP. Это наша работа. Единственная возможность это сделать — установить процедуру завершения.
Если в обрабатываемом блоке стека нет указателя на процедуру завершения, то IoCompleteRequest смотрит, было ли установлено на предыдущем шаге поле IRP.PendingReturned. Если да, и всё ещё есть действительный блок стека, взводит флаг SL_PENDING_RETURNED в предыдущем блоке стека (этот блок IoCompleteRequest будет обрабатывать при следующем витке цикла), используя макрос IoMarkIrpPending.
Представим теперь два плохих сценария:
- драйвер unknown возвращает STATUS_PENDING, но забывает про IoMarkIrpPending;
- драйвер unknown отмечает IRP как ожидающий завершения, используя IoMarkIrpPending, но забывает вернуть STATUS_PENDING.
Сценарий 1: Если драйвер возвращает из процедуры диспетчеризации код STATUS_PENDING, IoCallDriver передаст этот код нам. Увидев такой код, мы бесконечно ждем, пока наша процедура завершения не освободит событие. По прошествии некоторого времени драйвер unknown инициирует завершение IRP. IoCompleteRequest смотрит в блок стека, принадлежащий драйверу unknown, и, не обнаружив там флага SL_PENDING_RETURNED, обнуляет IRP.PendingReturned. Видя, что в блоке стека установлена процедура завершения (установленная нашим драйвером), IoCompleteRequest вызывает её. Получив управление, наша процедура завершения не сигналит событие и освобождает память, занятую под IRP. В результате событие уже никогда не будет освобождено и поток, ожидающий на нем, никогда не возобновит работу.
Вариацией этого сценария будет ситуация, когда драйвер unknown ставит IRP в очередь, а потом вызывает IoMarkIrpPending (имеется ввиду, что блокировка очереди уже снята). Тогда ещё до того как он доберется до IoMarkIrpPending, IRP может быть извлечен из очереди и завершен.
Сценарий 2: Получив от IoCallDriver код отличный от STATUS_PENDING, наш драйвер считает, что IRP завершен и в зависимости от ошибочно возвращенного кода либо получает неверные данные, либо не получает ничего. Но это не самое страшное. Хуже, если мы переведем IoFreeIrp из процедуры завершения в основную процедуру после IoCallDriver, а мы имеем полное право это сделать. Драйвер unknown ведь не знает деталей реализации вышестоящего драйвера, и ни в коем случае не должен на это полагаться. Посчитав, что IRP завершен, мы вызовем IoFreeIrp. Через некоторое время драйвер unknown пытается извлечь уже не существующий IRP из очереди…
Не сложно догадаться, что для сценария 1 можно применить простое противоядие: вне зависимости от значения поля PendingReturned всегда вызывать KeSetEvent в процедуре завершения. Можно конечно, но тогда во всех случаях, когда IRP завершается немедленно, мы будем зря вызывать KeSetEvent, а она блокирует базу данных диспетчера потоков, ищет потоки, ждущие на событии, и делает их планируемыми, разблокирует базу данных диспетчера потоков. Вобщем, кое-какие накладные расходы будут. Но дело даже не в этом. Мы можем переписать нашу процедуру завершения, но мы не можем переписать код диспетчера в/в, который реализует свою логику работы. Диспетчер в/в вообще не устанавливает процедуру завершения. Он использует другие механизмы, но при принятии решений также опирается на код, возвращенный IoCallDriver и значение поля PendingReturned.
Правило:
Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.
Вернемся к стеку клавиатуры. Мы уже вызвали IoCallDriver и сейчас находимся в процедуре диспетчеризации KeyboardPnP драйвера kbdclass.
Я использую здесь исходный код из 2003 IFS KIT. В 2000 DDK код функции KeyboardPnP отличается: драйвер kbdclass синхронизирует обработку IRP, используя функцию KeyboardSendIrpSynchronously, почти идентичную функции I8xSendIrpSynchronously драйвера i8042ptr (см. ниже). Во-первых, так нам будет проще, а во-вторых, это внесет некоторое разнообразие.
PIO_STACK_LOCATION pStack
pStack = IoGetCurrentIrpStackLocation( pIrp )
if pStack->MinorFunction == IRP_MN_QUERY_PNP_DEVICE_STATE {
pIrp->IoStatus.Information |= PNP_DEVICE_NOT_DISABLEABLE
pIrp->IoStatus.Status = STATUS_SUCCESS
IoCopyCurrentIrpStackLocationToNext( pIrp )
status = IoCallDriver( NextLowerDeviceObject, pIrp )
Первым делом kbdclass получает указатель на свой блок стека, чтобы посмотреть чего от него хотят.
При обработке IRP_MN_QUERY_PNP_DEVICE_STATE драйвер должен поместить в поле IRP.IoStatus.Information флаг, определяющий состояние устройства. При этом, поскольку поле IRP.IoStatus.Information одно, а драйверов в стеке много, все они используют логические операции для установки или сброса нужных флагов. Драйвер kbdclass добавляет флаг PNP_DEVICE_NOT_DISABLEABLE и помещает в IRP код успеха. Теперь он должен передать его нижестоящему драйверу. При этом дальнейшая судьба этого запроса его не интересует и он не устанавливает процедуру завершения. Уак будет завершен IRP, kbdclass не узнает уже никогда. Несмотря на то, что после вызова IoCallDriver в переменной pIrp всё еще будет хранится число, являвшееся указателем на IRP, обращаться по этому указателю драйвер kbdclass не имеет права, т.к., возможно, этот IRP уже не существует и на схеме 15-7 это будет очень хорошо видно.
Перед вызовом нижестоящего драйвера, драйвер kbdclass (и любой другой) должен заполнить причитающийся ему (нижестоящему драйверу) блок стека. В данном случае, т.к. kbdclass не формирует новый IRP, а пересылает переданный ему свыше, он может просто скопировать свой блок стека в следующий (помните, что это стек, где всё поставлено с ног на голову, т.е. следующим будет блок стека расположенный в памяти ниже). Это можно сделать с помощью макроса IoCopyCurrentIrpStackLocationToNext. В ntddk.inc можно увидеть оптимизированный вариант, а здесь приводится белее доступная для понимания версия.
IoCopyCurrentIrpStackLocationToNext MACRO pIrp:REQ
mov esi, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
mov edx, (_IRP PTR [eax]).Tail.Overlay.CurrentStackLocation
sub edx, sizeof IO_STACK_LOCATION
mov ecx, sizeof IO_STACK_LOCATION
and (IO_STACK_LOCATION PTR [edx]).Control, 0
and (IO_STACK_LOCATION PTR [edx]).CompletionRoutine, 0
and (IO_STACK_LOCATION PTR [edx]).Context, 0
Как видно, макрос копирует текущий блок стека в следующий, но три поля: Control, CompletionRoutine и Context обнуляются. Зачем обнуляются эти поля, мы знаем ниже. Теперь kbdclass вызывает IoCallDriver, передавая в своей переменной NextLowerDeviceObject, указатель на объект «устройство» находящийся непосредственно под ним. Этот указатель kbdclass получает при подключении к стеку. Т.к. мы договорились рассматривать классический состав стека, следующим в стеке оказывается объект «устройство», принадлежащий драйверу i8042ptr и мы оказываемся в его процедуре диспетчеризации I8xPnP.
PIO_STACK_LOCATION pStack
pStack = IoGetCurrentIrpStackLocation( pIrp )
if pStack->MinorFunction == IRP_MN_QUERY_PNP_DEVICE_STATE {
status = I8xSendIrpSynchronously( TopOfStack, pIrp, FALSE )
pIrp->IoStatus.Information |= PnpDeviceState
pIrp->IoStatus.Status = status
IoCompleteRequest( pIrp, IO_NO_INCREMENT )
i8042ptr также получает указатель на свой блок стека и синхронно перенаправляет IRP следующему (нижестоящему) драйверу acpi, указатель на который хранится в переменной TopOfStack.
IN PDEVICE_OBJECT pDeviceObject,
KeSetEvent( pEvent, 0, FALSE ) // Four-F: It’s not good to signal event unconditionaly.
return STATUS_MORE_PROCESSING_REQUIRED
I8xSendIrpSynchronously (
IN PDEVICE_OBJECT pDeviceObject,
KeInitializeEvent( &event, SynchronizationEvent, FALSE )
IoCopyCurrentIrpStackLocationToNext( pIrp )
IoSetCompletionRoutine( pIrp, I8xPnPComplete, &Event, TRUE, TRUE, TRUE )
status = IoCallDriver( pDeviceObject, pIrp )
if status == STATUS_PENDING {
KeWaitForSingleObject( &Event, Executive, KernelMode, FALSE, NULL )
status = pIrp->IoStatus.Status
Разбирать функции I8xSendIrpSynchronously и I8xPnPComplete я не буду, т.к. они реализуют ту же логику работы, что и наши QueryPnpDeviceState и IrpComplete. Разобравшись с кодом нашего драйвера, вы без труда поймете, как работают эти две функции.
По возвращении из I8xSendIrpSynchronously, драйвер i8042ptr добавляет в поле Information свою порцию флагов из переменной PnpDeviceState и завершает IRP, вызовом IoCompleteRequest.
Ну, и, наконец, процедура диспетчеризации драйвера acpi будет у нас выглядеть так (на самом деле всё гораздо сложнее):
IN PDEVICE_OBJECT pDeviceObject,
pIrp->IoStatus.Information |= PNP_DEVICE_NOT_DISABLEABLE
pIrp->IoStatus.Status = STATUS_SUCCESS
IoCompleteRequest( pIrp, IO_NO_INCREMENT )
Теперь рассмотрим случай, когда обработка IRP будет синхронной, т.е. пройдет в контексте одного и того же потока. Все драйверы в стеке завершают IRP немедленно и, соответственно, ни одна из процедур диспетчеризации не возвращает STATUS_PENDING. Будем пользоваться схемой на рис. 15-7. Нарисовав эту схему, я был приятно удивлен тем, насколько хорошо видны на ней некоторые совсем неочевидные вещи.
Рис. 15-7. Этапы обработки IRP.
Наш драйвер QueryPnpDeviceState создает IRP, инициализирует объект «событие», на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения IrpComplete и посылает IRP драйверу kbdclass.
Драйвер kbdclass перенаправляет IRP нижестоящему драйверу i8042prt, не устанавливая процедуру завершения.
&ThreadListEntry : 83887018
IoStatus.Status : C00000BB
IoStatus.Information : 00000000
CurrentLocation : <b>04</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>838870E4</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
StackLocation 3 at 838870C0:
CurrentStackLocation at <b>838870E4</b>:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852CA0
CompletionRout * : 00000000
StackLocation 5 at 83887108:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852AB0
CompletionRout * : ED5E14C0
Драйвер i8042prt инициализирует объект «событие», на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения I8xPnpComplete и передаёт IRP нижестоящему драйверу acpi.
&ThreadListEntry : 83887018
IoStatus.Status : C00000BB
IoStatus.Information : 00000000
CurrentLocation : <b>03</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>838870C0</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
CurrentStackLocation at <b>838870C0</b>:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852CA0
CompletionRout * : ED09043F
StackLocation 4 at 838870E4:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852CA0
CompletionRout * : 00000000
StackLocation 5 at 83887108:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852AB0
CompletionRout * : ED5E14C0
Драйвер acpi завершает IRP (возможно предварительно разослав его каким-то другим драйверам), вызывая IoCompleteRequest.
Функция IoCompleteRequest начинает завершение IRP. Смотрит в блок стека принадлежащий драйверу acpi. Не найдя там флага SL_PENDING_RETURNED (драйвер acpi не вызывал макрос IoMarkIrpPending), не устанавливает поле IRP.PendingReturned. Находит указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt и вызывает её.
&ThreadListEntry : 83887018
IoStatus.Status : 00000000 <- STATUS_SUCCESS
IoStatus.Information : 00000020 <- PNP_DEVICE_NOT_DISABLEABLE
CurrentLocation : <b>04</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>838870E4</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
StackLocation 3 at 838870C0:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 00 <- обнулено ZeroIrpStackLocation
Control : 00 <- обнулено ZeroIrpStackLocation
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 818A64F0
CompletionRout * : ED09043F
CurrentStackLocation at <b>838870E4</b>:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852CA0
CompletionRout * : 00000000
StackLocation 5 at 83887108:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 14 IRP_MN_QUERY_PNP_DEVICE_STATE
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852AB0
CompletionRout * : ED5E14C0
Процедура завершения I8xPnpComplete совершенно напрасно сигналит событие (драйвер i8042prt не ждет и не будет ждать на этом событии) и возвращает код STATUS_MORE_PROCESSING_REQUIRED.
Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера acpi.
Драйвер acpi возвращает код STATUS_SUCCESS, и мы выходим из функции IoCallDriver в драйвере i8042prt.
Увидев, что возвращенный из IoCallDriver код не STATUS_PENDING, драйвер i8042prt не ждет на событии. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. устанавливал процедуру завершения, которая прервала обработку IRP. Поскольку драйвер i8042prt прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, то должен возобновить этот процесс. Что он и делает вызовом IoCompleteRequest.
Выше мы выяснили, что завершать IRP два раза нельзя. Здесь же мы видим уже второй вызов IoCompleteRequest. Есть ли тут противоречие? Нет. Завершение IRP — это не просто вызов IoCompleteRequest. Это многоэтапный процесс. На каждом этапе он может быть прерван и возобновлен вновь. Только когда все эти этапы будут пройдены, IRP считается завершенным.
Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В блоке стека драйвера i8042prt нет флага SL_PENDING_RETURNED (драйвер i8042prt тоже не вызывал макрос IoMarkIrpPending). Поэтому IRP.PendingReturned опять обнуляется. IoCompleteRequest не находит указатель на процедуру завершения в блоке стека драйвера i8042prt и переходит к предыдущему и последнему блоку стека драйвера kbdclass. kbdclass тоже не использовал макрос IoMarkIrpPending и IRP.PendingReturned опять обнуляется. В блоке стека драйвера kbdclass имеется указатель на нашу процедуру завершения IrpComplete, которая и вызывается.
Вспомните, что при передаче IRP нижестоящему драйверу, драйвер kbdclass скопировал свой блок стека в следующий, использую макрос IoCopyCurrentIrpStackLocationToNext. Однако этот макрос не копирует поля связанные с процедурой завершения. Если бы он этого не сделал, то указатель на нашу процедуру завершения (он находится в блоке стека драйвера kbdclass) попал бы в блок стека драйвера i8042prt, и наша процедура завершения была бы вызвана дважды. В стародавние времена, когда ещё не было макроса IoCopyCurrentIrpStackLocationToNext, программисты вручную копировали блоки стека, иногда забывая обнулить поля связанные с процедурой завершения, что приводило к трудно находимым багам.
&ThreadListEntry : 83887018
IoStatus.Status : 00000000
IoStatus.Information : 00000020
CurrentLocation : <b>06</b>
Overlay : 00000000 00000000
CancelRoutine * : 00000000
&DeviceQueueEntry : 83887048
AuxiliaryBuffer * : 00000000
CurrentStackLoc * : <b>8388712C</b>
OrigFileObject * : 00000000
StackLocation 1 at 83887078:
StackLocation 2 at 8388709C:
StackLocation 3 at 838870C0:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 00 <- обнулено ZeroIrpStackLocation
Control : 00 <- обнулено ZeroIrpStackLocation
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 818A64F0
CompletionRout * : ED09043F
StackLocation 4 at 838870E4:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 00 <- обнулено ZeroIrpStackLocation
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852CA0
CompletionRout * : 00000000
StackLocation 5 at 83887108:
MajorFunction : 1B IRP_MJ_PNP
MinorFunction : 00 <- обнулено ZeroIrpStackLocation
Control : 00 <- обнулено ZeroIrpStackLocation
Others : 00000000 00000000 00000000 00000000
DeviceObject * : 81852AB0
CompletionRout * : ED5E14C0
CurrentStackLocation at <b>8388712C</b>:
<заполнен нулями> <- недействительный блок стека
Наша процедура завершения несколько умнее. Видя, что поле PendingReturned равно нулю, она понимает, что нижестоящий драйвер не возвращал STATUS_PENDING, а значит, процедура диспетчеризации драйвера QueryPnpDeviceState не ждет на событии. Поэтому и сигналить его нет смысла. Мы установили процедуру завершения только для того, чтобы удалить, созданный нами IRP. Можем сделать это прямо сейчас, вызвав IoFreeIrp. Поскольку IRP больше нет, мы должны остановить его завершение, вернув код STATUS_MORE_PROCESSING_REQUIRED.
Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера i8042prt. Вот здесь очень хорошо видно, почему после вызова IoCompleteRequest нельзя обращаться к IRP. Ведь возможно IRP уже не существует, и узнать это драйвер вызывающий IoCompleteRequest не может. Обратите внимание на то, что функция IoCompleteRequest не возвращает никакого значения.
Правило:
После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.
Процедура диспетчеризации драйвера i8042prt возвращает код, который вернула вызванная им IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в драйвере kbdclass. И опять здесь хорошо видно, почему после вызова IoCallDriver нельзя обращаться к IRP, если, конечно, не устанавливать процедуру завершения и не прерывать завершение IRP. Ведь IRP то уже не существует. Драйвер kbdclass отказался от установки процедуры завершения, а значит, после вызова IoCallDriver полностью потерял контроль над IRP. Кто и когда завершит IRP драйвер kbdclass не узнает, а значит, не может делать никаких предположений о том, существует ли IRP до сих пор или его уже нет. Драйвер i8042prt смог обратиться к IRP после вызова IoCallDriver только потому, что его процедура завершения прервала процесс завершения IRP, а драйвер kbdclass не может.
Правило:
Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.
Процедура диспетчеризации драйвера kbdclass возвращает код, который вернула, вызванная им, IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в нашем драйвере QueryPnpDeviceState.
Видя, что возвращенный из IoCallDriver код не STATUS_PENDING, мы не ждем на событии. Хотя мы и установили процедуру завершения, и она вернула STATUS_MORE_PROCESSING_REQUIRED, но трогать IRP после возвращения из IoCallDriver всё равно не можем. Это исключение из правил, т.к. мы являемся создателем IRP. Надеюсь, здесь это очевидно. Мы же сами удалили IRP в процедуре завершения и прекратили его дальнейшее завершение.
Теперь поставим на место драйвера acpi драйвер unknown и представим, что он откладывает завершение IRP и возвращает из своей процедуры диспетчеризации STATUS_PENDING. Т.е. обработка IRP будет асинхронной.
Т.к. драйвер unknown откладывает завершение IRP, то, используя макрос IoMarkIrpPending, заносит в свой блок стека флаг SL_PENDING_RETURNED, ставит IRP в очередь и возвращает STATUS_PENDING. Мы выходим из функции IoCallDriver в драйвере i8042prt. Увидев код STATUS_PENDING, драйвер i8042prt начинает ждать освобождения события и текущий поток блокируется.
Через некоторое время в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown достает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt, вызывает её. Процедура завершения I8xPnpComplete сигналит событие и возвращает код STATUS_MORE_PROCESSING_REQUIRED, что заставляет функцию IoCompleteRequest прекратить работу и вернуться туда, откуда она была вызвана.
Ожидающий на событии поток пробуждается. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, и совершенно точно знает, что IRP ещё не завершен. Это он и делает, для того чтобы узнать код, с которым завершился отложенный IRP (см. исходный код функции I8xSendIrpSynchronously). Этот код драйвер извлекает из поля IRP.IoStatus.Status и из своей процедуры диспетчеризации будет возвращать именно его, а не первоначальный STATUS_PENDING. Затем драйвер i8042prt возобновляет завершение IRP, вызовом IoCompleteRequest.
Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В этом блоке стека нет флага SL_PENDING_RETURNED… Точнее говоря, его там быть не должно, но взгляните на исходный код функции I8xPnPComplete из 2000 DDK. Вы увидите там такие строки:
IN PDEVICE_OBJECT pDeviceObject,
<FONT color=»red»> if pIrp->PendingReturned {
IoMarkIrpPending( pIrp ) // Four-F: Do not do this if you return
// STATUS_MORE_PROCESSING_REQUIRED!
KeSetEvent( pEvent, 0, FALSE ) // Four-F: It’s not good to signal event unconditionaly.
return STATUS_MORE_PROCESSING_REQUIRED
В 2003 DDK эти строки уже закомментарены.
IN PDEVICE_OBJECT pDeviceObject,
// Since this completion routines sole purpose in life is to synchronize
// Irp, we know that unless something else happens that the IoCallDriver
// will unwind AFTER the we have complete this Irp. Therefore we should
// NOT bubble up the pending bit.
// if pIrp->PendingReturned {
// IoMarkIrpPending( pIrp )
KeSetEvent( pEvent, 0, FALSE ) // Four-F: It’s not good to signal event unconditionaly.
return STATUS_MORE_PROCESSING_REQUIRED
Две выделенные красным строки должны быть в процедуре завершения, но только если она не возвращает STATUS_MORE_PROCESSING_REQUIRED. Чуть позже увидим почему.
Допустим, мы используем I8xPnPComplete из 2000 DDK и в блоке стека драйвера i8042prt ошибочно присутствует флаг SL_PENDING_RETURNED. Видя это, IoCompleteRequest опять помещает в поле IRP.PendingReturned ненулевое значение. Если вы проанализируете дальнейший ход событий, то увидите, что ненулевое значение в поле IRP.PendingReturned дойдет до нашей процедуры завершения. Увидев не равное нулю поле IRP.PendingReturned, она решит, что нижестоящий драйвер вернул STATUS_PENDING и процедура диспетчеризации QueryPnpDeviceState ждет освобождения события, хотя на самом деле это не так. В данном случае, ничего ужасного не произойдет. Мы просто напрасно просигналим событие и всё. В каком-то другом случае, наверное, возможны более серьёзные последствия, т.к. драйвер будет основывать свои действия на неверных допущениях.
Мы уже несколько раз убеждались в том, что не стоит слепо верить документации DDK. Теперь оказывается, что и исходникам DDK нельзя верить?! Да, к сожалению, это так. Особенно много, скажем так, неоптимальных решений в исходниках 2000 DDK. Тексту этой статьи я тоже, кстати, советую не доверять
Остальные возможные сценарии проанализируйте сами. Я только хочу ещё раз обратить особое внимание на поле IRP.PendingReturned. Во всех источниках, которые мне приходилось видеть, в том числе и в DDK, предназначение этого поля не совсем верно трактуется. Обычно говорится, что это поле сообщает диспетчеру в/в или вышестоящему драйверу о том, что нижестоящий драйвер отмечал IRP как ожидающий завершения (вызывал IoMarkIrpPending и возвращал из процедуры диспетчеризации STATUS_PENDING). Это верно. Также говорится, что якобы если какой-либо драйвер отмечал IRP как ожидающий завершения, то ненулевое значение этого поля так и сохраняется при завершении IRP до самого верха. А вот это уже не совсем так. Функция IoCompleteRequest (и мы с вами тоже должны будем принять в этом участие чуть ниже) действительно старается сохранить состояние этого поля, но только если она не встретит процедуру завершения. Зачем это нужно? В только что рассмотренном нами сценарии с драйвером unknown вместо acpi, обработка IRP до того как он опустился до драйвера i8042prt, была синхронной (проходила в контексте одного и того же потока). После того, как драйвер unknown вернул из процедуры диспетчеризации STATUS_PENDING, обработка IRP стала асинхронной (процедура завершения драйвера i8042prt вызывается в контексте случайного потока, а процедура диспетчеризации драйвера i8042prt ждет события в контексте первоначального потока). Дождавшись освобождения события, процедура диспетчеризации драйвера i8042prt продолжает обработку IRP в контексте первоначального потока, и обработка IRP опять становится синхронной. Вот тут собака и зарыта. Все драйверы находящиеся выше i8042prt вообще не должны знать, что драйвер unknown откладывал завершение IRP. Это проблема драйвера i8042prt и он сам её решил. Для всех вышестоящих драйверов всё как было синхронным, так и осталось. На участке между драйверами unknown и i8042prt поле IRP.PendingReturned будет содержать ненулевое значение, а на участке выше драйвера i8042prt оно обнулится, т.к. обработка IRP вновь стала синхронной и никто никого не ждет. Надеюсь, что понятно объяснил и нигде не ошибся
Ну, хорошо, все процедуры завершения, которые мы видели до сих пор, возвращали STATUS_MORE_PROCESSING_REQUIRED. Но, как мы выяснили выше, это не единственно возможный код возврата. Этот код процедуры завершения возвращают в одном из трех случаев:
- Драйвер-создатель IRP вновь хочет увидеть своё чадо, для того чтобы его… скажем мягко, освободить (пример — наш драйвер) или повторно использовать;
- Драйвер хочет синхронизировать обработку IRP (пример — драйвер i8042prt);
- Т.к. процедура завершения может вызываться на повышенном IRQL, драйвер хочет сделать какую-то дополнительную обработку на PASSIVE_LEVEL в своей процедуре диспетчеризации.
Если же драйверу не нужна такая функциональность, но перехватить IRP на обратном пути всё же требуется (например, для того, чтобы посмотреть считанные с диска данные или код нажатой клавиши, что мы и будем делать в следующей статье) и всю обработку драйвер может сделать в процедуре завершения, даже на уровне DISPATCH_LEVEL, то тогда процедуре завершения не требуется прерывать завершение IRP и можно вернуть STATUS_SUCCESS или ContinueCompletion (что одно и то же).
В этом случае процедура завершения может выглядеть примерно так:
JustComplete proc uses esi edi ebx pDeviceObject:PDEVICE_OBJECT, pIrp:PIRP, pContext:PVOID
.if [esi].IoStatus.Status == STATUS_SUCCESS
mov edi, [esi].AssociatedIrp.SystemBuffer
; Что-то делаем с данными
.if [esi].PendingReturned
Самое важное здесь, в контексте нашего разговора, это вызов макроса IoMarkIrpPending в случае, если поле IRP.PendingReturned не равно нулю. Выше мы разобрались, что IoCompleteRequest как бы «перекладывает» флаг SL_PENDING_RETURNED из текущего блока стека в поле PendingReturned самого IRP и наоборот, если в блоке стека нет процедуры завершения, а поле PendingReturned не равно нулю, то вызывает макрос IoMarkIrpPending. Короче говоря, IoCompleteRequest пытается донести до первой встретившейся ей процедуры завершения, тот факт, что какой-то нижестоящий драйвер отмечал IRP как ожидающий завершения. Когда IoCompleteRequest находит процедуру завершения, то возлагает эту задачу на неё (см. исходный код IoCompleteRequest, а лучше блок-схему).
Представим, что вместо драйвера acpi у нас драйвер unknown и процедура завершения I8xPnPComplete драйвера i8042prt похожа на процедуру JustComplete, т.е. не сигналит событие и возвращает код STATUS_SUCCESS. Соответственно, процедура диспетчеризации драйвера i8042prt никакого события не инициализирует и не ждет, а просто возвращает тот код, который вернет IoCallDriver.
Драйвер unknown вызывает макрос IoMarkIrpPending, ставит IRP в очередь и возвращает STATUS_PENDING. Этот код «поднимается» до нашей процедуры диспетчеризации и мы начинаем ждать.
Некоторое время спустя, в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown извлекает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения JustComplete вышестоящего драйвера i8042prt, вызывает её (повторяю, мы заменили код на JustComplete). Сделав свои дела, процедура завершения JustComplete видит, что поле IRP.PendingReturned не равно нулю и, вызовом макроса IoMarkIrpPending, кладет в свой блок стека флаг SL_PENDING_RETURNED. Функция IoCompleteRequest делает то же самое в ветке else, но т.к. IoCompleteRequest встретила процедуру завершения, то эта задача перекладывается на неё. Т.к. процедура завершения I8xPnpComplete возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, функция IoCompleteRequest продолжает «подниматься» по блокам стека. Сделав дальнейший анализ, вы увидите, что информация о том, что IRP отмечался как ожидающий завершения в виде ненулевого значения в поле IRP.PendingReturned благополучно доходит до нашей процедуры завершения. Наша процедура завершения понимает, что процедура диспетчеризации QueryPnpDeviceState ждет на событии, сигналит его и всё заканчивается благополучно.
А если вы также проанализируете, что будет, если процедура завершения JustComplete забудет должным образом воспользоваться макросом IoMarkIrpPending, то придете к ещё одному правилу.
Правило:
Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом.
if pIrp->PendingReturned {
IoMarkIrpPending( pIrp )
}
Ну и последнее. Т.к. у процедуры завершения нет другой возможности узнать, с каким кодом нижестоящий драйвер завершает IRP, кроме как обратиться к полю IRP.IoStatus.Status, мы запишем последнее правило.
Правило:
Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.
Начиная писать эту «бесконечную» статью я планировал ещё рассказать о том, какую логику использует диспетчер в/в при обработке IRP, т.к. чаще всего именно он является создателем IRP, но чувствую, что силы покидают меня. Если этот вопрос вас интересует, то рекомендую почитать статью «How Windows NT Handles I/O Completion» в IFS KIT или «The NT Insider» ( http://www.osronline.com/ ). К сожалению, исходного кода диспетчера в/в вы там не найдете, но общее представление получите.
Что вы должны делать и чего вы делать не должны
Подведем итог.
Правило 1:
Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.
Правило 2:
После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.
Правило 3:
Завершать IRP с кодом STATUS_PENDING нельзя.
Правило 4:
Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.
Правило 5:
Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.
Правило 6:
Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом.
if pIrp->PendingReturned {
IoMarkIrpPending( pIrp )
}
Некоторые из этих правил, наверное, можно нарушить, если очень хорошо представлять себе, все детали механизма обработки IRP. Если такого представления нет, то лучше следовать им неукоснительно.
В следующий раз мы попробуем применить кое-какие полученные сегодня знания на практике.
Исходный код драйвера в архиве.
© Four-F
В конце концов, все мы люди, а людям, как известно…На чтение 8 мин. Просмотров 1.7k. Опубликовано 03.09.2019
Windows – это сложная операционная система, обслуживающая миллионы ПК по всему миру и работающая на тысячах различных аппаратных комбинаций, что может сделать ее довольно интересной для инженеров Microsoft.
К сожалению, эта сложность также означает, что неизбежны ошибки из-за различных причин, которые трудно диагностировать. Одной из таких проблем является ошибка MULTIPLE_IRP_COMPLETE_REQUESTS на синем экране. Синий экран появляется как последнее средство – когда ОС не знает, что еще делать, она решает просто аварийно завершить работу и сообщить пользователю о проблеме.
Эта ошибка может быть вызвана различными причинами, это может быть что угодно, от плохих драйверов до неисправного жесткого диска, поэтому диагностировать это не просто. Однако мы можем дать представление о наиболее распространенных решениях и посмотреть, работают ли они. В прошлом мы исправляли ошибки и предоставляли методы для исправления ошибки NTFS_File_System в Windows 10, поэтому вы можете ожидать, что эти решения будут работать на вас. Если этого не произойдет, вам, возможно, придется продолжить поиск лучшего решения.
Содержание
- Исправьте MULTIPLE_IRP_COMPLETE_REQUESTS Windows 10
- Решение 1. Проверьте свой антивирус
- Решение 2. Использование средства проверки системных файлов
- Решение 3 – Запустите CHKDSK, чтобы исправить это
- Решение 4 – Обновите ваши драйверы
- Решение 5 – Удалить проблемное программное обеспечение
- Решение 6 – Сброс вашего BIOS по умолчанию
- Решение 7 – Обновите свой BIOS
Исправьте MULTIPLE_IRP_COMPLETE_REQUESTS Windows 10
MULTIPLE_IRP_COMPLETE_REQUESTS – ошибка синего экрана, и она может быть довольно проблематичной. Говоря об ошибках такого рода, вот некоторые похожие проблемы, о которых сообщили пользователи:
- Multiple_irp_complete_requests синий экран смерти – Это ошибка синего экрана, и если вы столкнетесь с ней, вы сможете исправить ее с помощью одного из наших решений.
- Multiple_irp_complete_requests ntoskrnl.exe, classpnp.sys, wdf01000.sys, hal.dll, usbport.sys, acpi.sys, ntfs.sys, nvlddmkm.sys – Иногда определенный файл может вызывать эту ошибку , Чтобы решить эту проблему, вам нужно немного изучить и выяснить, как этот файл связан с вашим оборудованием или программным обеспечением. Как только вы обнаружите проблемное оборудование или программное обеспечение, проблема должна быть решена.
- Multiple_irp_complete_requests Windows 10, Windows Server 2003, Windows Server 2008 r2 . Эта ошибка может возникать в других версиях Windows, но даже если вы не используете Windows 10, вы сможете применить некоторые из наших решения для этого.
Решение 1. Проверьте свой антивирус
В некоторых случаях ваш антивирус может вызвать ошибку MULTIPLE_IRP_COMPLETE_REQUESTS, и для ее устранения рекомендуется проверить настройки антивируса. Иногда определенные функции вашего антивируса могут вызывать эту проблему, и для ее устранения вам просто нужно отключить эти функции.
Если отключение этих функций не помогает, возможно, вам придется полностью отключить антивирус. В некоторых случаях вам, возможно, даже придется полностью удалить антивирус и проверить, решает ли это проблему.
Если отключение антивируса не помогло устранить проблему, следующим шагом будет полное удаление антивируса. Помните, что Windows 10 имеет Защитник Windows в качестве антивируса по умолчанию, поэтому даже если вы удалите антивирус, у вас все равно будет какая-то базовая защита.
После того, как вы удалите антивирус, проверьте, сохраняется ли проблема. Если нет, возможно, стоит подумать о переходе на другое антивирусное решение. На рынке есть много отличных антивирусных инструментов, но если вам нужен надежный антивирус, который не мешает вашей системе, вам следует рассмотреть возможность использования BullGuard .
- ПРОЧИТАЙТЕ ТАКЖЕ: Исправлено: ОШИБКА ПРОЦЕССА СОСТОЯНИЯ СИСТЕМЫ В Windows 10
Решение 2. Использование средства проверки системных файлов
По словам пользователей, иногда это может привести к повреждению системных файлов. Однако вы можете решить эту проблему, просто выполнив сканирование SFC. Для этого просто выполните следующие действия:
-
Запустите Командную строку от имени администратора. Для этого просто нажмите клавишу Windows + X и выберите Командная строка (Admin) или PowerShell (Admin) .
-
Теперь выполните команду sfc/scannow .
- Начнется сканирование SFC. Это сканирование может занять около 15 минут, поэтому не мешайте ему.
После того, как сканирование завершено, убедитесь, что проблема все еще существует. Если проблема все еще существует или вы вообще не смогли запустить сканирование SFC, мы рекомендуем вам попробовать сканирование DISM. Для этого просто выполните следующие действия:
- Откройте Командную строку в качестве администратора.
-
Теперь введите команду DISM/Online/Cleanup-Image/RestoreHealth и нажмите Enter , чтобы запустить ее.
- Сканирование DISM начнется. Имейте в виду, что это сканирование может занять около 20 минут, поэтому не вмешивайтесь в него.
После того, как оба сканирования завершены, проверьте, сохраняется ли проблема.
Решение 3 – Запустите CHKDSK, чтобы исправить это
Использование CHKDSK для исправления этой ошибки – это еще один способ, поскольку он может легко исправить многие типы ошибок, включая ошибки, такие как KERNEL_DATA_INPAGE_ERROR в Windows 10. Давайте посмотрим, как запустить эту команду для исправления этой конкретной ошибки.
- Откройте Командную строку от имени администратора. Чтобы увидеть, как это сделать правильно, проверьте наше предыдущее решение.
-
Когда откроется Командная строка , введите chkdsk/f: X и нажмите Enter . Конечно, замените X буквой, обозначающей ваш системный диск. В большинстве случаев это будет C.
- Вас попросят запланировать сканирование, поэтому нажмите Y , чтобы сделать это.
Теперь вам просто нужно перезагрузить компьютер и позволить ему сканировать системный диск. Этот процесс может занять около 20-30 минут, но после его завершения проблема должна быть полностью решена.
- ЧИТАЙТЕ ТАКЖЕ: Исправлено: ошибка BUGCODE USB DRIVER в Windows 10
Решение 4 – Обновите ваши драйверы
Еще одной причиной для MULTIPLE_IRP_COMPLETE_REQUESTS могут быть ваши драйверы. Иногда эта проблема может быть вызвана устаревшими драйверами, и лучший способ решить эту проблему – обновить все основные драйверы на вашем компьютере.
Обычно это ваша видеокарта, драйверы сети и чипсета. Для этого просто посетите веб-сайт производителя оборудования и загрузите последние версии драйверов для вашего устройства. Делать это вручную может быть немного утомительно, так как вам нужно загрузить каждый драйвер вручную.
Однако вы можете использовать такие инструменты, как TweakBit Driver Updater , чтобы обновить все ваши драйверы всего парой кликов. Этот инструмент автоматически обновит ваши драйверы для вас, поэтому вам не придется искать их вручную.
Как только ваши драйверы обновятся, проверьте, сохраняется ли проблема.
Решение 5 – Удалить проблемное программное обеспечение
Иногда сторонние приложения могут мешать работе вашей системы и вызывать ошибку MULTIPLE_IRP_COMPLETE_REQUESTS. По словам пользователей, такие приложения, как LogMeIn Hamachi , AsRock, и EasyTune , могут вызывать эту проблему.
Если вы используете какое-либо из этих приложений, мы советуем вам удалить их и проверить, решает ли это проблему. Хотя вы можете удалить эти приложения с помощью приложения «Настройки», мы настоятельно рекомендуем использовать программное обеспечение для удаления, такое как Revo Uninstaller , чтобы удалить их.
Программное обеспечение Uninstaller предназначено для полного удаления всех файлов и записей реестра, связанных с приложением, которое вы пытаетесь удалить. В результате приложение будет полностью удалено, и не останется доступных файлов, которые могли бы помешать работе вашей системы.
Имейте в виду, что другие приложения также могут вызывать эту проблему, поэтому обязательно выполните детальный осмотр вашей системы.
- ЧИТАЙТЕ ТАКЖЕ: Исправлено: код ошибки 0x80246017 при загрузке Windows 10 Preview Build
Решение 6 – Сброс вашего BIOS по умолчанию
В некоторых случаях ваши настройки BIOS могут вызвать ошибку MULTIPLE_IRP_COMPLETE_REQUESTS. Обычно это вызвано вашими настройками, но вы можете решить проблему, просто сбросив BIOS по умолчанию.
Это довольно просто сделать, и вам просто нужно войти в BIOS и выбрать опцию для загрузки настроек по умолчанию. Эта процедура может отличаться в зависимости от версии BIOS, которую вы используете, поэтому, чтобы увидеть, как правильно войти и сбросить BIOS до значения по умолчанию, мы рекомендуем вам ознакомиться с руководством по материнской плате для получения подробных инструкций.
Решение 7 – Обновите свой BIOS
Другой способ исправить ошибку MULTIPLE_IRP_COMPLETE_REQUESTS – обновить BIOS. Прежде чем начать, мы должны упомянуть, что обновление BIOS может быть рискованной процедурой, поэтому, если вы решите обновить его, имейте в виду, что вы делаете это на свой страх и риск.
Мы уже написали краткое руководство о том, как прошить BIOS, но так как это всего лишь общее руководство, мы советуем вам ознакомиться с руководством по материнской плате для получения подробных инструкций по обновлению BIOS.
Обязательно внимательно следуйте инструкциям в руководстве по эксплуатации, чтобы избежать нанесения непоправимого ущерба вашей системе. После обновления BIOS проверьте, не устранена ли проблема.
Эти решения должны, по крайней мере, помочь вам выяснить, что именно происходит с Windows, а в некоторых случаях также решить эти проблемы. Windows – сложная операционная система, поэтому трудно сказать, что именно вызывает все проблемы.
Примечание редактора . Этот пост был первоначально опубликован в марте 2016 года и с тех пор был полностью переработан и обновлен для обеспечения свежести, точности и полноты.
Драйверы режима ядра: Часть 15 : Жизненный цикл IRP
Драйверы режима ядра: Часть 15 : Жизненный цикл IRP — Архив WASM.RU
В этой и следующей статье мы рассмотрим принципы фильтрации (перехвата) пакетов запроса в/в (IRP). Для чего нужно перехватывать чужие IRP? Применений этому много. Например, захотелось нам посмотреть, к каким файлам обращается та или иная программа. Что мы сделаем в первую очередь? Правильно — запустим FileMon ( sysinternals.com ), который установит драйвер-фильтр на файловую систему. А поскольку обращение к файлам — это фактически формирование соответствующих IRP (быстрый в/в, при котором формирования IRP не происходит, не в счет) и посылка их драйверам файловой системы, то прежде чем добраться до адресата, IRP попадет в фильтр и FileMon зафиксирует это обращение, после чего перешлет его адресату. При этом воздействовать на перехватываемые пакеты FileMon не может. Его задача — только регистрировать факт посылки IRP. Другой пример. Допустим, вам понадобилось скрыть, например, от ваших ближайших родственников или коллег по работе, наличие некоторых файлов фривольного содержания. Недолго думая, вы наберете в google что-то вроде «Hide Files And Folders» и тут же найдете кучку программ, позволяющих скрывать отдельные файлы и каталоги. Это возможно благодаря тому же самому механизму фильтрации IRP. Получая доступ к пакету, драйвер-фильтр имеет возможность модифицировать передаваемые в нём данные, как на пути к файловой системе, так и обратно. Разумеется, фильтровать можно не только IRP передающиеся в файловую систему, но и любые другие. Фильтрация IRP — это общий и универсальный механизм. Антивирусные мониторы, файерволы, на лету компрессоры/декопрессоры крипторы/декрипторы и т.д. и т.п. используют механизм фильтрации IRP. Фильтр, который мы напишем в следующий раз, будет отслеживать IRP, связанные с клавиатурным вводом.
Фильтрация пакетов запроса в/в — достаточно сложная тема. Поэтому, прежде чем перейти к практической реализации потребуется хотя бы минимальная теоретическая подготовка. Как минимум, надо четко представлять себе жизненный цикл IRP от «рождения до смерти». В этой статье мы, в основном, и будем заниматься исследованием этого вопроса. Поскольку драйверы, обслуживающие клавиатуру, в полной мере поддерживают механизм Plug And Play, то придется, в минимальном объеме, осветить и этот вопрос. При этом наш фильтр не будет драйвером Plug And Play. Это будет по-прежнему унаследованный (legacy), в терминологии Microsoft, драйвер, но подключать мы его будем к Plug And Play драйверу.
Ввиду сложности темы, мне вряд ли удастся осветить этот вопрос со всех сторон. Много дополнительной информации можно получить из раздела DDK «Handling IRPs». В Installable File System Kit (IFS KIT), являющийся надмножеством обычного DDK, имеется также раздел «OSR Technical Articles» куда вошли статьи подготовленные командой Open System Resources ( http://www.osr.com/ ). Если в вашем распоряжении только обычный DDK, то большую часть этих статей, если не все, а также много дополнительной информации можно найти в онлайновом журнале «The NT Insider» ( http://www.osronline.com/ ).
Общая классификация драйверов WDM
Все Plug And Play драйверы должны соответствовать модели драйверов Windows (Windows Driver Model, WDM). В соответствии с этой моделью драйверы подразделяются на три типа:
- Драйверы шин (Bus Drivers). Управляют логическими или физическими шинами. Отвечают за распознавание устройств, подключение их к управляемой ими шине и оповещение о них диспетчера PnP.
- Функциональные драйверы (Function Drivers). Управляют конкретным типом устройств. Экспортируют рабочий интерфейс устройства операционной системе.
- Драйверы фильтров (Filter Drivers). Занимая более высокий логический уровень, чем функциональные драйверы, добавляют функциональность или изменяют поведение устройства либо другого драйвера. Этот тип драйверов не обязателен для нормальной работы устройства.
Драйверы фильтров, в свою очередь, подразделяются на:
- Драйверы фильтров шин (Bus Filter Drivers).
- Низкоуровневые драйверы фильтров (Lower-Level Filter Drivers).
- Высокоуровневые драйверы фильтров (Upper-Level Filter Drivers).
Как вы знаете, каждый драйвер должен создать, как минимум, один объект «устройство», которым он будет управлять. Объекты «устройство» WDM также делит на типы:
- Объект «физическое устройство» (Physical Device Object, PDO) — Создается драйвером шины по заданию диспетчера PnP, когда драйвер шины, перечисляя устройства на своей шине, сообщает о наличии какого-либо устройства. PDO представляет физический интерфейс устройства.
- Объект «функциональное устройство» (Functional Device Object, FDO) — Создается функциональным драйвером, который загружается диспетчером PnP для управления обнаруженным устройством. FDO представляет логический интерфейс устройства.
- Необязательная группа объектов «устройство-фильтр» (Filter Device Object, FiDO). Одна группа таких объектов размещается между PDO и FDO (эти объекты создаются драйверами фильтров шин), вторая — между первой группой FiDO и FDO (эти объекты создаются низкоуровневыми драйверами фильтров), а третья — над FDO (эти объекты создаются высокоуровневыми драйверами фильтров).
Дерево устройств
Имея вышеозначенную классификацию, начнем с того, что определимся, каким образом система, точнее говоря, диспетчер PnP (PnP Manager) — компонент операционной системы, предназначенный для автоматического распознавания установленных устройств, узнает, какие драйверы необходимы для того или иного устройства. Процесс распознавания включает в себя перечисление устройств при загрузке и обнаружение их добавления или удаления во время работы системы.
Во время загрузки системы диспетчер PnP начинает перечисление устройств с виртуальной шины под именем Root. В качестве виртуального драйвера, обслуживающего эту шину, выступает сама система. Логически, всё устройства (физические и виртуальные) подключены к этой шине. Виртуальный драйвер корневой шины (и драйверы других шин тоже) извлекает необходимую информацию из реестра. В реестр сведения об оборудовании заносятся ещё на этапе установки операционной системы. Программа установки обнаруживает установленные устройства и, используя информационные файлы (INF Files), заполняет соответствующие разделы реестра. Перечисляя устройства на корневой шине, её виртуальный драйвер обнаруживает другие шины (физические и виртуальные), например, физическую шину PCI. На основе данных реестра диспетчер PnP определяет, установлен ли в системе драйвер, способный управлять обнаруженным устройством. Если такой драйвер установлен, диспетчер PnP указывает диспетчеру ввода-вывода (I/O Manager) загрузить его. Если подходящий драйвер не установлен, диспетчер PnP пытается его установить. При этом если не обнаружится соответствующего информационного файла или других необходимых файлов, диспетчер PnP взаимодействует с пользователем, который должен указать месторасположение необходимых компонентов. Будучи загруженным, драйвер, обслуживающий обнаруженную шину, перечисляет подключенные к ней устройства. При этом он может обнаружить другие дополнительные шины. Если для работы устройства, обнаруженного на шине, необходим драйвер, он загружается. Такой рекурсивный процесс — перечисление устройств, загрузка драйвера, дальнейшее перечисление — продолжается до тех пор, пока не будут обнаружены и сконфигурированы все устройства в системе. Диспетчер PnP способен обнаруживать добавление/удаление нового устройства и во время работы системы. В результате перечисления образуется так называемое дерево устройств (Device Tree), отражающее иерархические взаимосвязи между всеми установленными в системе устройствами.
Дерево устройств можно просмотреть с помощью диспетчера устройств (Device Manager). Как выглядит дерево устройств на моём компьютере (в меню «Вид» я выбрал «Устройства по подключению» и отметил «Показать скрытые устройства».) показано на Рис. 15.1.
Рис. 15-1. Дерево устройств.
На рисунке вы можете обнаружить некоторые, созданные нами ранее виртуальные устройства, например, ProcessMon (Process creation/destruction monitor), подключенные (также виртуально) к корневой шине. В Windows 2000 диспетчер устройств показывает все установленные ранее виртуальные устройства, а в Windows XP (и в Windows 2003 Server, наверное, тоже) только активные в данный момент. Информация о виртуальных устройствах извлекается диспетчером устройств из разделов реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumRootLEGACY_XXX.
Узлы дерева устройств называются узлами устройств (device nodes или devnodes). Каждый узел обслуживается одним или несколькими драйверами. Каким образом система узнает, какие драйверы, какой узел обслуживают?
Все устройства, обнаруженные в процессе установки системы (а также установленные позже), регистрируются в подразделах реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnum<enumerator><deviceID><instanceID>. Где enumerator — драйвер шины, перечисляющий устройства на шине, deviceID — уникальный идентификатор устройств данного типа, instanceID — уникальный идентификатор экземпляра устройства данного типа (по нему можно различать несколько одинаковых устройств).
В процессе перечисления драйвер шины сообщает диспетчеру PnP идентификаторы обнаруженных устройств: deviceID и instanceID. Используя эту информацию, диспетчер PnP находит в реестре драйверы нужные для узла данного устройства.
Пример подраздела Enum для клавиатуры показан на рис 15-2.
Рис. 15-2. Подраздел реестра ветви Enum для клавиатуры.
Как видно из рисунка, перечислителем является ACPI, идентификатор устройства — PNP0303, а идентификатор экземпляра устройства — 3&13c0b0c5&0. Если заглянуть в %SystemRoot%infkeyboard.inf, то можно обнаружить, что информация в реестр попадает именно из этого информационного файла. К вашей машине, разумеется, может быть подключена клавиатура другого типа.
Функциональный драйвер задается параметром Service. В данном случае это i8042prt. Параметр ClassGUID (Globally Unique Identifier of Class) определяет подраздел класса устройства HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass. Этот подраздел содержит сведения о драйвере класса устройства. Драйвер класса определяет общую функциональность для всех устройств данного типа. Он ничего не знает о том, как управлять конкретным устройством, но, используя стандартизованные сервисы, взаимодействует с функциональным драйвером, который, в свою очередь, знает, как управляет конкретным типом устройств. В данном случае драйвером класса является kbdclass. Он исполняет роль своего рода буфера между функциональным драйвером i8042prt и подсистемой Win32 (подробнее в следующей статье). Пример подраздела Class для клавиатуры показан на рис 15-3.
Рис. 15-3. Подраздел реестра ветви Class для клавиатуры.
Содержимое этих двух разделов дает диспетчеру PnP всю информацию необходимую для загрузки драйверов для узла данного устройства. Имена драйверов указывают на подразделы реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices<drivername>.
Загрузка драйверов для узла устройства происходит в следующем порядке:
- Низкоуровневые драйверы фильтров, указанные в параметрах LowerFilters ветвей реестра Enum и Class.
- Функциональный драйвер, заданный в параметре Service ветви реестра Enum.
- Высокоуровневые драйверы фильтров, указанные в параметрах UpperFilters ветвей реестра Enum и Class.
Стек объектов «устройство»
Всё, вышесказанное не имеет прямого отношения к материалу статьи. Используемый в ней драйвер не является PnP-драйвером, а по-прежнему относится к унаследованным драйверам (legacy drivers). Общее понимание механизма перечисления и знание того, что представляет собой дерево устройств необходимо для ввода следующего, уже непосредственно важного для нас, понятия.
Загружая каждый PnP драйвер, диспетчер PnP вызывает стандартную процедуру драйвера AddDevice. В параметре PhysicalDeviceObject передается указатель на объект «физическое устройство», созданный драйвером шины. Загруженный драйвер, в свою очередь, создает свой объект «устройство» и подключает его к объекту «физическое устройство», вызовом функции IoAttachDeviceToDeviceStack. В эту функцию он передает два указателя: переданный ему диспетчером Pnp указатель на объект «физическое устройство» и указатель на созданный им объект «устройство». При этом новый объект всегда подключается к самому верхнему объекту в этой цепочке, вне зависимости от того, имеется ли над PDO другие объекты или нет. Указатель на объект «физическое устройство», при подключении нового объекта, используется как указатель на цепочку объектов, к которой происходит подключение, а не указатель на конкретный объект «устройство». Функция IoAttachDeviceToDeviceStack сама находит самый верхний объект.
Получившаяся конструкция состоит, как минимум, из двух объектов: объект «физическое устройство», созданный драйвером шины, и объект «функциональное устройство», созданный функциональным драйвером, и называется стеком объектов «устройство» (device stack) или просто стеком. Т.о. каждый узел в дереве устройств представлен своим стеком.
Учитывая всё вышесказанное, и имея содержимое разделов реестра Enum и Class, мы можем предсказать, из каких объектов будет состоять стек для узла устройства «клавиатура» (объекты перечисляются снизу вверх):
- объект «физическое устройство», созданный драйвером шины ACPI.
- объект «функциональное устройство», созданный функциональным драйвером i8042prt.
- объект «устройство-фильтр», созданный высокоуровневым драйвером фильтра nmfilter (NTICE Support File).
- объект «устройство-фильтр», созданный высокоуровневым драйвером фильтра kbdclass.
Оба объекта «устройство-фильтр» созданы высокоуровневыми драйверами фильтров, а драйверов фильтров шины и низкоуровневых драйверов фильтров в данном случае нет.
Просмотреть стеки устройств можно с помощью программы Devide Tree ( osr.com или osronline.com ). Но я избегаю пользоваться этой утилитой, т.к. её работа на трех моих машинах с разными версиями системы неизбежно приводит к появлению «синего экрана смерти» (по крайней мере, в режиме PnP). Удивительно, что эта утилита входит в DDK. Мы воспользуемся более надежной командой !devstack отладчика Kernel Debugger.
Рис. 15-4. Стеки объектов «устройство» для клавиатуры.
На этой машине активна система Terminal Server и у клавиатуры имеется не один, а два стека. Как видите, наши предположения о составе устройств подтвердились. На вашей машине его состав, естественно, может отличаться. Далее мы будем рассматривать классический состав стека для клавиатуры, а именно: Kbdclass сверху, i8042prt посередине, ACPI внизу.
В общем случае стек объектов «устройство» может выглядеть так (см. классификацию драйверов и объектов в WDM выше):
Рис. 15-5. Стек объектов «устройство» для узла устройства (общая схема).
Поскольку каждым объектом «устройство» в стеке управляет драйвер, то очень часто наряду с понятием «стек устройств» употребляют «стек драйверов». Это не совсем верно, но о чём идет речь, надеюсь, понятно. Далее по ходу статьи я тоже буду иногда говорить «стек устройств», и иногда «стек драйверов».
IRP формируется диспетчером в/в или драйвером не принадлежащим стеку и направляется на вершину стека. Если для обработки запроса драйверу требуется помощь нижестоящего драйвера, он перенаправляет IRP ниже по стеку и т.д. IRP всегда идет по стеку сверху вниз. Решение об окончании обработки IRP может быть принято на любом уровне. Мало того, любой драйвер в стеке может сформировать дополнительные IRP (например, разбить запрос чтения из файла на несколько запросов) и разслать его необходимым драйверам. Любой драйвер может отклонить запрос или может модифицировать передаваемые в нем данные. В общем случае, если драйвер получил IRP, то может делать с ним всё что угодно.
Язык с за три минуты
Мне придется использовать исходные коды некоторых системных функций, т.к. по-настоящему разобраться с обработкой IRP без анализа исходного кода, по-моему, невозможно. Эти фрагменты, конечно, не будут истинным кодом операционной системы и будут урезаны, порой весьма значительно. Также опущена вся обработка ошибок: проверки указателей, входных данных и возвращаемых функциями значений, убраны обработчики SEH. Оставлена только самая суть. Для упрощения анализа кода я буду использовать c-подобный псевдоязык (почти чистый с). Вполне допускаю, что вы можете и не знать этого языка, т.к. мы всё же занимаемся разработкой драйверов на ассемблере. Поэтому тезисно приведу базовые конструкции, без которых не обойтись.
На ассемблере место под инициализированную переменную отводится так:
В языке с глобальные и локальные инициализированные переменные определяются так:
Если надо передать адрес переменной в функцию (используя макрос invoke) мы делаем это так:
Программист на с делает это так:
Обратная операция — запись в переменную значения по указателю на переменную — в ассемблере это выглядит так (pwd — указатель на переменную размером в двойное слово):
В с это несколько проще:
Если у нас есть структура FILE_OBJECT, то мы можем записать в её поле DeviceObject указатель на объект «устройство» таким образом:
Программист на с делает это так:
Если же, вместо структуры, в нашем распоряжении указатель на неё, то вышеозначенную операцию нам придется делать примерно так:
Программисту на с, как всегда, немного проще:
Если с-программисту надо увеличить значение переменной на единицу, то он может сделать это, как минимум тремя способами, самый очевидный из которых следующий:
Для уменьшения числа IRP циркулирующих в системе можно сделать это и так:
Такой же трюк можно проделать и с другими тремя математическими операциями. Логические операции тоже можно записывать в такой форме. Например:
Эквивилентно
Но, скажу вам по секрету, есть ещё один способ, которым обычно пользуются только гуру или самые ленивые с-программисты для приращения переменных на единицу:
Такой же трюк можно проделывать и с операцией вычитания.
В дальнейшие подробности вдаваться не будем, этого минимума должно хватить. Также имейте в виду, что в DDK есть полный исходный код драйверов kbdclass и i8042prt. Правда, в разных DDK он немного отличается. Соответственно, отличаются и эти драйверы в разных версиях системы.
Жизненный цикл IRP
Мы уже много раз получали IRP, но ещё ни разу не создавали его сами. Поскольку мы собираемся рассмотреть весь жизненный цикл пакета запроса в/в, то без его создания нам никак не обойтись. С этого и начнем.
Допустим, у нас есть имя объекта «устройство», скажем, DeviceKeyboardClass0. Судя по названию, этот объект имеет какое-то отношение к обслуживанию физического устройства «клавиатура». Для чего этот объект нужен и какова его роль, мы подробнее поговорим в следующей статье. Пока нас интересует только одно: у нас есть имя устройства и мы хотим послать ему какой-нибудь IRP. Это можно сделать вызовом функции IoCallDriver, прототип которой выглядит так:
Несмотря на название функции, первым аргументом является указатель на объект «устройство», а не «драйвер», которому адресован IRP. Обрабатывать же IRP будет, естественно, драйвер, это устройство создавший. Второй параметр — указатель на сам пакет запроса в/в.
Получить указатель на нужное нам устройство по его имени мы можем с помощью IoGetDeviceObjectPointer. В случае успеха, эта функция вернёт даже два указателя: один — собственно указатель на нужное нам устройство в переменной pTargetDeviceObject, а второй — указатель на объект «файл» ассоциированный с этим устройством в переменной pTargetFileObject. Откуда взялся объект «файл»? Заглянем внутрь функции IoGetDeviceObjectPointer, а также двух других, которые она вызывает.
Первым делом, функция IoGetDeviceObjectPointer получает описатель объекта «файл» (представлен структурой FILE_OBJECT).
Вспомните, как в программе управления драйвером мы получаем описатель для взаимодействия с его устройством. Мы вызываем функцию CreateFile, которая создает объект «файл», представляющий не собственно файл на диске, а виртуальное устройство (структура DEVICE_OBJECT), созданное драйвером. Т.е. на самом деле, описатель файла используется для ввода-вывода в устройство. Такая схема нужна, во-первых, для разграничения прав доступа, т.к. в структуре DEVICE_OBJECT нет, например, полей WriteAccess и SharedRead, а в FILE_OBJECT такие поля есть, во-вторых, в объекте «файл» можно хранить некоторые другие атрибуты операции ввода-вывода. Адрес истинного получателя пакета запроса в/в, в нашем случае, находится в поле FILE_OBJECT.DeviceObject. Итак, вызов ZwOpenFile, так же как и CreateFile, приводит к созданию объекта «файл», а значит формированию IRP типа IRP_MJ_CREATE и посылке его целевому устройству (в нашем случае устройству DeviceKeyboardClass0). Этот пакет, как вы понимаете, попадает в драйвер обслуживающий это устройство (устройство DeviceKeyboardClass0 обслуживает драйвер kbdclass). Т.е. решение об удовлетворении запроса — вызове IoCompleteRequest со статусом STATUS_SUCCESS — принимает обслуживающий драйвер.
Вот фрагмент функции KeyboardClassCreate драйвера kbdclass:
Как видите, kbdclass отклоняет попытку режима пользователя получить доступ к его устройствам для чтения.
Кстати, раз уж мы так подробно собрались во всем разбираться, посмотрим на внутренности макроса IoGetCurrentIrpStackLocation, который мы сами уже много раз использовали (полная версия в ntddk.inc).
Марос IoGetCurrentIrpStackLocation просто извлекает указатель на текущий блок стека из поля CurrentStackLocation.
Получив описатель объекта «файл», функция IoGetDeviceObjectPointer дополнительно увеличивает счетчик ссылок в объекте «файл», вызовом ObReferenceObjectByHandle. Затем IoGetDeviceObjectPointer пытается получить указатель на целевое устройство, сопоставленное с объектом «файл», вызывая IoGetRelatedDeviceObject. В зависимости от принадлежности объекта «файл» тому или иному типу устройств, IoGetRelatedDeviceObject может извлечь необходимый указатель из разных мест (в нашем случае из поля pFileObject->DeviceObject). Далее, обратите на это особое внимание, если к целевому устройству прикреплено ещё одно устройство (об этом говорит ненулевое значение в поле pDeviceObject->AttachedDevice), функция IoGetAttachedDevice «поднимается» по стеку устройств до самого верха и возвращает указатель на устройство, находящееся на вершине стека. Если же прикрепленных устройств нет, то возвращается указатель на само целевое устройство, т.е. то, имя которого было передано в IoGetDeviceObjectPointer. Запомните: Функция IoGetAttachedDevice всегда возвращает указатель на объект «устройство», находящийся на вершине стека.
После получения указателя IoGetDeviceObjectPointer закрывает описатель объекта «файл» и в этот момент счетчик описателей становится равным нулю, что приводит к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLEANUP. Т.о. функция IoGetDeviceObjectPointer вернет указатели на два объекта: «файл» и «устройство». Причем в объекте «устройство» значение счетчиков указателей и описателей не меняется, а в объекте «файл» равно 1 и 0, соответственно. Единичное значение счетчика указателей достигается благодаря дополнительному вызову ObReferenceObjectByHandle. До тех пор, пока существует объект «файл», объект «устройство», с которым он связан, не будет удален и соответственно драйвер, управляющий устройством, также не может быть выгружен, т.к. в управляемом им объекте «устройство», будет установлен соответствующий флаг и при попытке выгрузить такой драйвер он отмечается как ожидающий выгрузки, а процедура DriverUnload просто не будет вызвана. Только после того, как будут удалены все управляемые драйвером устройства, драйвер сможет отработать DriverUnload.
Т.о. в случае с IoGetDeviceObjectPointer схема точно такая же, какой пользуется режим пользователя, получая описатель объекта «файл» и таким образом блокируя связанный с ним объект. При этом сам объект «файл» относится к любому источнику или приемнику ввода-вывода (собственно файлу или каталогу, именованному каналу, почтовому ящику и др.), который рассматривается как файл. При таком механизме все считываемые или записываемые данные представляются простыми потоками байтов, направляемыми в виртуальные файлы. По окончании работы, программа режима пользователя закрывает описатель файла, а мы должны будем удалить ссылку, вызовом ObDereferenceObject. При этом счетчик указателей в объекте «файл» обнулится, и это приведет к формированию и посылке драйверу kbdclass IRP типа IRP_MJ_CLOSE. Только после этого объект «файл» будет удален.
Вернемся к исходному коду нашего драйвера.
Теперь у нас есть адресат для посылки IRP. Осталось только сформировать сам пакет.
IRP состоит из тела или заголовка (собственно структура IRP) и одного или нескольких блоков стека (stack locations). Тело IRP хранит общую информацию о запросе ввода-вывода: указатели на буферы, данные о состоянии и др. Блоки стека содержат информацию специфичную для конкретного этапа обработки IRP. Передавая IRP на обработку драйверу, диспетчер в/в (или драйвер самостоятельно создающий IRP, как мы в этом примере) заполняет верхний блок стека. Если драйвер, получивший IRP, решает отправить его на дальнейшую обработку нижестоящему драйверу, он заполняет следующий блок стека (т.к. это стек, то в памяти следующий блок стека находится по меньшему адресу — подробнее об этом чуть позже) и передает IRP ниже и т.д. Т.о. блоки стека — по одному на каждый вызываемый драйвер — хранят информацию, необходимую каждому драйверу для обработки своей части запроса.
Создать IRP можно одной из четырех функций: IoBuildSynchronousFsdRequest, IoBuildDeviceIoControlRequest, IoBuildAsynchronousFsdRequest и IoAllocateIrp. Если быть совсем точным, то можно сделать IRP вообще вручную, выделив память из пула или ассоциативного списка, но тогда все его поля придется заполнять самим. Мы воспользуемся самой универсальной из четырех вышеперечисленных функций — IoAllocateIrp. В отличие от трех остальных, с её помощью можно создавать IRP любого типа.
По соображениям лучшей производительности, память под IRP выделяется в одном из двух ассоциативных списков, индивидуальных для каждого процессора (структуры управляющие списками хранятся в специфичной для каждого процессора структуре KPRCB). Если нужен IRP с одним блоком стека, то используется ассоциативный список малых IRP. Если IRP должен содержать более одного блока стека — используется ассоциативный список больших IRP. Такие IRP содержат 8 блоков стека (эта цифра хранится в переменной ядра IopLargeIrpStackLocations). В Windows NT4 эта цифра равнялась 4, но с приходом PnP глубина стеков увеличилась. Если же IRP требует более 8 блоков стека или ассоциативный список пуст, то диспетчеру в/в ничего другого не остается, как выделить память под IRP из неподкачиваемого пула. Перед тем как вернуть управление, IoAllocateIrp обнуляет весь IRP и инициализирует некоторые его поля.
Самые важные для нас на данный момент поля это:
- Irp.StackCount — максимально необходимое количество блоков стека в IRP. Это поле будет равно значению первого параметра переданного в IoAllocateIrp. Мы извлекаем его из объекта «устройство», которому собираемся отправить IRP. Каждый объект «устройство» знает, сколько под ним объектов и, соответственно, сколько нужно блоков стека.
- Irp.CurrentLocation — порядковый номер текущего блока стека (отсчет идет в обратном порядке). Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает значение этого поля на единицу. Изначально же, как видите, оно на один больше чем действительно необходимо.
- Irp.Tail.Overlay.CurrentStackLocation — указатель на текущий блок стека. Каждый раз при передаче IRP нижестоящему драйверу функция IoCallDriver уменьшает его значение на размер структуры IO_STACK_LOCATION. Изначально оно указывает на недействительный блок стека, т.е. на область памяти сразу за концом IRP. Строго говоря, это не всегда так. Например, если IRP выделен из ассоциативного списка больших IRP, то у него 8 блоков стека, а мы, допустим, заказали 5. Тогда CurrentStackLocation будет указывать на один из лишних блоков стека. Если же мы просили IRP с одним блоком или он выделен из пула, то CurrentStackLocation указывает на «чужую» память.
По возвращении из IoAllocateIrp наш IRP выглядит так (я использовал команду irp отладчика SoftICE с ключом -f):
IoAllocateIrp делает только заготовку будущего IRP. Кое-какие поля требуется заполнить вручную.
Для формирования IRP разных типов может потребоваться заполнение разных полей. Я заполнил только самые необходимые для нас и вам не следует принимать это за образец. Подробности можно посмотреть в DDK.
После заполнения тела IRP мы должны сформировать блок стека для драйвера, которому мы адресуем запрос. Если использовать нумерацию блоков стека как её использует SoftIce, то мы должны заполнить блок стека за номером 5. Как вы помните, сейчас поле CurrentStackLocation указывает на недействительный блок стека. Для получения указателя на следующий блок стека, принадлежащий драйверу которому мы адресуем запрос, используется макрос IoGetNextIrpStackLocation:
Пусть вас не смущает слово next в имени макроса. Мы ведь имеем дело со стеком. «Следующий драйвер» означает нижестоящий драйвер, а «следующий блок стека» — блок стека с адресом на sizeof(IO_STACK_LOCATION) меньше чем текущий блок стека. Соответственно «предыдущий драйвер» означает вышестоящий драйвер, а «предыдущий блок стека» — блок стека с адресом на sizeof(IO_STACK_LOCATION) больше чем текущий блок стека. Макрос IoGetNextIrpStackLocation берет значение из поля CurrentStackLocation и уменьшает его на размер структуры IO_STACK_LOCATION. Таким образом, мы движемся в сторону меньших адресов по направлению к телу IRP.
Мы посылаем запрос типа IRP_MJ_PNP, а дополнительный код IRP_MN_QUERY_PNP_DEVICE_STATE определяет какую именно информацию о PnP характеристиках устройства мы хотим получить.
Инициализируем объект «событие». На этом объекте мы будем ждать момента завершения IRP. Тип события может быть и SyncronizationEvent, т.к. всё равно кроме нас, его никто ждать не будет. В исходных кодах драйверов можно встретить оба варианта.
Буквально через одну строку мы собираемся послать IRP драйверу kbdclass. Если мы не предпримем специальных мер, то никогда уже не сможем увидеть наш IRP. Как это не покажется парадоксальным, с первого взгляда, но после вызова IoCallDriver обращаться к IRP нельзя. К концу статьи, надеюсь, будет ясно почему. Единственная возможность вновь получить контроль над IRP — это установить специальную процедуру — процедуру завершения (completion routine). Процедура завершения будет вызвана, в тот момент, когда какой-либо драйвер ниже по стеку завершит IRP вызовом IoCompleteRequest. Одной из задачь функции IoCompleteRequest как раз и является задача вызова всех процедур завершения. Нашу процедуру завершения я назвал IrpComplete, а установить её можно с помощью макроса IoSetCompletionRoutine (полный вариант в ntddk.inc):
Первый параметр — указатель на IRP, при завершении которого должна быть вызвана процедура, указатель на которую передается во втором параметре. Третий параметр — указатель на любые данные. Этот указатель будет передан в процедуру завершения, и в нем мы укажем адрес нашего объекта «событие», которое процедура завершения, при необходимости, должна будет перевести в сигнальное состояние. Три последних параметра определяют, в каком случае будет вызвана процедура. Нам нужно, чтобы она была вызвана в любом случае: при завершении IRP с кодом успеха, при завершении IRP с кодом ошибки, при отмене IRP. Т.е. как бы ни завершился IRP, мы всё равно его перехватим на обратном пути. Обратите внимание, что макрос IoSetCompletionRoutine использует следующий блок стека, т.е. предназначенный для нижестоящего драйвера. Т.е. адрес процедуры завершения и её параметр помещаются не в блок стека драйвера, которому он принадлежит, а в блок стека нижестоящего драйвера. Почему мы лезем в чужой блок стека со своей процедурой завершения? Дело в том, что, во-первых, у нас нет своего блока стека, точнее он нам не нужен. Мы же сами формируем IRP и прекрасно знаем, что в нем содержится. С другой стороны, драйверу, стоящему ниже в стеке, который будет завершать IRP, не нужна процедура завершения. Он же сам его завершает и прекрасно знает как.
И ещё один очень важный момент, касающийся процедур завершения. В общем случае обработка ввода/вывода с физического устройства проходит по следующей схеме. Драйвер инициирует операцию в/в. Когда устройство завершает операцию, то генерирует прерывание, которое обрабатывается процедурой обработки прерывания (Interrupt Service Routine, ISR), зарегистрированной драйвером. Причем обработка будет происходить в контексте того потока, который был текущим на момент прерывания, а это случайный поток. Т.к. ISR работает на повышенном IRQL (больше DISPATCH_LEVEL), работа всех остальных потоков на данном процессоре блокируется. Мало того, блокируются (маскируются) все прерывания с таким же или более низким уровнем. Для того чтобы обработать возможные прерывания от менее приоритетных устройств, необходимо как можно быстрее понизить IRQL. Для этого ISR делает только то, что необходимо сделать немедленно и ставит в очередь так называемый вызов отложенной процедуры (Deferred Procedure Call, DPC). DPC работает при IRQL = DISPATCH_LEVEL. Когда IRQL понижается до DISPATCH_LEVEL, система вызывает отложенную процедуру и она делает дополнительные операции по завершению IRP. В самой последней фазе отложенная процедура вызывает IoCompleteRequest, которая, как я сказал выше, вызывает все процедуры завершения. Поэтому процедура завершения может быть вызвана в контексте случайного потока и при IRQL меньше или равном DISPATCH_LEVEL.
Раз процедура завершения может быть вызвана на повышенном IRQL, то очевидно, что и она сама и все данные, к которым она обращается должны находиться в неподкачиваемой памяти. Наша процедура завершения обращается к двум структурам: IO_STATUS_BLOCK и KEVENT (сам IRP не в счет, т.к. он всегда выделяется из неподкачиваемой памяти), которые располагаются в стеке потока, выполняющего процедуру QueryPnpDeviceState. Если этот поток будет ждать, то его стек может быть выгружен в файл подкачки (то, что, в данном случае, это системный поток не в счет). Чтобы запретить системе это делать, необходимо указывать KernelMode в параметре WaitMode функций ожидания. Я уже как-то раз говорил об этом, но, на всякий случай, повторяю.
Ну что же. Теперь у нас есть всё необходимое: адресат, сформированный IRP и процедура завершения, готовая перехватить его на обратном пути. Вызовом функции IoCallDriver, посылаем IRP драйверу, обслуживающему объект «устройство», указатель на который содержится в первом параметре.
Реализация функции IoCallDriver на удивление проста:
Сначала IoCallDriver уменьшает значение CurrentLocation на единицу и если оно вдруг стало равно нулю или ещё меньше, то система показывает «голубой экран смерти», т.к. нулевое значение в поле CurrentLocation говорит о том, что мы исчерпали все блоки стека и если IoCallDriver пойдет дальше, то просто будет «затирать» тело IRP, что рано или поздно всё равно приведет к краху. Затем значение в CurrentStackLocation уменьшается на размер структуры IO_STACK_LOCATION. Вот теперь оба поля: CurrentLocation и CurrentStackLocation соответствуют заполненному нами блоку стека. CurrentLocation равно 5, а CurrentStackLocation — 83887108. Сейчас наш IRP выглядит так:
Далее IoCallDriver помещает в поле DeviceObject текущего блока стека указатель на вызываемый объект «устройство». Этот указатель может потребоваться процедуре завершения. Затем из объекта «устройство» извлекается указатель на обслуживающий его драйвер и вызывается одна из процедур диспетчеризации драйвера. Т.к. в pStack->MajorFunction находится IRP_MJ_PNP, IoCallDriver берет из соответствующего элемента массива MajorFunction указатель на процедуру и передает ей адреса объекта «устройство» и IRP (вспомните любую функцию диспетчеризации, коих мы написали уже не мало). Если драйвер не занёс в соответствующее поле массива MajorFunction указатель на свою процедуру обработки данного типа IRP, то по умолчанию там находится указатель на системную функцию IopInvalidDeviceRequest, которая просто возвращает STATUS_INVALID_DEVICE_REQUEST и на этом обработка IRP будет завершена, не начавшись. Если же нужная процедура у драйвера имеется, а kbdclass имеет процедуру для обработки запросов IRP_MJ_PNP, то мы в нее и попадем, а IoCallDriver вернет то, что вернет эта процедура.
Теперь, прежде чем мы погрузимся в kbdclass, немного «уйдем в сторону» и представим, что IRP, только что сформированный нами, не IRP типа IRP_MJ_PNP, а гипотетический IRP_MJ_UNKNOWN, и посылаем мы его абстрактному драйверу unknown, процедура диспетчеризации которого выглядит приблизительно так:
Драйвер unknown либо сразу завершает IRP, либо ставит его в очередь, для того чтобы завершить позже. Сначала рассмотрим первый случай.
Прежде чем добавить IRP в очередь, драйвер должен отметить его как ожидающий завершения (pending). Это можно сделать с помощью макроса IoMarkIrpPending, который выглядит так:
Обратите внимание — флаг означающий, что IRP ожидает завершения, помещается не в тело IRP, а в текущий блок стека. Т.е. каждый драйвер независимо от других может проделать эту операцию.
Дальше драйвер помещает IRP в очередь и возвращает код STATUS_PENDING, говорящий вышестоящему драйверу о том, что завершение IRP отложено на неопределенное время. В нашем случае, вышестоящий драйвер — наш драйвер и ему необходимы результаты завершения IRP. Поэтому будем ждать, на созданном нами объекте «событие».
Существует несколько механизмов, которыми драйверы могут пользоваться для постановки IRP в очередь, но в итоге все сводится к добавлению IRP в двусвязный список. В самом простом случае можно использовать поле IRP.Tail.Overlay.ListEntry. Для того чтобы гарантировать себе монопольный доступ к очереди драйверы используют блокировку. Как работает очередь и блокировка, сейчас не важно.
По прошествии некоторого времени драйвер решает удалить IRP из очереди и завершить его.
Это может произойти в контексте любого потока и в любой момент (в результате прерывания). В данном случае, для нас важно лишь то, что драйвер вызывает IoCompleteRequest.
Рис. 15-6. Блок-схема функции IoCompleteRequest.
IoCompleteRequest должна пройтись по всем блокам стека, участвовавшим в обработке IRP, причем в обратном порядке, и вызвать все процедуры завершения. Когда IRP продвигается вниз, то значения полей CurrentLocation и CurrentStackLocation уменьшаются с каждым вызовом IoCallDriver (исключением является случай, когда драйвер передает свой собственный блок стека нижестоящему драйверу, пользуясь макросом IoSkipCurrentIrpStackLocation). IoCompleteRequest проделывает обратную работу, начиная с текущего блока стека, т.е. того, указатель на который находится в поле CurrentStackLocation (именно этот блок стека был текущим для драйвера вызвавшего IoCompleteRequest).
Когда IoCompleteRequest «поднимется» до самого верха, значения этих двух полей будут такими же, какими они были сразу после вызова IoAllocateIrp. Т.е. значение в поле CurrentLocation должно быть на единицу больше чем StackCount, а CurrentStackLocation будет указывать на недействительный блок стека.
Поэтому если CurrentLocation больше или равно StackCount + 1, это означает, что IRP уже был завершен. А завершать два раза IRP это примерно то же самое, что повторно вызывать ExFreePool с одним и тем же указателем. «Синий экран смерти» тут как нельзя кстати. Поэтому завершать IRP можно только один раз.Дальше идет отладочное утверждение ASSERT. Код, заключенный в макрос ASSERT попадает только в отладочный выпуск (checked build) системы. В свободном выпуске (free build) системы отловить такой баг можно с помощью Driver Verifier. Я специально добавил эту строку, т.к. завершение IRP с кодом STATUS_PENDING — очень распространенная ошибка. IRP может либо завершаться, либо ожидать завершения. Третьего не дано.
Правило:
Завершать IRP с кодом STATUS_PENDING нельзя.
Далее IoCompleteRequest получает указатель на текущий блок стека, вызовом макроса IoGetCurrentIrpStackLocation. А какой блок стека текущий в данном случае? Сейчас текущим является блок стека, принадлежащий драйверу unknown. Ведь IRP продвигался вниз всего на «один шаг». Если бы драйверу unknown понадобился указатель на его блок стека, то вызовом IoGetCurrentIrpStackLocation, он получил бы тот же самый адрес.
Потом IoCompleteRequest крутит цикл, проходя по всем участвовавшим в обработке IRP блокам стека в обратном порядке. Если в блоке стека установлен флаг SL_PENDING_RETURNED, значит драйвер, которому он принадлежит, вызывал IoMarkIrpPending. Если это так, то устанавливается ненулевое значение в поле IRP.PendingReturned. А если флаг SL_PENDING_RETURNED не установлен, то поле IRP.PendingReturned обнуляется. Это нужно для того, чтобы вышестоящий драйвер в своей процедуре завершения смог видеть, что нижестоящий драйвер отмечал IRP как ожидающий завершения. Обращаться к чужим блокам стека драйверы не должны (исключение — копирование/заполнение блока стека при передаче IRP вниз по стеку). IoCompleteRequest даже специально обнуляет некоторые поля обработанного блока стека используя ZeroIrpStackLocation (на самом деле это макрос, а не функция). Поэтому SL_PENDING_RETURNED, как бы «перекладывается» в поле PendingReturned самого IRP. Когда мы доберемся до схемы на рис. 15-7, предназначение поля PendingReturned станет более понятно.
Если вышестоящий драйвер установил процедуру завершения (вы должны помнить, что драйверы устанавливают процедуры завершения в блоке стека, принадлежащем нижестоящему драйверу), она вызывается. В процедуру завершения передается указатель на объект «устройство», принадлежащий драйверу установившему эту процедуру. Поскольку инициатор запроса (наш драйвер, в данном случае) не имеет своего блока стека, то в качестве указателя на объект «устройство» он получит NULL.
Если процедуре завершения потребуется обратиться к текущему блоку стека она тоже может использовать макрос IoGetCurrentIrpStackLocation. А какой блок стека она получит? Процедура завершения получит блок стека, принадлежащий её драйверу. Т.е. и в процедуре диспетчеризации и в процедуре завершения IoGetCurrentIrpStackLocation возвращает один и тот же указатель. Можем ли мы как создатели IRP в нашей процедуре завершения вызвать IoGetCurrentIrpStackLocation? Нет. Точнее указатель то мы получим, но на недействительный блок стека. Ведь своего собственного блока стека у нас нет, т.к. он нам не нужен.
Если процедура завершения вернула STATUS_MORE_PROCESSING_REQUIRED, то IoCompleteRequest, не делая ни одного лишнего движения, сразу возвращает управление, т.к. трогать IRP она уже не имеет права — возможно, IRP уже не существует. В нашем случае это именно так, ведь мы в процедуре завершения вызываем IoFreeIrp и для того, чтобы заставить IoCompleteRequest немедленно прекратить дальнейшие действия по завершению IRP, возвращаем STATUS_MORE_PROCESSING_REQUIRED. Если же процедура завершения возвращает любой другой код, то IoCompleteRequest продолжает работу. DDK рекомендует в качестве «любого другого кода» возвращать STATUS_SUCCESS просто потому, что он равен 0, а это приводит к генерации компилятором более оптимального кода. В более поздних DDK можно найти такие определения:
Имена констант ContinueCompletion и StopCompletion значительно лучше отражают суть, чем STATUS_SUCCESS и STATUS_MORE_PROCESSING_REQUIRED. Т.о., возвращая StopCompletion, мы говорим функции IoCompleteRequest, что она должна немедленно прекратить работу и вернуть управление. Если мы возвращаем ContinueCompletion (точнее говоря, не возвращаем StopCompletion), то IoCompleteRequest продолжает процесс завершения IRP.
Для чего нам нужно остановить IoCompleteRequest? Мы, как создатели IRP, не можем допустить, чтобы диспетчер в/в завершал созданный нами IRP. Это наша работа. Единственная возможность это сделать — установить процедуру завершения.
Если в обрабатываемом блоке стека нет указателя на процедуру завершения, то IoCompleteRequest смотрит, было ли установлено на предыдущем шаге поле IRP.PendingReturned. Если да, и всё ещё есть действительный блок стека, взводит флаг SL_PENDING_RETURNED в предыдущем блоке стека (этот блок IoCompleteRequest будет обрабатывать при следующем витке цикла), используя макрос IoMarkIrpPending.
Представим теперь два плохих сценария:
- драйвер unknown возвращает STATUS_PENDING, но забывает про IoMarkIrpPending;
- драйвер unknown отмечает IRP как ожидающий завершения, используя IoMarkIrpPending, но забывает вернуть STATUS_PENDING.
Сценарий 1: Если драйвер возвращает из процедуры диспетчеризации код STATUS_PENDING, IoCallDriver передаст этот код нам. Увидев такой код, мы бесконечно ждем, пока наша процедура завершения не освободит событие. По прошествии некоторого времени драйвер unknown инициирует завершение IRP. IoCompleteRequest смотрит в блок стека, принадлежащий драйверу unknown, и, не обнаружив там флага SL_PENDING_RETURNED, обнуляет IRP.PendingReturned. Видя, что в блоке стека установлена процедура завершения (установленная нашим драйвером), IoCompleteRequest вызывает её. Получив управление, наша процедура завершения не сигналит событие и освобождает память, занятую под IRP. В результате событие уже никогда не будет освобождено и поток, ожидающий на нем, никогда не возобновит работу.
Вариацией этого сценария будет ситуация, когда драйвер unknown ставит IRP в очередь, а потом вызывает IoMarkIrpPending (имеется ввиду, что блокировка очереди уже снята). Тогда ещё до того как он доберется до IoMarkIrpPending, IRP может быть извлечен из очереди и завершен.
Сценарий 2: Получив от IoCallDriver код отличный от STATUS_PENDING, наш драйвер считает, что IRP завершен и в зависимости от ошибочно возвращенного кода либо получает неверные данные, либо не получает ничего. Но это не самое страшное. Хуже, если мы переведем IoFreeIrp из процедуры завершения в основную процедуру после IoCallDriver, а мы имеем полное право это сделать. Драйвер unknown ведь не знает деталей реализации вышестоящего драйвера, и ни в коем случае не должен на это полагаться. Посчитав, что IRP завершен, мы вызовем IoFreeIrp. Через некоторое время драйвер unknown пытается извлечь уже не существующий IRP из очереди…
Не сложно догадаться, что для сценария 1 можно применить простое противоядие: вне зависимости от значения поля PendingReturned всегда вызывать KeSetEvent в процедуре завершения. Можно конечно, но тогда во всех случаях, когда IRP завершается немедленно, мы будем зря вызывать KeSetEvent, а она блокирует базу данных диспетчера потоков, ищет потоки, ждущие на событии, и делает их планируемыми, разблокирует базу данных диспетчера потоков. Вобщем, кое-какие накладные расходы будут. Но дело даже не в этом. Мы можем переписать нашу процедуру завершения, но мы не можем переписать код диспетчера в/в, который реализует свою логику работы. Диспетчер в/в вообще не устанавливает процедуру завершения. Он использует другие механизмы, но при принятии решений также опирается на код, возвращенный IoCallDriver и значение поля PendingReturned.
Правило:
Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.
Вернемся к стеку клавиатуры. Мы уже вызвали IoCallDriver и сейчас находимся в процедуре диспетчеризации KeyboardPnP драйвера kbdclass.
Я использую здесь исходный код из 2003 IFS KIT. В 2000 DDK код функции KeyboardPnP отличается: драйвер kbdclass синхронизирует обработку IRP, используя функцию KeyboardSendIrpSynchronously, почти идентичную функции I8xSendIrpSynchronously драйвера i8042ptr (см. ниже). Во-первых, так нам будет проще, а во-вторых, это внесет некоторое разнообразие.
Первым делом kbdclass получает указатель на свой блок стека, чтобы посмотреть чего от него хотят.
При обработке IRP_MN_QUERY_PNP_DEVICE_STATE драйвер должен поместить в поле IRP.IoStatus.Information флаг, определяющий состояние устройства. При этом, поскольку поле IRP.IoStatus.Information одно, а драйверов в стеке много, все они используют логические операции для установки или сброса нужных флагов. Драйвер kbdclass добавляет флаг PNP_DEVICE_NOT_DISABLEABLE и помещает в IRP код успеха. Теперь он должен передать его нижестоящему драйверу. При этом дальнейшая судьба этого запроса его не интересует и он не устанавливает процедуру завершения. Уак будет завершен IRP, kbdclass не узнает уже никогда. Несмотря на то, что после вызова IoCallDriver в переменной pIrp всё еще будет хранится число, являвшееся указателем на IRP, обращаться по этому указателю драйвер kbdclass не имеет права, т.к., возможно, этот IRP уже не существует и на схеме 15-7 это будет очень хорошо видно.
Перед вызовом нижестоящего драйвера, драйвер kbdclass (и любой другой) должен заполнить причитающийся ему (нижестоящему драйверу) блок стека. В данном случае, т.к. kbdclass не формирует новый IRP, а пересылает переданный ему свыше, он может просто скопировать свой блок стека в следующий (помните, что это стек, где всё поставлено с ног на голову, т.е. следующим будет блок стека расположенный в памяти ниже). Это можно сделать с помощью макроса IoCopyCurrentIrpStackLocationToNext. В ntddk.inc можно увидеть оптимизированный вариант, а здесь приводится белее доступная для понимания версия.
Как видно, макрос копирует текущий блок стека в следующий, но три поля: Control, CompletionRoutine и Context обнуляются. Зачем обнуляются эти поля, мы знаем ниже. Теперь kbdclass вызывает IoCallDriver, передавая в своей переменной NextLowerDeviceObject, указатель на объект «устройство» находящийся непосредственно под ним. Этот указатель kbdclass получает при подключении к стеку. Т.к. мы договорились рассматривать классический состав стека, следующим в стеке оказывается объект «устройство», принадлежащий драйверу i8042ptr и мы оказываемся в его процедуре диспетчеризации I8xPnP.
i8042ptr также получает указатель на свой блок стека и синхронно перенаправляет IRP следующему (нижестоящему) драйверу acpi, указатель на который хранится в переменной TopOfStack.
Разбирать функции I8xSendIrpSynchronously и I8xPnPComplete я не буду, т.к. они реализуют ту же логику работы, что и наши QueryPnpDeviceState и IrpComplete. Разобравшись с кодом нашего драйвера, вы без труда поймете, как работают эти две функции.
По возвращении из I8xSendIrpSynchronously, драйвер i8042ptr добавляет в поле Information свою порцию флагов из переменной PnpDeviceState и завершает IRP, вызовом IoCompleteRequest.
Ну, и, наконец, процедура диспетчеризации драйвера acpi будет у нас выглядеть так (на самом деле всё гораздо сложнее):
Теперь рассмотрим случай, когда обработка IRP будет синхронной, т.е. пройдет в контексте одного и того же потока. Все драйверы в стеке завершают IRP немедленно и, соответственно, ни одна из процедур диспетчеризации не возвращает STATUS_PENDING. Будем пользоваться схемой на рис. 15-7. Нарисовав эту схему, я был приятно удивлен тем, насколько хорошо видны на ней некоторые совсем неочевидные вещи.
Рис. 15-7. Этапы обработки IRP.
Наш драйвер QueryPnpDeviceState создает IRP, инициализирует объект «событие», на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения IrpComplete и посылает IRP драйверу kbdclass.
Драйвер kbdclass перенаправляет IRP нижестоящему драйверу i8042prt, не устанавливая процедуру завершения.
Драйвер i8042prt инициализирует объект «событие», на котором будет ждать завершения IRP, если завершение будет отложено, устанавливает процедуру завершения I8xPnpComplete и передаёт IRP нижестоящему драйверу acpi.
Драйвер acpi завершает IRP (возможно предварительно разослав его каким-то другим драйверам), вызывая IoCompleteRequest.
Функция IoCompleteRequest начинает завершение IRP. Смотрит в блок стека принадлежащий драйверу acpi. Не найдя там флага SL_PENDING_RETURNED (драйвер acpi не вызывал макрос IoMarkIrpPending), не устанавливает поле IRP.PendingReturned. Находит указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt и вызывает её.
Процедура завершения I8xPnpComplete совершенно напрасно сигналит событие (драйвер i8042prt не ждет и не будет ждать на этом событии) и возвращает код STATUS_MORE_PROCESSING_REQUIRED.
Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера acpi.
Драйвер acpi возвращает код STATUS_SUCCESS, и мы выходим из функции IoCallDriver в драйвере i8042prt.
Увидев, что возвращенный из IoCallDriver код не STATUS_PENDING, драйвер i8042prt не ждет на событии. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. устанавливал процедуру завершения, которая прервала обработку IRP. Поскольку драйвер i8042prt прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, то должен возобновить этот процесс. Что он и делает вызовом IoCompleteRequest.
Выше мы выяснили, что завершать IRP два раза нельзя. Здесь же мы видим уже второй вызов IoCompleteRequest. Есть ли тут противоречие? Нет. Завершение IRP — это не просто вызов IoCompleteRequest. Это многоэтапный процесс. На каждом этапе он может быть прерван и возобновлен вновь. Только когда все эти этапы будут пройдены, IRP считается завершенным.
Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В блоке стека драйвера i8042prt нет флага SL_PENDING_RETURNED (драйвер i8042prt тоже не вызывал макрос IoMarkIrpPending). Поэтому IRP.PendingReturned опять обнуляется. IoCompleteRequest не находит указатель на процедуру завершения в блоке стека драйвера i8042prt и переходит к предыдущему и последнему блоку стека драйвера kbdclass. kbdclass тоже не использовал макрос IoMarkIrpPending и IRP.PendingReturned опять обнуляется. В блоке стека драйвера kbdclass имеется указатель на нашу процедуру завершения IrpComplete, которая и вызывается.
Вспомните, что при передаче IRP нижестоящему драйверу, драйвер kbdclass скопировал свой блок стека в следующий, использую макрос IoCopyCurrentIrpStackLocationToNext. Однако этот макрос не копирует поля связанные с процедурой завершения. Если бы он этого не сделал, то указатель на нашу процедуру завершения (он находится в блоке стека драйвера kbdclass) попал бы в блок стека драйвера i8042prt, и наша процедура завершения была бы вызвана дважды. В стародавние времена, когда ещё не было макроса IoCopyCurrentIrpStackLocationToNext, программисты вручную копировали блоки стека, иногда забывая обнулить поля связанные с процедурой завершения, что приводило к трудно находимым багам.
Наша процедура завершения несколько умнее. Видя, что поле PendingReturned равно нулю, она понимает, что нижестоящий драйвер не возвращал STATUS_PENDING, а значит, процедура диспетчеризации драйвера QueryPnpDeviceState не ждет на событии. Поэтому и сигналить его нет смысла. Мы установили процедуру завершения только для того, чтобы удалить, созданный нами IRP. Можем сделать это прямо сейчас, вызвав IoFreeIrp. Поскольку IRP больше нет, мы должны остановить его завершение, вернув код STATUS_MORE_PROCESSING_REQUIRED.
Увидев код STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest немедленно прекращает работу и возвращает управление в процедуру диспетчеризации драйвера i8042prt. Вот здесь очень хорошо видно, почему после вызова IoCompleteRequest нельзя обращаться к IRP. Ведь возможно IRP уже не существует, и узнать это драйвер вызывающий IoCompleteRequest не может. Обратите внимание на то, что функция IoCompleteRequest не возвращает никакого значения.
Правило:
После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.
Процедура диспетчеризации драйвера i8042prt возвращает код, который вернула вызванная им IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в драйвере kbdclass. И опять здесь хорошо видно, почему после вызова IoCallDriver нельзя обращаться к IRP, если, конечно, не устанавливать процедуру завершения и не прерывать завершение IRP. Ведь IRP то уже не существует. Драйвер kbdclass отказался от установки процедуры завершения, а значит, после вызова IoCallDriver полностью потерял контроль над IRP. Кто и когда завершит IRP драйвер kbdclass не узнает, а значит, не может делать никаких предположений о том, существует ли IRP до сих пор или его уже нет. Драйвер i8042prt смог обратиться к IRP после вызова IoCallDriver только потому, что его процедура завершения прервала процесс завершения IRP, а драйвер kbdclass не может.
Правило:
Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.
Процедура диспетчеризации драйвера kbdclass возвращает код, который вернула, вызванная им, IoCallDriver, а это, в данном случае, STATUS_SUCCESS и мы выходим из функции IoCallDriver в нашем драйвере QueryPnpDeviceState.
Видя, что возвращенный из IoCallDriver код не STATUS_PENDING, мы не ждем на событии. Хотя мы и установили процедуру завершения, и она вернула STATUS_MORE_PROCESSING_REQUIRED, но трогать IRP после возвращения из IoCallDriver всё равно не можем. Это исключение из правил, т.к. мы являемся создателем IRP. Надеюсь, здесь это очевидно. Мы же сами удалили IRP в процедуре завершения и прекратили его дальнейшее завершение.
Теперь поставим на место драйвера acpi драйвер unknown и представим, что он откладывает завершение IRP и возвращает из своей процедуры диспетчеризации STATUS_PENDING. Т.е. обработка IRP будет асинхронной.
Т.к. драйвер unknown откладывает завершение IRP, то, используя макрос IoMarkIrpPending, заносит в свой блок стека флаг SL_PENDING_RETURNED, ставит IRP в очередь и возвращает STATUS_PENDING. Мы выходим из функции IoCallDriver в драйвере i8042prt. Увидев код STATUS_PENDING, драйвер i8042prt начинает ждать освобождения события и текущий поток блокируется.
Через некоторое время в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown достает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения I8xPnpComplete вышестоящего драйвера i8042prt, вызывает её. Процедура завершения I8xPnpComplete сигналит событие и возвращает код STATUS_MORE_PROCESSING_REQUIRED, что заставляет функцию IoCompleteRequest прекратить работу и вернуться туда, откуда она была вызвана.
Ожидающий на событии поток пробуждается. Сейчас драйвер i8042prt имеет полное право обращаться к IRP, т.к. прервал завершение IRP, вернув из своей процедуры завершения код STATUS_MORE_PROCESSING_REQUIRED, и совершенно точно знает, что IRP ещё не завершен. Это он и делает, для того чтобы узнать код, с которым завершился отложенный IRP (см. исходный код функции I8xSendIrpSynchronously). Этот код драйвер извлекает из поля IRP.IoStatus.Status и из своей процедуры диспетчеризации будет возвращать именно его, а не первоначальный STATUS_PENDING. Затем драйвер i8042prt возобновляет завершение IRP, вызовом IoCompleteRequest.
Функция IoCompleteRequest продолжает завершать IRP с того места, где её прервали, т.е. с текущего блока стека, а текущим сейчас является блок стека драйвера i8042prt. В этом блоке стека нет флага SL_PENDING_RETURNED… Точнее говоря, его там быть не должно, но взгляните на исходный код функции I8xPnPComplete из 2000 DDK. Вы увидите там такие строки:
В 2003 DDK эти строки уже закомментарены.
Две выделенные красным строки должны быть в процедуре завершения, но только если она не возвращает STATUS_MORE_PROCESSING_REQUIRED. Чуть позже увидим почему.
Допустим, мы используем I8xPnPComplete из 2000 DDK и в блоке стека драйвера i8042prt ошибочно присутствует флаг SL_PENDING_RETURNED. Видя это, IoCompleteRequest опять помещает в поле IRP.PendingReturned ненулевое значение. Если вы проанализируете дальнейший ход событий, то увидите, что ненулевое значение в поле IRP.PendingReturned дойдет до нашей процедуры завершения. Увидев не равное нулю поле IRP.PendingReturned, она решит, что нижестоящий драйвер вернул STATUS_PENDING и процедура диспетчеризации QueryPnpDeviceState ждет освобождения события, хотя на самом деле это не так. В данном случае, ничего ужасного не произойдет. Мы просто напрасно просигналим событие и всё. В каком-то другом случае, наверное, возможны более серьёзные последствия, т.к. драйвер будет основывать свои действия на неверных допущениях.
Мы уже несколько раз убеждались в том, что не стоит слепо верить документации DDK. Теперь оказывается, что и исходникам DDK нельзя верить?! Да, к сожалению, это так. Особенно много, скажем так, неоптимальных решений в исходниках 2000 DDK. Тексту этой статьи я тоже, кстати, советую не доверять
Остальные возможные сценарии проанализируйте сами. Я только хочу ещё раз обратить особое внимание на поле IRP.PendingReturned. Во всех источниках, которые мне приходилось видеть, в том числе и в DDK, предназначение этого поля не совсем верно трактуется. Обычно говорится, что это поле сообщает диспетчеру в/в или вышестоящему драйверу о том, что нижестоящий драйвер отмечал IRP как ожидающий завершения (вызывал IoMarkIrpPending и возвращал из процедуры диспетчеризации STATUS_PENDING). Это верно. Также говорится, что якобы если какой-либо драйвер отмечал IRP как ожидающий завершения, то ненулевое значение этого поля так и сохраняется при завершении IRP до самого верха. А вот это уже не совсем так. Функция IoCompleteRequest (и мы с вами тоже должны будем принять в этом участие чуть ниже) действительно старается сохранить состояние этого поля, но только если она не встретит процедуру завершения. Зачем это нужно? В только что рассмотренном нами сценарии с драйвером unknown вместо acpi, обработка IRP до того как он опустился до драйвера i8042prt, была синхронной (проходила в контексте одного и того же потока). После того, как драйвер unknown вернул из процедуры диспетчеризации STATUS_PENDING, обработка IRP стала асинхронной (процедура завершения драйвера i8042prt вызывается в контексте случайного потока, а процедура диспетчеризации драйвера i8042prt ждет события в контексте первоначального потока). Дождавшись освобождения события, процедура диспетчеризации драйвера i8042prt продолжает обработку IRP в контексте первоначального потока, и обработка IRP опять становится синхронной. Вот тут собака и зарыта. Все драйверы находящиеся выше i8042prt вообще не должны знать, что драйвер unknown откладывал завершение IRP. Это проблема драйвера i8042prt и он сам её решил. Для всех вышестоящих драйверов всё как было синхронным, так и осталось. На участке между драйверами unknown и i8042prt поле IRP.PendingReturned будет содержать ненулевое значение, а на участке выше драйвера i8042prt оно обнулится, т.к. обработка IRP вновь стала синхронной и никто никого не ждет. Надеюсь, что понятно объяснил и нигде не ошибся
Ну, хорошо, все процедуры завершения, которые мы видели до сих пор, возвращали STATUS_MORE_PROCESSING_REQUIRED. Но, как мы выяснили выше, это не единственно возможный код возврата. Этот код процедуры завершения возвращают в одном из трех случаев:
- Драйвер-создатель IRP вновь хочет увидеть своё чадо, для того чтобы его… скажем мягко, освободить (пример — наш драйвер) или повторно использовать;
- Драйвер хочет синхронизировать обработку IRP (пример — драйвер i8042prt);
- Т.к. процедура завершения может вызываться на повышенном IRQL, драйвер хочет сделать какую-то дополнительную обработку на PASSIVE_LEVEL в своей процедуре диспетчеризации.
Если же драйверу не нужна такая функциональность, но перехватить IRP на обратном пути всё же требуется (например, для того, чтобы посмотреть считанные с диска данные или код нажатой клавиши, что мы и будем делать в следующей статье) и всю обработку драйвер может сделать в процедуре завершения, даже на уровне DISPATCH_LEVEL, то тогда процедуре завершения не требуется прерывать завершение IRP и можно вернуть STATUS_SUCCESS или ContinueCompletion (что одно и то же).
В этом случае процедура завершения может выглядеть примерно так:
Самое важное здесь, в контексте нашего разговора, это вызов макроса IoMarkIrpPending в случае, если поле IRP.PendingReturned не равно нулю. Выше мы разобрались, что IoCompleteRequest как бы «перекладывает» флаг SL_PENDING_RETURNED из текущего блока стека в поле PendingReturned самого IRP и наоборот, если в блоке стека нет процедуры завершения, а поле PendingReturned не равно нулю, то вызывает макрос IoMarkIrpPending. Короче говоря, IoCompleteRequest пытается донести до первой встретившейся ей процедуры завершения, тот факт, что какой-то нижестоящий драйвер отмечал IRP как ожидающий завершения. Когда IoCompleteRequest находит процедуру завершения, то возлагает эту задачу на неё (см. исходный код IoCompleteRequest, а лучше блок-схему).
Представим, что вместо драйвера acpi у нас драйвер unknown и процедура завершения I8xPnPComplete драйвера i8042prt похожа на процедуру JustComplete, т.е. не сигналит событие и возвращает код STATUS_SUCCESS. Соответственно, процедура диспетчеризации драйвера i8042prt никакого события не инициализирует и не ждет, а просто возвращает тот код, который вернет IoCallDriver.
Драйвер unknown вызывает макрос IoMarkIrpPending, ставит IRP в очередь и возвращает STATUS_PENDING. Этот код «поднимается» до нашей процедуры диспетчеризации и мы начинаем ждать.
Некоторое время спустя, в результате прерывания или по другой причине, но в контексте какого-то другого потока, драйвер unknown извлекает IRP из очереди и завершает его вызовом IoCompleteRequest. IoCompleteRequest обнаруживает в блоке стека драйвера unknown флаг SL_PENDING_RETURNED, и поле IRP.PendingReturned принимает ненулевое значение. Обнаружив указатель на процедуру завершения JustComplete вышестоящего драйвера i8042prt, вызывает её (повторяю, мы заменили код на JustComplete). Сделав свои дела, процедура завершения JustComplete видит, что поле IRP.PendingReturned не равно нулю и, вызовом макроса IoMarkIrpPending, кладет в свой блок стека флаг SL_PENDING_RETURNED. Функция IoCompleteRequest делает то же самое в ветке else, но т.к. IoCompleteRequest встретила процедуру завершения, то эта задача перекладывается на неё. Т.к. процедура завершения I8xPnpComplete возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, функция IoCompleteRequest продолжает «подниматься» по блокам стека. Сделав дальнейший анализ, вы увидите, что информация о том, что IRP отмечался как ожидающий завершения в виде ненулевого значения в поле IRP.PendingReturned благополучно доходит до нашей процедуры завершения. Наша процедура завершения понимает, что процедура диспетчеризации QueryPnpDeviceState ждет на событии, сигналит его и всё заканчивается благополучно.
А если вы также проанализируете, что будет, если процедура завершения JustComplete забудет должным образом воспользоваться макросом IoMarkIrpPending, то придете к ещё одному правилу.
Правило:
Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом.
if pIrp->PendingReturned {
IoMarkIrpPending( pIrp )
}
Ну и последнее. Т.к. у процедуры завершения нет другой возможности узнать, с каким кодом нижестоящий драйвер завершает IRP, кроме как обратиться к полю IRP.IoStatus.Status, мы запишем последнее правило.
Правило:
Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.
Начиная писать эту «бесконечную» статью я планировал ещё рассказать о том, какую логику использует диспетчер в/в при обработке IRP, т.к. чаще всего именно он является создателем IRP, но чувствую, что силы покидают меня. Если этот вопрос вас интересует, то рекомендую почитать статью «How Windows NT Handles I/O Completion» в IFS KIT или «The NT Insider» ( http://www.osronline.com/ ). К сожалению, исходного кода диспетчера в/в вы там не найдете, но общее представление получите.
Что вы должны делать и чего вы делать не должны
Подведем итог.
Правило 1:
Перед вызовом IoCompleteRequest в процедуре диспетчеризации драйвер должен поместить в поле IRP.IoStatus.Status код с которым он завершает IRP и вернуть из процедуры диспетчеризации тот же самый код.
Правило 2:
После вызова процедуры IoCompleteRequest обращаться к IRP нельзя. Возможно, IRP уже не существует.
Правило 3:
Завершать IRP с кодом STATUS_PENDING нельзя.
Правило 4:
Если из процедуры диспетчеризации драйвер возвращает код STATUS_PENDING, то перед этим должен вызвать IoMarkIrpPending. Если в процедуре диспетчеризации драйвер вызывает IoMarkIrpPending, то должен вернуть код STATUS_PENDING. Либо и то и другое, либо ни того, ни другого.
Правило 5:
Если у вас нет процедуры завершения или имеющаяся у вас процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то после вызова IoCallDriver обращаться к IRP нельзя. Возможно, IRP уже не существует.
Правило 6:
Если процедура завершения возвращает код отличный от STATUS_MORE_PROCESSING_REQUIRED, то должна использовать (в любо месте) макрос IoMarkIrpPending таким образом.
if pIrp->PendingReturned {
IoMarkIrpPending( pIrp )
}
Некоторые из этих правил, наверное, можно нарушить, если очень хорошо представлять себе, все детали механизма обработки IRP. Если такого представления нет, то лучше следовать им неукоснительно.
В следующий раз мы попробуем применить кое-какие полученные сегодня знания на практике.
Исходный код драйвера в архиве.
© Four-F
archive
New Member
- Регистрация:
- 27 фев 2017
- Публикаций:
- 532
25.04.2019
Просмотров: 12844
Синий экран смерти MULTIPLE IRP COMPLETE REQUESTS с цифровым кодом 0x00000044 чаще всего появляется на старых сборках Windows XP и 2000 по причине повреждения системного драйвера, сбоев в работе жесткого диска, в результате работы вирусного приложения. Также ошибка 0x00000044 на более старшей версии Windows 7 и 8 возникает по причине конфликта операционной системы с файлами антивируса. Поэтому для решения синего экрана смерти MULTIPLE IRP COMPLETE REQUESTS придется провести ряд диагностических действий.
Читайте также: Решение ошибки 0x000000A5: ACPI BIOS ERROR при загрузке и установке Windows
Способы решения ошибки MULTIPLE IRP COMPLETE REQUESTS
Если на вашем компьютере возник синий экран смерти MULTIPLE IRP COMPLETE REQUESTS, то, в первую очередь, нужно проверить операционную систему на наличие вирусов. Для этого нужно иметь установленный антивирус с актуальными вирусными базами или скачать лечащую утилиту Dr.Web Curelt.
Если в результате проверки вирусы не были обнаружены, стоит на время отключить, а еще лучше, удалить антивирус. Как показал анализ различных форумов, ошибка 0x00000044 часто появлялась на ПК пользователей по вине антивируса. Поэтому на этапе диагностики системы лучше Защитник Windows отключить, а антивирус удалить.
Если BSOD все равно появляется, то виной могут быть драйвера. Определить, какой драйвер вызывает ошибку, можно как при анализе малого дампа памяти и самого синего экрана (иногда сбойный файл указывается на экране), так и вручную. Для самостоятельного определения сбойного драйвера нужно перейти в Диспетчер устройств, нажав «Win+R» и ввел «devmgmt.msc».
Откроется новое окно. В древовидном меню будут представлены все подключенные устройства и компоненты системный сборки. Разворачиваем каждый элемент и смотрим, чтобы не было значка с восклицательным знаком, который указывает на то, что драйвер устройства поврежден или отсутствует. Далее нажимаем на устройстве право кнопкой мыши и выбираем «Обновить драйвера».
На следующем этапе кликаем на ссылку «Выполнить поиск драйверов на этом компьютере».
Указываем на ранее загруженный с сайта официального производителя драйвер. Запускаем обновление ПО. Как только установка будет закончена, нужно перезагрузить систему, чтобы изменения вступили в силу. Проверяем ПК на предмет ошибки.
ВАЖНО! Если ошибочного драйвера не было обнаружено, стоит запустить утилиту Driver Pack Solution для автоматического поиска и обновления устаревших драйверов. Можно установить последние имеющиеся обновления Windows.
Ошибка MULTIPLE IRP COMPLETE REQUESTS также может возникать в случае повреждения жесткого диска. Для начала накопитель нужно проверить утилитой чекдиск, которую стоит запустить через командную строку с правами Администратора, ввел chkdsk C: /f, где С: — буква диска с операционной системой, /f – параметр команды для исправления ошибок.
После запуска такой команды ПК будет перезагружен и запустится сканирование диска. В данный момент компьютер запрещается перезагружать или аварийно выключать. Даже после включения ПК команда будет работать. Поэтому лучше подождать окончания проверки, которая может длиться от нескольких минут до часа.
Для глубокой проверки накопителя рекомендуем скачать программу Victoria HDD, которая проверить HDD или SSD на наличие битых секторов.
На некоторых форумах данную ошибку связывают с проблемами оперативной памяти. Исправить её можно с помощью программы MemTest86, которая разработана для диагностики и исправления ошибок с ОЗУ. Программу нужно скачать и записать как образ на диск или флешку. Далее нужно загрузиться в BIOS и выставить приоритетность загрузки со съемного носителя или CD-ROM. После этого запускаем проверку памяти. Желательно выполнить несколько проходов данной программой, так как за один проход софт может не обнаружить неполадок.
Также для уверенности можно почистить контакты модулей ОЗУ и переставить модули местами. Возможно, модули просто сбоили. Однако это уже сигнал к тому, что планки нужно будет заменить.
Важно отметить, что на Windows 7 и Windows 8 такая неполадка также появлялась при подключении накопителя к портам USB 2.0 и USB 3.0. Поэтому, если вы подключили к ПК какое-то оборудование через данные порты, то стоит их перепроверить и подключить заново. Возможно, вы подключили устройство USB 3.0 к порту USB 2.0.
Во всех остальных случаях, при возникновении неполадки нужно либо откатить систему до более раннего состояния, либо вовсе переустановить Windows.
|
Pe
Гость |
Есть не PnP драйвер фильтр. В его диспетчерской процедуре всего стоит IoSkipCurrentIrpStackLocation и IoCallDriver. Как корректно сделать выгрузку и как сделать корректную выгрузку моего фильтра, если над моим драйвером фильтром висит еще какой — то драйвер фильтр ? |
||
|
|
SlavaI
Главный специалист |
Корректная выгрузка фильтра-драйвера невозможна, а тем более если над твоим драйвером фильтром висит сидит еще кто-то! У него же указатель на объекты твоего драйвера! Сначала надо отсоединить объект, который над тобой, что может официально сделать только система если PDO решил исчезнуть, то есть о нем не сообщила при запросе BusRelation. |
||
|
|
Pe
Гость |
Во-первых, IRPTracer вроде не присоединяется, он работает вроде как-то по другому. Вроде не меняет адреса обработчиков отслеживаемого драйвера. Как, не знаешь, он работает ? |
||
|
|
Pe
Гость |
Может как-то поменять указатель stack’ a при выгрузке устройства моего фильтра ? |
||
|
|
SlavaI
Главный специалист |
у кого ты его и где менять будешь? Его во внутренних структурах хранят, формат которых тебе неизвестен это раз, второе- уже может быть инициирована посылка IRP на тебя, просто из-за планировщика не успели вызвать твою точку входа, но IoCallDriver уже вызвали, в итоге все упадет с тем же кодом. Нельзя выгружаться и все! |
||
|
|
Pe
Гость |
Смотрел отлвадчиком, эта ошибка на стадии выполнения IoDeleteDevice, там что, с устройством фильтра связан IRP, а в это время происходит удаление устройства ? |
||
|
|
SlavaI
Главный специалист |
Пока у тебя есть свой объект в стеке, ты удалится не можешь. Можно сделать как IrpTrace но тут тоже проблемы- а если еще кто-то так сделает? А ты выгружаться начнешь, то все упадет- у него адреса твоих точек входа, а у тебя родного драйвера и все упадет. |
||
|
|
Pe
Гость |
Если кто-то еще сделает, то можно попробовать поменять точки входа с моего фильтра на точки входа «родного» драйвера. |
||
|
|
SlavaI
Главный специалист |
Я не помню как точно работает IRP трасер, там два варианта |
||
|
|
Pe
Гость |
Вроде 1 и есть 2. |
||
|
|
Pe
Гость |
Но IoCallDriver вызывает устройство. |
||
|
|
SlavaI
Главный специалист |
Ну устройство, а устройством кто управляет? этот IoCallDriver — это будет код твоего драйвера, который сам вызовет родной IoCallDriver если надо будет. Элементарно же. главный и основной пример пункта 2- driververifier |
||
|
|
Pe
Гость |
SlavaI, можешь пример кода привести, если например в диспетчерской процедуре фильтра только IoSkipCurrentIrpStackLocation и IoCallDriver ? |
||
|
|
SlavaI
Главный специалист |
берешь DDK и по папке source запускаешь поиск слова IoSkipCurrentIrpStackLocation |
||
|
|
Pe
Гость |
SlavaI, ты не понял, пример кода ко 2 пункту, если например в диспетчерской процедуре фильтра только IoSkipCurrentIrpStackLocation и IoCallDriver. |
||
|