Kernel mode driver что это
Перейти к содержимому

Kernel mode driver что это

Руководство по проектированию архитектуры драйверов Kernel-Mode

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

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

Этот раздел содержит общие сведения, описывающие и помогающие создавать драйверы режима ядра.

Обзор , содержащий:

компоненты режима ядра описывают основные диспетчеры режима ядра и компоненты операционной системы Windows.

написание драйверов wdm и введение в wdm предоставляют сведения, необходимые для записи драйверов с помощью WDM (WDM).

Объекты устройств и другие разделы в объектах устройств и в стеках устройств описывают, как операционная система представляет устройства по объектам устройств.

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

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

Обработка IRP описывает, как драйверы режима ядра обрабатывают пакеты запросов ввода-вывода (IRP).

Канал DMA Прямой доступ к памяти (DMA) — это важный аспект разработки драйверов, а темы на этом узле охватывают DMA от а до я.

Объекты контроллера представляют собой контроллер физического устройства с подключенными устройствами.

Программы-обработчики прерываний (ISR) обработают прерывания для драйверов физического устройства, принимающего прерывания.

Сигнальные прерывания вызывают прерывание, записывая значение в определенный адрес памяти.

Отложенные вызовы процедур (объекты DPC) могут быть поставлены в очередь из ISR и выполняться позже, а уровень IRQL — ниже, чем при ISR.

Plug and Play (PnP) специализируется на поддержке программного обеспечения для pnp и о том, как драйверы используют эту поддержку для реализации pnp.

Управление питанием описывает архитектуру, обеспечивающую комплексный подход к управлению питанием системы и устройств.

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

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

NVIDIA Windows Kernel Mode Driver перестал отвечать видеодрайвер

Обычно данная ошибка выражается в искажении изображения, появлении полос на экране или зависании. Она может быть устранена автоматически, и тогда пользователь увидит сообщение о том, что видеодрайвер NVIDIA Windows Kernel Mode Driver не отвечает, и был успешно восстановлен. В противном случае появится синий экран, и компьютер перезагрузится.

Скриншот ошибки Nvidia Kernel

Периодичность и обстоятельства появления ошибки NVIDIA

Если ошибка появляется редко или вовсе возникла единожды, то не стоит обращать на нее большого внимания. Если же оповещения о том, что NVIDIA Windows Kernel Mode Driver перестал отвечать, и был успешно восстановлен, на самом деле мешают работе, то следует попытаться установить, какие действия приводят в сбою – это ключ к решению проблемы. Если раньше сбоев не возникало, то необходимо изучить последние операции:

  • внесение изменений в настройки;
  • установку или удаление софта;
  • обновление ОС.

Если вместо восстановления драйвера возник синий экран, то потребуется сделать расшифровку дампа памяти.

Синий экран

Возможные причины

Проблема может иметь аппаратный характер, например, неисправность некорректная работа видеокарты или материнской платы. Если ПК был собран самостоятельно, то причиной ошибки может быть несовместимость компонентов. Иногда подобная ошибка появляется из-за чрезмерного нагрева видеокарты.

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

Устранение ошибки NVIDIA Windows Kernel Mode Driver перестал отвечать видеодрайвер

Возврат к старой версии драйвера или обновление. В некоторых случаях вернуть работоспособность помогает загрузка точки восстановления системы. Если это не так, то потребуется удалить драйверы с помощью диспетчера устройств. После этого рекомендуется выполнить очистку с помощью Driver Cleaner или аналогичной программы, чтобы окончательно избавиться от старых данных, и перезагрузиться. Теперь можно приступать к скачиванию драйверов и установке. Модель видеокарты указана в документации к компьютеру.

Окно удаления сведений

Переустановка (обновление) DirectX

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

Настройка видеокарты NVIDIA

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

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

Некоторым пользователям помогает исправить NVIDIA Windows Kernel Mode Driver незначительное снижение частоты и увеличение напряжения на видеокарте примерно на 5%. Сделать это можно с помощью программы NVIDIA Inspector. Следует обратить внимание, что некорректная настройка способна привести к сбоям, и начинающим пользователям определенно не рекомендуется ее выполнять.

Программа NVIDIA Inspector

Замена времени ответа в реестре

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

Эти действия разрешается выполнять только опытным пользователям!

Необходимо открыть реестр и перейти по адресу HKLM\System\CurrentControlSet\Control\GraphicsDrivers. Потребуется отредактировать значение ключа TDRDelay с 2 на 5, если это не помогло, то можно установить 10. Более радикальным способом является полное отключение проверки с помощью указания 0 в ключе TDRLevel.

Повторная установка Windows

Если ничего из этого не помогло, то придется полностью переустанавливать ОС. На некоторых моделях видеокарт наблюдается некорректная работа с определенными версиями Windows (особенно с неофициальными сборками). По этой причине для старого оборудования лучше установить Windows 7, а для нового – 10.

Когда и это не принесло результата, и ошибка NVIDIA Windows Kernel Mode Driver продолжает появляться, тогда, весьма вероятно, причина в технической неисправности. Более точное заключение можно получить только после проведения профессиональной диагностики.

Прятки по хардкору. Как сделать свой драйвер режима ядра Windows и скрывать процессы

Процессорные архитектуры x86 и x64 имеют четыре кольца защиты, из которых в Windows по факту используются всего два — это ring 3 (режим пользователя) и ring 0 (режим ядра). Бытует мнение, что код режима ядра — самый привилегированный и «ниже» ничего нет. На самом деле архитектура x86/x64 позволяет опускаться еще ниже: это технология виртуализации (hypervisor mode), которая считается кольцом −1 (ring −1), и режим системного управления (System Management Mode, SMM), считающийся кольцом −2 (ring −2), которому доступна память режима ядра и гипервизора.

Итак, мы решили писать собственный драйвер. Начнем с выбора инструментария. Я советую использовать Microsoft Visual Studio, как наиболее user-friendly IDE. Также необходимо будет установить Windows SDK и Windows Driver Kit (WDK) для твоей версии ОС. Кроме того, я крайне рекомендую запастись такими утилитами, как DebugView (просмотр отладочного вывода), DriverView (позволяет получить список всех установленных драйверов) и KmdManager (удобный загрузчик драйверов).

Драйверы в Windows начиная с Vista могут быть как режима пользователя (User-Mode Driver Framework, UMDF), так и режима ядра (Kernel-Mode Driver Framework, KMDF). Более ранние драйверы Windows Driver Model (WDM) появились в Windows 98 и сейчас считаются устаревшими.

Драйверы UMDF имеют намного более ограниченные права, чем KMDF, однако они используются, например, для управления устройствами, подключенными по USB. Помимо ограничений, у них есть очевидные плюсы: их намного проще отлаживать, а ошибка в их написании не вызовет глобальный системный сбой и синий экран смерти. Такие драйверы имеют расширение dll.

Что до драйверов режима ядра (KMDF), то им дозволено куда больше, а расширение файлов, закрепленное за ними, — это sys. В этой статье мы научимся писать простые драйверы режима ядра, напишем драйвер для скрытия процессов методом DKOM (Direct Kernel Object Manipulation) и его загрузчик.

Создание драйвера KMDF

После того как ты создашь проект драйвера, Visual Studio автоматически настроит некоторые параметры. Проект будет компилироваться в бинарный файл в соответствии с тем, какая выбрана подсистема. Наш вариант — это NATIVE, подсистема низкого уровня, как раз для того, чтобы писать драйверы.

Точка входа в драйвер

Строго говоря, точка входа в драйвер может быть любой — мы можем сами ее определить, добавив к параметрам компоновки проекта -entry:[DriverEntry] , где [DriverEntry] — название функции, которую мы хотим сделать стартовой. Если в обычных приложениях основная функция обычно называется main, то в драйверах точку входа принято называть DriverEntry.

Выглядеть это будет так:

Давай пройдемся по параметрам, которые передаются DriverEntry . pDriverObject имеет тип PDRIVER_OBJECT , это значит, что это указатель на структуру DRIVER_OBJECT , которая содержит информацию о нашем драйвере. Мы можем менять некоторые поля этой структуры, тем самым меняя свойства драйвера. Второй параметр имеет тип PUNICODE_STRING , который означает указатель на строку типа UNICODE . Она, в свою очередь, указывает, где в системном реестре хранится информация о нашем драйвере.

WARNING

Любая ошибка в драйвере может вызвать общесистемный сбой и BSOD. Вероятна потеря данных и повреждение системы. Все эксперименты я рекомендую проводить в виртуальной машине.

Interrupt Request Level (IRQL)

IRQL — это своеобразный «приоритет» для драйверов. Чем выше IRQL, тем меньшее число других драйверов будут прерывать выполнение нашего кода. Существует несколько уровней IRQL: Passive, APC, Dispatch и DIRQL. Если открыть документацию MSDN по функциям WinAPI, то можно увидеть примечания, которые регламентируют уровень IRQL, который требуется для обращения к каждой функции. Чем выше этот уровень, тем меньше WinAPI нам доступно для использования. Первые три уровня IRQL используются для синхронизации программных частей ОС, уровень DIRQL считается аппаратным и самым высоким по сравнению с программными уровнями.

Пакеты запроса ввода-вывода (Input/Output Request Packet)

IRP — это запросы, которые поступают к драйверу. Именно при помощи IRP один драйвер может «попросить» сделать что-то другой драйвер либо получить запрос от программы, которая им управляет. IRP используются диспетчером ввода-вывода ОС. Чтобы научить программу воспринимать наши IRP, мы должны зарегистрировать функцию обратного вызова и настроить на нее массив указателей на функции. Код весьма прост:

А вот код функции-заглушки, которая всегда возвращает статусный код STATUS_SUCCESS . В этой функции мы обрабатываем запрос IRP.

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

Здесь мы объявили процедуру с именем IRP_MY_FUNC и ее кодом — 0x801 . Чтобы драйвер ее обработал, мы должны настроить на нее ссылку, создав таким образом дополнительную точку входа в драйвер:

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *