Как зарегистрировать библиотеку dll в Windows 10 | Настройка оборудования

[упрощенное] описание процесса регистрации библиотеки

Утилита regsvr32 при помощи системной функции LoadLibrary загружает библиотеку и, в зависимости от того входных параметров [командной строки], выполняет:

Все это говорит в пользу того, что существуют определенные требования к структуре DLL, которую вы хотите регистрировать с помощью regsvr32. Для того, чтобы управляющий элемент можно было зарегистрировать с помощью regsvr32, в DLL должны быть реализованы функции DllRegisterServer, DllUnregisterServer, а при необходимости выполнения специфичных действий еще и функции DllInstall, DllUnInstall.

Функции DllRegisterServer / DllUnregisterServer содержат логику, которая фактически и выполняет регистрацию библиотеки в системе, добавляя записи в реестр, требующиеся для управляющего элемента. Функции DllInstall / DllUnInstall служат для выполнения дополнительных действий, которые планирует произвести автор DLL. Поэтому помните, что:

Далеко не все DLL могут быть зарегистрированы при помощи regsvr32!

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

В этом случае мы видим на экране ошибку: “Модуль ????????.??? загружен, но точка входа DllRegisterServer не найдена”. Но, давайте как перейдем, непосредственно, к самому процессу регистрации.

%windir%system32drivers

Это директория в файловой системе Windows, где размещаются непосредственно файлы драйверов. В современных операционных системах, а я говорю сейчас о Windows Vista и более поздних, драйвера в данной директории имеют расширения .sys в подавляющем своем большинстве, реже встречаются dll-файлы, однако общего смысла это не меняет, поскольку, вне зависимости от расширения, все они идентичны по структуре .dll-файлам. В более ранних операционных системах встречались такие форматы как .drv и .vxd.

%windir%system32driverstore

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

32-битные и 64-битные версии regsvr32

Начиная с Windows XP, в зависимости от разрядности ОС, утилита regsvr32.exe располагается либо только в директории %SystemRoot%System32 для 32-битных систем, либо в папках %SystemRoot%System32 и %SystemRoot%SysWOW64 для 64-битных (присутствуют две разные версии программы).

В данный момент более активно начали использоваться 64-битные версии Windows. Если в 32-битных версиях Windows всё было достаточно прозрачно и присутствовало только одна версия программы, то в 64-битных версиях ОС имеются две версии утилиты regsvr32:

Получается, в 64-битной системе разработчики сохранили прежнюю систему именования каталогов, однако поместили туда уже “родные” 64-битные приложения. Объясняется это обеспечением совместимости приложений и уменьшением временных затрат на трансляцию кода из 32- в 64-разрядную версию Windows.

Таким образом, в 64-битной версии Windows могут работать как 32-битные, так и 64-битные версии программ, соответственно, и DLL могут использоваться и 32- и 64-разрядные.Когда вы запускаете regsvr32 в 64-битной версии ОС для регистрации DLL, вы по-умолчанию используете 64-битную версию утилиты.

Для 64-битных ОС Windows существует золотое правило: директория System32 системы предназначается для родных 64-битных приложений, директория SysWOW64 для 32-битных. Немного не интуитивно, однако это сложившийся факт!! WOW64 (Windows on Windows64) – 32-битная подсистема, которая запускается в 64-битной среде.

Поэтому, если вам требуется зарегистрировать 32-разрядную версию библиотеки DLL в 64-разрядной ОС, и у вас возникает ошибка, то можно поступить следующим образом:

1. Открыть командную строку с правами администратора;
2. Если требуемая для регистрации 32-разрядная библиотека DLL находится в директории %SystemRoot%System32, переместить ее в папку %SystemRoot%SysWoW64;
3. Выполнить команду:
   %SystemRoot%SysWoW64regsvr32 <полный путь к библиотеке DLL>

   то есть, к примеру: %SystemRoot%SysWoW64regsvr32 %SystemRoot%SysWOW64test.dll

Если же перед вами стоит задача зарегистрировать 64-битную DLL в 64-разрядной ОС:

1. Открыть командную строку с правами администратора;
2. Если требуемая для регистрации 64-разрядная библиотека DLL находится в директории %SystemRoot%SysWOW64, переместить ее в папку %SystemRoot%System32
3. Выполнить команду:
   %SystemRoot%System32regsvr32 <полный путь к библиотеке DLL>

   то есть, например: %SystemRoot%System32regsvr32 %SystemRoot%System32test.dll

Hklmsystemcurrentcontrolsetcontrol

Куст реестра, содержащий информацию о разных параметрах конфигурации драйверов на этапе запуска операционной системы. Содержит такие важные ключи как:

• Class содержит информацию о классах инсталляции устройств, которые используются для группировки устройств, конфигурируемых и устанавливаемых схожим образом. Для каждого класса инсталляции в составе этого ключа имеется ключ, имя которого совпадает с именем GUID соответствующего класса инсталляции.
• CoDeviceInstallers содержит информацию о соинсталляторах класса
• DeviceClasses содержит информацию об интерфейсах устройств, зарегистрированных в системе. любой драйвер, который хочет взаимодействовать в системе с программами режима пользователя, должен предоставить интерфейс. Класс интерфейса устройства предоставляет функциональные возможности устройства и его драйвера другим системным компонентам и приложениям режима пользователя.

Hklmsystemcurrentcontrolsetenum

Куст реестра, содержащий информацию об устройствах, имеющихся в системе. PnP менеджер создает здесь ключ для каждого устройства в формате HKLMSYSTEMCurrentControlSetEnumEnumeratordeviceID. где Enumerator – это описанный выше в статье идентификатор шины, полученный на этапе перечисления устройств, deviceid – идентификатор типа устройств.

Ключ содержит следующую информацию: описание устройства, аппаратные идентификаторы (Hardware ID), идентификаторы совместимых устройств (Compatible ID) и требования к ресурсам. Куст зарезервирован для использования исключительно кодом операционной системой, поэтому пользовательским приложениям и драйверам не рекомендуется напрямую взаимодействовать с ним, предлагается использовать документированные системные функции.

Hklmsystemcurrentcontrolsetservices

Куст реестра, который используется для размещения информации обо всех сервисах (драйверах) в системе. Каждый системный драйвер размещает достаточно важную глобальную информацию о себе в подключах вида HKLMSYSTEMCurrentControlSetServices<

Имя_драйвера>, которая используется драйвером в процессе инициализации на этапе загрузки системы. Куст активно используется PnP менеджером для передачи параметров при вызове процедуры инициализации драйвера.В этом кусте размещаются такие элементы:

• ImagePath – содержит полный путь в двоичному файлу (образу) драйвера. программа инсталляции заполняет это значение на основе данных из inf-файла пакета драйвера;
• Parameters – хранит индивидуальную информацию драйвера, заполняется на основе данных, размешенных в inf-файле пакета драйвера;
• Performance – информация для мониторинга производительности устройства, контролируемого драйвером. Указывает имя DLL мониторинга производительности и имена функций, экспортируемых данной DLL. Заполняется на основании данных, полученных из inf-файла;

Inf-файл

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

Файл содержит команды, которые добавляют в реестр информацию, отвечающую за перечисление (Enum) драйвера и его класса (Class), и могут содержать указания для мастера установки оборудования по запуску так называемых основных установщиков (Class Installer, Установщик класса) и дополнительных установщиков (CoInstaller, Cоинсталлятор) для класса устройств и непосредственно устройства.

Соинсталлятор (по структуре обычная DLL) – дополнительный инсталлятор, вызываемый на этапе инсталляции, который выполняет специфичные для подкласса или устройства шаги установки, такие как подготовка инфраструктуры для работы драйвера в системе (например, установка пакета NET.Framework), вывод конфигурационных диалоговых окон, которые позволяют пользователю указать настройки для конкретного устройства.

Немаловажная особенность соинсталляторов заключается в том, что они, в случае необходимости выполняют привязку экземпляров нового устройства к требуемым для работы протоколам. Это, к примеру, может касаться разного рода коммуникационных устройств, которым требуются для работы различные протоколы и транспорты, такие как ndis, pppoe, tcpip, tcpip6, smb, netbt.В .inf-файле дополнительно описываются операции распаковки, копирования, запуска, переименования файлов, добавления и удаления ключей в реестре и многое другое.

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

Динамические библиотеки

Дальнейшее развитие данной концепции (а так же развитие ОС) привело к появлению динамически загружаемых библиотек (называемых упрощенно динамическими библиотеками, DLL). Отличительной особенностью было то, что обращение к функционалу этих библиотек могло осуществляться из кода на любых языках и из любых средств разработки [в рамках операционной системы].

На механизме динамических библиотек построен весь программный интерфейс (WinAPI) операционных систем Mirosoft Windows, поэтому любое API, любой сервис, так или иначе базируются на DLL. Характерная особенность динамической библиотеки заключается в том, что она может использоваться сразу несколькими приложениями, а система обеспечивает присутствие в памяти всего-лишь одного экземпляра [кода] динамической библиотеки для всех приложений, которые содержат ссылки на функции данной библиотеки. DLL имели ряд выраженных недостатков:

• при загрузке динамической библиотеки [в адресное пространство процесса] использовалось лишь её символическое имя, поскольку отсутствовал механизм устойчивой идентификации необходимых библиотек, соответственно:
• в подгруженной библиотеке [сторонней/не той версии] мог содержаться код, разрушающий структуры данных и кода вызывающего приложения.
• подгружаемая библиотека [сторонняя/не той версии] могла использовать контекст безопасности основного приложения для получения доступа к ресурсам, к которым в обычных условиях доступа у нее нет.
• не проверяется информация о типах параметров функции;
• не проверяется корректность передаваемых параметров функции;

Журнал драйвера

Если Вы используете Диспетчер пакетов (Package Manager, pkgmgr) для инсталляции/деинсталляции пакета, который (в свою очередь) инсталлирует, обновляет, либо деинсталлирует драйвер, то у Вас есть возможность включить (с целью отладки) создание специального лог-файла drivers.log, который будет содержать только ошибки, специфичные для конкретного драйвера.

Для создания этого журнала, создайте/задайте следующий ключ реестра, и затем запустите pkgmgr снова. После этого, в директории, откуда был запущен pkgmgr, будет создан файл drivers.log.Ветка: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionDevice InstallerКлюч: DebugPkgMgrТип: DWordЗначение: 1

Инсталляция драйвера

На этом этапе пакет драйвера стороннего разработчика развертывается в системное хранилище драйверов. Затем, система выполняет фактическую инсталляцию драйвера из хранилища драйверов, которая производится посредством утилиты %Windir%System32drvinst.exe. На этом этапе происходят следующие события:

• inf-файл драйвера копируется в специализированную папку %Windir%/inf. Для драйверов сторонних разработчиков характерно переименование файла в OEMx.inf, где x – порядковый номер inf-файла в директории.
• Код операционной системы фиксирует факт инсталляции inf-файла в реестре.
• Создается узел устройства (devnode) в реестре по пути HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnum<Enumerator><device id><instance id>, который содержит подробную информацию об устройстве.
• Двоичные файлы драйвера копируются в целевую папку %Windir%System32DRIVERS и, возможно, другие целевые папки. Обновляются разделы реестра.
• Формируется ключ реестра, соответствующий драйверу: HKLMSYSTEMCurrentControlSetServicesимя_драйвера. Формируются параметры ключа.
• Формируется ключ реестра, отвечающий за логгирование событий драйвера, размещающийся в ветке HKLMSYSTEMCurrentControlSetServicesEventLogSystemимя_драйвера.
• PnP менеджер вызывает процедуру DriverEntry для каждого установленного только что драйвера. Затем PnP менеджер режима ядра пытается “запустить” драйвер, подгружая его в память и вызывая процедуру AddDevice драйвера для информирования самого драйвера о присутствии устройства, для которого он был загружен.

Использование «открыть с помощью»

Чтобы использовать данный инструмент, необходимо открыть папку System32. Затем выполнить несколько последовательных шагов:

• по файлу audiosrv кликнуть правой клавишей мышки, откроется дополнительное меню действий;

• нажать строку «Открыть с помощью»;

• выбрать пункт «Обзор», затем – программу System32 или SysWow64 (в зависимости от разрядности действующей операционки).

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

Компонентная объектная модель (com)

Следующим этапом развития концепции разделяемого кода стало появление компонентной объектной модели (COM, Component Object Model). COM обеспечивал возможность разделять код на отдельные независимые компоненты, которые (в отличие от предыдущих реализаций) подключались уже не по имени файла, а при помощи специального глобального идентификатора (GUID).

GUID ни что иное как 128-битный глобальный идентификатор (GUID, Global Unique ID), идентифицирующий конкретный объект класса библиотеки. Каждый компонент определялся [глобально] собственным уникальным идентификатором, и в системе хранилась единая база информации по компонентам, в которой содержалась вся информация: начиная от имени файла, в котором расположен сам компонент, и заканчивая сетевыми настройками. База COM хранится в реестре, в разделе HKEY_CLASSES_ROOT:

Причем сам HKEY_CLASSES_ROOT представляет собой комбинацию разделов HKCUSoftwareClasses (для текущего пользователя) и HKLMSoftwareClasses (для машины в целом).

Чтобы как-то отличать идентификаторы классов от иных [похожих] системных идентификаторов, применительно к СОМ эти идентификаторы называются идентификаторами класса, и для них используется аббревиатура CLSID.

Примером значения CLSID может служить строка вида {2DB47AE5-CF39-43C2-B4D6-0CD8D90946F4}. В глобальном смысле данные уникальные номера “не повторяются” и уникально идентифицируют компоненты системы, что говорит нам об уникальности объекта класса библиотеки в пределах системы. Подразделами в этих ветках реестра могут быть:

То есть параметр (default) этих ключей содержит полный путь к зарегистрированной библиотеке.Тем не менее в компонентной объектной модели так же присутствовал ряд проблем:

• COM базируется на динамических библиотеках (в них то и размещаются компоненты). А как мы помним с DLL сохранялась проблема, связанная с совпадением имён файлов библиотек;
• База данных COM располагается в реестре, и работать с ней предлагалось напрямую, без какого-либо специализированного API. При том, что раздел базы данных является общедоступным, после продолжительной эксплуатации системы он традиционно приходил в рассогласованное состояние (приводящее к множеству системных ошибок).

Линейное программирование

На заре развития языков программирования, при создании (разработке) программ использовался так называемый линейный подход, который заключался в том, что код писался/выполнялся “сверху-вниз”, в четкой последовательности от начала к концу. Но как только человек научился писать код чуть сложнее, чем простой вывод фразы “Hello, World!”, перед ним тут же встало несколько проблем, которые показали, что подход имеет очевидные недостатки:

• исходный код необходимо было копировать из старого проекта в новый;
• копирование старого кода приводило к ошибкам, путанице, нестыковкам, необходимости исправления и подгонки под новый проект;

Новый метод

Как мы уже говорили, для регистрации библиотеки используется функция DllRegisterServer(). Функция проверяет 128-битный глобальный идентификатор (GUID, Global Unique ID) всех объектов COM/ActiveX, обнаруженных в библиотеке и последовательно прописывает информацию о них в реестр.

Тут мы видим что происходит как бы не регистрация библиотеки, а регистрация объектов в библиотеках. Как мы уже говорили выше, регистрация объектов необходима, поскольку программы работают не с самими файлами DLL/OCX/ACX, а с объектами, представляющими определенный набор интерфейсов.

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

Если вам необходимо поменять расположение библиотеки DLL в системе (например, поменять директорию размещения), то потребуется её перерегистрация.

Обнаружение драйверов

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

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

Мастер установки драйверов устройств инициирует поиск подходящего для устройства драйвера по информации из всех inf-файлов системы, расположенных в следующих доверенных системных расположениях:

• Хранилище драйверов;
• Центр обновления Windows;
• Системный каталог INF-файлов;

Для вышеописанных целей поиска и установки драйвера используются функции библиотек setupapi.dll (функции поддержки инсталляции) и cfgmgr32.dll (менеджер конфигурации). В процессе поиска используются полученные уже на данный момент идентификаторы HardwareID и (опционально)

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

Списки идентификаторов упорядочены, поэтому более специфичные описатели оборудования представлены в списках первыми. Если совпадения идентификаторов были найдены в нескольких inf-файлах, более точное совпадение считается предпочтительным по отношению к менее точному совпадению, подписанные inf-файлы предпочитаются неподписанным, и подписанные позднее inf-файлы предпочитаются подписанным ранее.

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

Оверлеи

В условиях дороговизны оперативной памяти и отсутствия у многих операционных систем того времени (MSDOS) механизма виртуализации адресного пространства процесса (виртуальной памяти), обеспечивающего достаточное адресное пространство для приложений, появилась необходимость загружать в ограниченное пространство [дорогой] физической памяти много превосходящие по размеру код/данные приложений.

Следствием всего этого явилось разбиение кода/данных программы на обособленные модули, получившие название оверлеев (overlay). Данный механизм непрямую не связан с разделением кода, тем не менее мы о нем упомянем, как о существенной вехе в развитии механизмов разделения кода.

Перечисление устройств

Целиком стадию загрузки с самого ее начала описывать смысла нет, и мы начнем с только с интересующего нас этапа, на котором модуль Winload(.efi) загружает ядро операционной системы Windows 7 из файла ntoskrnl.exe.

Ядро запускает PnP менеджер, являющийся частью исполнительной подсистемы. PnP менеджер стартует процесс перечисления устройств с корневого устройства, драйвера виртуальной шины под названием ROOT (Корень), который олицетворяет собой всю систему и представляет из себя драйвер шины вообще для всех PnP- и не-PnP-устройств, а так же HAL (уровня аппаратных абстракций).

HAL на этом этапе функционирует как драйвер шины, который перечисляет устройства, напрямую подключенные к материнской плате. Однако, HAL вместо фактического перечисления полагается на описание оборудования, уже присутствующее в реестре.

Цель HAL на данном этапе – обнаружить первичные шины, такие как PCI. Драйвер первичной шины PCI, в свою очередь, перечисляет устройства, подключенные к данной шине, находит другие шины, для которых PnP менеджер тут же загружает драйвера.

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

В процессе перечисления PnP менеджер строит дерево устройств (device tree), которое однозначно описывает отношения между всеми устройствами системы. Узлы этого дерева, именуемые devnodes (сокр. от “узлы устройств”), содержат информацию об объекте устройства, который, в свою очередь, подробно описывает устройство.

где:

• Enumerator – наименование драйвера шины. Может принимать значения: ACPI, DISPLAY, HDAUDIO, HID, HDTREE, IDE, PCI, PCIIDE, Root, STORAGE, SW, UMB, USB, USBSTOR и другие;
• DeviceID – уникальный идентификатор для данного типа устройств;
• InstanceID – уникальный идентификатор различных экземпляров одного и того же устройства.

Дело в том, что драйвер шины, к которой подключено устройство, запрашивает у устройства различные параметры (идентификатор производителя, устройства, ревизии и прч) и формирует так называемый аппаратный идентификатор (HardwareID), который однозначно описывает устройство и представляет из себя строку параметров, разделенных знаками & и состоящую из следующих частей:

• Префикс, описывающий шину, к которой подключено устройство.
• Идентификатор устройства. Состоит из нескольких частей, таких как идентификатор производителя, идентификатор продукта (модели), ревизия устройства.

HardwareID – идентификационная строка, зависящая от параметров устройства (производитель, модель, ревизия, версия и прч), которую Windows использует для сопоставления устройства с .inf-файлом драйвера.

Типичная структура HardwareID:

PCIVEN_10DE&DEV_1341&SUBSYS_2281103C&REV_A2

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

Идентификаторы HardwareID и CompatibleID используются кодом исполнительной подсистемы Windows для поиска драйвера устройства.

Прерывания

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

Данный сервис мог лешгко программироваться пользователями, то есть любая программа могла [пере]назначить одно из доступных программных прерываний, предоставив, таким образом, общесистемный сервис. И не смотря на все положительные стороны подобного подхода, он имел и ряд серьёзных недостатков:

• Фиксированное количество сервисов, ограниченное размером таблицы векторов прерываний (255);
• Отсутствие обработки исключительных ситуаций.
• Отсутствие системы безопасности;
• Обособленный синтаксис, несовместимости с синтаксисом языков высокого уровня (необходимость оперировать низкоуровневыми регистрами);
• Отсутствие контроля типов и корректности данных;

Проверка цифровой подписи драйвера

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

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

Следующим шагом часть кода PnP менеджера, работающая в пользовательском режиме, проверяет системную политику подписания драйверов. Если системная политика предписывает коду ядра блокировать или предупреждать об инсталляции неподписанных драйверов, то PnP менеджер парсит inf-файл драйвера на предмет наличия директивы CatalogFile, указывающей на файл каталога (файл с расширением .cat), содержащий цифровую подпись пакета драйвера.

Файл каталога (.cat) – специальный файл, который играет роль цифровой подписи для всего пакета драйвера, потому как отдельно каждый файл, входящий в комплект пакета драйвера, не подписывается. Исключение составляют лишь двоичные файлы драйверов ядра этапа загрузки, но их проверяет отдельный код ядра.

Для тестирования драйверов и их подписания была сформирована лаборатория Microsoft Windows Hardware Quality Lab (WHQL), обстоятельно тестирующая драйвера, поставляемые с дистрибутивами Windows, а так же драйвера от крупных поставщиков оборудования.

Для всех остальных разработчиков драйверов предусмотрены процедуры получения возможности самостоятельно подписывать драйвера на платной основе. Когда драйвер проходит все тесты WHQL, он становится “подписанным”. Это означает, что для драйвера WHQL формирует хэш, или уникальную сигнатуру, однозначно идентифицирующую файлы драйвера, и затем подписывает ее с применением криптографических алгоритмов при помощи специального закрытого ключа Microsoft, используемого для подписания драйверов.

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

Если хэши совпадают, драйвер маркируется как прошедший WHQL тестирование. Если сигнатуру не удается проверить, PnP менеджер действует в соответствии с настройками системной политики подписи драйверов, либо запрещая инсталляцию драйвера, либо все же позволяя инсталлировать драйвер.

Процедуры (функции)

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

Это существенно упростило архитектуру приложения, решило важную проблему дублирующегося кода, поскольку теперь вместо того, чтобы программе использовать повторяющиеся участки кода на протяжении всего процесса выполнения, проще разместить его в отдельной процедуре (функции) и многократно вызывать [по мере необходимости]. Тем не менее, данный подход требовал доработки, поскольку:

• позволял разделять код программы на логические части лишь в рамках одной языковой среды разработки.

Регистрация dll в windows

Теперь самое интересное — как зарегистрировать библиотеку dll в Windows. Нажимаем кнопку Пуск правой кнопкой мыши и выбираем в контекстном меню пункт «Выполнить»:

Того же самого эффекта можно достигнуть нажав комбинацию клавиш WIN R. Повявится вот такое окно «Выполнить»:

В строку «Открыть» надо ввести вот такую команду:

regsvr32 <полный_путь_к_файлу_библиотеки>

В качестве примера давайте зарегистрируем библиотеку runtime.dll для 32-хбитной версии Windows 10. команда будет такой:

regsvr32 C:WindowsSystem32runtime.dll

Нажимаем на кнопку «ОК» и ждём что нам ответит система.  Если всё правильно — она просто «съест» файл. Но случается и ошибки. Вот самая распространённая:

Связана она либо с ошибкой в пути или имени файла, либо с неправильно выбранной папкой, в которую была скопирована ДЛЛ-ка для регистрации. Стоит ещё раз всё тщательно проверить.

Сборки (assembly)

Следующая попытка усовершенствовать механизмы распределения кода была предпринята в процессе разработки платформы .NET Framework. В процессе разработки платформы было предложено решение, в основе которого лежат так называемые сборки (assembly), которые являются наименьшими строительными блоками .NET, призванными обеспечить безопасное разделение кода в .NET-приложениях.

Сборка (assembly) – коллекция типов и ресурсов, сгруппированная в один или нескольких файлов для совместного функционирования, образующая логическую функциональную единицу.

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

Синтаксис regsvr32

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

В большинстве случаев, для регистрации DLL требуются повышенные привилегии, то есть права локального администратора.

Утилита regsvr32.exe имеет следующие параметры командной строки:

Regsvr32 [/u] [/s] [/n] [/i[:cmdline]]

Список ключей утилиты и описание их действия приведем в следующей таблице:

В общем случае, регистрация библиотеки DLL при помощи regsvr32 может быть выполнена следующей командой:

regsvr32 .dll

Например:

regsvr32 “C:WindowsSystem32schmmgmt.dll”

Напоминаю, будьте внимательны с версиями утилиты regsvr32 под Windows различной разрядности. В некоторых случаях приходится уточнять путь к утилите при запуске.Более того, практически всегда, когда регистрируемый компонент лежит вне путей, включенных в переменную %PATH% (к примеру, если он не находится в %SystemRoot%System32), путь к компоненту приходится уточнять!Пример:

%SystemRoot%System32Regsvr32 %SystemRoot%System32macromedFlashFlash10a.ocx

*Составные пути к файлу должны заключаться в кавычки по правилам синтаксиса командной строки Windows.

Смысл регистрации библиотек и элементов управления

Но, вернемся к нашим библиотекам 🙂

По какой причине, для использования функций DLL в системе непременно требуется их регистрация? Ответ: чтобы система смогла их найти!!

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

Я думаю, вполне уместно было бы привести аналогию с системной переменной пути (%PATH%). Как Вы помните, файлы, которые располагаются в директориях, указанных в переменной %PATH%, можно запускать из командной строки без указания полного пути.

В случае же отсутствия директорий в переменной %PATH%, указанные файлы невозможно будет запустить из произвольного местоположения в операционной системе, командный интерпретатор их попросту “не найдет”. По аналогии и библиотеки, которые содержат функции, широко используемые различными программами, должны быть “объявлены” в системе, иначе программы не смогут их “найти”.

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

Если опираться на историю развития технологии распределенного кода, то можно сделать вывод, что regsvr32 обеспечивает регистрацию как классических библиотек DLL, так и продвинутых их собратьев, содержащих COM-объекты, поскольку со сборками .NET утилита уже не работает.

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

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

Зачастую нет необходимости самостоятельно (вручную) регистрировать DLL, практически всегда это выполняется автоматически при инсталляции компонентов системы/программы. Необходимость в ручной регистрации возникает, как правило, в случае каких-либо ошибок в системе: проблем инсталляции/деинсталляции программ, сбоях, либо в случае самостоятельно разрабатываемых DLL, которые необходимо оттестировать.

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

Ошибка сообщает нам о том, что загрузчик образа cDSsvc.exe не смог найти библиотеку MFC71.DLL, необходимую ей для функционирования. Один из способов устранения данного класса ошибок состоит в повторной инсталляции программы, в ситуации, когда файл искомой библиотеки входит в состав какого-либо дистрибутива, поскольку библиотека инсталлируется автоматически скриптом инсталляции.

Если библиотека входит в состав другого пакета, например Microsoft Visual C 2022 x64 Redistributable, то переустановить необходимо именно его. Если же описанными способами ошибку исправить все же не удается, тогда нам на помощь приходит утилита Regsvr32.

Способ 1

Перед тем, как переходить к непосредственному осуществлению регистрационного процесса необходимо отметить, что при использовании операционной системы Windows 64-битной разрядности создаётся два различных варианта «regsvr32.exe», с применением которого и связана вся последующая работа.

Один находиться в «C:WindowsSysWOW64», второй в «C:WindowsSystem32», и при этом 64-битная версия располагается именно в «System32».

Последующие действия заключаются в следующем:

Если всё прошло корректно, то в ответ на выполнение команды вам будет предоставлено уведомление об успешной регистрации файла dll.

Способ 1: запуск «командной строки» от имени администратора

Самая частая причина отказа функционирования Regsvr32 — запуск консоли с правами обычного пользователя. Эта утилита нуждается в повышенном уровне доступа, поскольку редактироваться будут именно системные файлы, поэтому выполнять ее следует только от имени администратора.

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

Подробнее: Используем учетную запись администратора в Windows

Способ 2: перенос файла в «syswow64»

Обратим внимание, что использовать этот способ стоит только тем юзерам, кто обладает 64-разрядной операционной системой и пытается зарегистрировать или выполнить другие действия с 32-битным файлом. Дело в том, что по умолчанию практически все динамически подключаемые библиотеки помещаются в директорию «System32», но компоненты, имеющие разрядность 32 бита и находящиеся в 64-разрядной Виндовс, должны быть помещены в папку «SysWoW64», чтобы выполнение определенных действий прошло успешно. Из-за этого возникает надобность произведения следующих действий:

1. Перейдите по пути C:WindowsSystem32, где C — буква системного раздела жесткого диска.



2. Отыщите там файл, с которым хотите осуществить манипуляции через Regsvr32. Щелкните по нему правой кнопкой мыши.



3. В появившемся контекстном меню вас интересует опция «Вырезать» или «Копировать».



4. Теперь вернитесь к папке «Windows», где кликните ПКМ по библиотеке «SysWOW64».



5. В контекстном меню выберите «Вставить».



6. Запустите консоль от имени администратора так, как это было продемонстрировано в первом способе. Используйте команду %systemroot%SysWoW64regsvr32 name.dll, где name.dll — полное название динамически подключаемой библиотеки, не забывая при этом применять аргументы.

Еще раз уточним, что этот метод подходит только в ситуации, когда рассматриваемая утилита отказывается функционировать с каким-то конкретным файлом в 64-битной операционной системе. В остальных случаях эти действия не принесут вообще никакого результата.

Способ 3: проверка системы на вирусы

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

Подробнее: Борьба с компьютерными вирусами

Способ 4: проверка целостности системных файлов

Если во время проверки на вирусы они все же были найдены и удалены, вполне возможно, что угрозы оставили след на системных файлах, повредив их. Иногда это приводит к отказу работы некоторых утилит, в том числе и Regsvr32. Запуск проверки целостности системных файлов доступен с помощью стандартного инструмента SFC, однако иногда и он завершает свою работу, выводя на экран ошибку «Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них».

Тогда следует обратиться к средству DISM. Оно предназначено для восстановления хранилища компонентов. Только после успешного выполнения этой операции вы можете вернуться к SFC, чтобы закончить сканирование и отладку целостности. Детальнее обо всем этом читайте в отдельном руководстве.

Подробнее: Использование и восстановление проверки целостности системных файлов в Windows

Способ 5: восстановление windows

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

Подробнее: Варианты восстановления ОС Windows

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

Перейти к официальной информации об ошибках Regsvr32

Старый метод

В дополнение к современному методу работы с COM-объектами, в реестре присутствует еще и ветка HKLMSOFTWAREMicrosoftWindowsCurrentVersionSharedDLLs. Могу предположить, что она относится к устаревшему методу регистрации общих библиотек DLL, базирующемуся на подсчете количества ссылок на библиотеку.

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

Windowssystem32VBAME.DLL). Значение параметра может варьироваться от 1 до 65535. Дело в том, что значение это – счетчик использования или, как еще называют, количество ссылок. Зачастую этот метод регистрации использовался не-MSI инсталляторами.

Каждый раз, когда какой-либо подобный установщик самостоятельно регистрирует в системе библиотеку, которая до этого уже была зарегистрирована кем-либо еще (то есть присутствует в SharedDLLs), он увеличивает счетчик использования на 1, когда же (например, при удалении) библиотека разрегистрируется, то счетчик уменьшается на 1.

Подобная логика была реализована в первых версиях Windows для борьбы с таким явлением как “Ад DLL”(DLL Hell). У параметров некоторых библиотек можно наблюдать достаточно большие значения (4096), полагаю, таким образом маркируются критичные для системы библиотеки, и счетчик искусственно увеличен с той целью, чтобы разнообразные пользовательские пакеты при своем удалении, случайно не уменьшили счетчик использования до 0 и не выключили DLL.

Термины и определения

В данной статье я приведу описание только одного метода установки, который, в любом случае, описывает практически все этапы алгоритма установки драйвера в Windows, которые применимы и к другим способам. И разговор у нас сейчас пойдет о ситуации, когда пользователь вставляет во внутренний разъем выключенного компьютера новое оборудование, например видеокарту.

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

Блок режима ядра взаимодействует с остальными компонентами системы в процессе загрузки/установки программного обеспечения, необходимого для обслуживания имеющихся в системе устройств. Блок пользовательского режима (%Windir%System32umpnpmgr.dll, запускается в контексте главного системного процесса svchost.exe) отвечает за взаимодействие с пользователем в ситуациях, требующих установки новых драйверов или настройки рабочих параметров в уже инсталлированных.

Отвечает за назначение и последующее распределение аппаратных ресурсов, таких как прерывания (IRQ), порты ввода-вывода, каналы прямого доступа к памяти (DMA) и адреса памяти. Имеет функционал определения драйвера, требуемого для поддержки определенного устройства и функционал загрузки/инсталляции данного драйвера.

Хранилище драйверов

Мастер установки драйверов пытается обнаружить подходящий inf-файл в системном хранилище драйверов, располагающемся в каталоге %Windir%System32DriverStore, который содержит все без исключения драйвера системы, входящие в состав дистрибутива Windows, полученные через службу “Windows Update”, либо инсталлированные в систему пользователем.

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

Хранилище драйверов было впервые введено в Windows Vista. Перед установкой любого драйвера в систему, сначала специализированный код проверяет цифровую подпись драйвера, затем синтаксис inf-файлов драйвера, затем привилегии текущего пользователя, только после этого помещает все компоненты драйвера в системное хранилище драйверов.

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

Заключение

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

1. Найдите информацию о том, какой именно функционал выполняется проблемным файлом, и посмотрите с какими системными компонентами он поставляется. Например, файлы, начинающиеся с «d3d», идут в комплекте с «DirectX», который доступен для скачивания на официальном сайте «Microsoft».
2. В большинстве случаев, пиратские версии программного обеспечения и игр поставляются с собственными файлами динамической библиотеки, которые необходимы для их работы.
   Данное обстоятельство приводит к тому, что файл с расширением «exe» обращается не к копии, которая находится в системном каталоге, а к собственному варианту, что и вызывает ошибку.
   Следовательно, для её исправления потребуется просто удалить «несанкционированную копию» из папки с используемым программным продуктом.

Похожее:

Настройка оборудования Reg dll windows 10 Fix mqrt.dll сообщения об ошибках отсутствует или не найден Как создать файл inf