Driver isolation что это
Driver isolation что это
Добрый день! Уважаемые читатели и гости блога pyatilistnik.org. Принтеры самое капризное место в работе системного администратора, именно на них чаще всего жалуются рядовые пользователю, у которых как обычно все очень срочно, горят отчеты, или нужно распечатать КП, Падение службы диспетчера печати (он же spooler) вследствие ошибок в драйверах печати является существенной проблемой ОС семейства Windows. Проблема усугубляется тем, что ошибки с драйверами печати довольно трудно диагностировать, а выявление проблемного драйвера может стать головной болью для системного администратора. Самое плохое, что сбой драйвера печати принтера, загруженного в процесс очереди печати, вызывал сбой самого спулера, в результате в результате вся система печати сервера перестает работать, и эти последствия затрагивают большое количество пользователей и принтеров. Однако вместе с выходом Windows 2008 R2 и Windows 7, все эти проблемы должны остаться в прошлом, ведь в этих ОС появилась технология Printer Driver Isolation (Изоляции драйверов принтеров).
Что такое изоляция драйвера
Вот так вот, очень часто выглядит ошибка, когда происходит конфликт драйверов, на сервере печати.
Как следует из названия, технология Printer Driver Isolation (PDI) реализует изоляцию драйверов принтеров в отдельные процессы, отделенные от процесса диспетчера печати (spoolsv.exe). Поэтому, если случается любая ошибка в драйвере принтера, то она затрагивает только процесс, которые подгрузил этот драйвер, а не процесс spoolsv.exe, тем самым предотвращая его падение и улучшая надежность сервера печати. Кроме того, эта новая функция обеспечивает возможность изоляции новых версий драйверов с целью тестирования или отладки, а также возможность выявить сбойный драйвер.
Процесс, осуществляющий загрузку драйверов, которые должны работать изолированно от «Диспетчера Печати», называется PrintIsolationHost.exe.Существует три режима работы технологии изоляции драйверов:
Чтобы проверить, поддерживает ли драйвер принтера технологию PDI: перейдите в следующую ветку реестра.
Если же значение отсутствует, значит оно равно 0, и драйвер PDI не поддерживает, как в моем примере у HP LaserJet Professional M1212nf MFP, хочу отметить, что вендоры могу выпускать свежие драйвера, которые уже будут поддерживать изолирование драйвера в отдельном процессе, так что если в реестре Windows вы обнаружили значение «0», то попробуйте найти новую версию драйверов на ваш принтер.
Как изменить режим работы Printer Driver Isolation
Есть несколько способов настроить режим работы режима изоляции драйверов печати:
С помощью inf файла драйвера принтера можно определить, поддерживает ли драйвер PDI или нет. Этот inf файл содержит ключ DriverIsolation, который определяет поддержку PDI. Соответственно, если значение этого параметра 0, значит данный драйвер PDI не поддерживает.
По умолчанию все драйвера в Windows лежат в папке:
Консоль Print Management (PMC)
С помощью новой консоли управления принтерами (PMC) можно достаточно просто управлять изоляцией драйверов. Если открыть консоль «Управление печатью (PMC)» и перейти в раздел драйверов, то в правой панели можно увидеть список установленных в системе драйверов, а в колонке Driver Isolation будет отображаться режим работы PDI драйвера принтера.
Чтобы изменить режим работы драйвера, нужно щелкнуть правой кнопкой по нужному драйверу и выбрать опцию ‘Set Driver Isolation‘. Доступны следующие опции:
Примечания:
Опция «По умолчанию отсутствует (System Default)» – означает, что драйвер работает в соответствии со своими стандартными настройками или настройками групповой политики.
Также если групповая политика ‘Execute Print drivers in isolated processes’ отключена (Disabled), тогда режим изоляции PDI поменять не получится.
Как изолировать драйвер принтера в Windows 7-03
Групповые политики, позволяющие управлять изоляцией драйверов
Существует две настройки групповой политики, позволяющие настроить режим изоляции драйверов принтеров. Найти их можно в разделе:
Настройки этой политики определяют будут ли драйвера принтера выполняться в одном или отдельных процессах. Если драйвера принтеров загружены изолированным процессом (или процессами), то любой сбой в драйвере печати не приведет к падению службы Print Spooler. В том случае если вы активировали или не настраивали данную политику, Диспетчер печати будет выполнять драйвера в изолированном процессе.
Если вы отключите данную политику, то драйвера принтеров будут исполняться в процессе диспетчера печати (как в версиях Windows XP/2003 и более ранних версиях ОС).
Политика: Override print driver execution compatibility setting reported by print driver
Политика определяет, должен ли Диспетчер печати переопределять режим работы PDI, заданный в драйвере принтера. Т.е. политика активирует выполнение драйверов в изолированном процессе, даже если драйвер принтера не совместим.
Если активировать эту политику, то спулер печати будет игнорировать флаг совместимости, заданный для драйвера принтера. Если отключить или не настраивать эту политику, print spooler будет использовать тот режим изоляции, который задан по-умолчанию в драйвере принтера.
Помимо технологии Printer Driver Isolation в Windows 7 и Windows 2008 появилась еще очень удобная технология, позволяющая существенно облегчить работы по управлению драйверами печати на терминальных серверах. Познакомится с ней можно в статье Easy Print в Windows 2008 Server
Driver Package Isolation
Driver package isolation is a requirement for Windows Drivers that makes driver packages more resilient to external changes, easier to update, and more straightforward to install.
While Driver Package Isolation is required for Windows Drivers, Windows Desktop Drivers still benefit from it through improved resiliency and serviceability.
The following table shows some example legacy driver practices that are no longer allowed for Windows Drivers in the left column along with the required behavior for Windows Drivers in the right column.
| Non-isolated Driver | Isolated Driver |
|---|---|
| INF copies files to %windir%\System32 or %windir%\System32\drivers | Driver files are run from the driver store |
| Interacts with device stacks/drivers using hardcoded paths | Interacts with device stacks/drivers using system-supplied functions or device interfaces |
| Hardcodes path to global registry locations | Uses HKR and system-supplied functions for relative location of registry and file state |
| Runtime file writes to any location | Files are written relative to locations supplied by the operating system |
For help in determining if your driver package meets Driver Package Isolation requirements, see Validating Windows Drivers.
Run From Driver Store
All isolated driver packages leave their driver package files in the driver store. This means that they specify DIRID 13 in their INF to specify the location for driver package files on install. For more information on how to use this in a driver package, see Run from Driver Store.
Reading and Writing State
If your component is using device or device interface properties to store state, continue to use that method and the appropriate OS API’s to store and access state. The following guidance for registry and file state is for other state that needs to be stored by a component.
Access to various registry and file state should be done by calling functions that provide a caller with the location of the state and then the state is read/written relative to that location. Do not use hardcoded absolute registry paths and file paths.
This section contains the following subsections:
Registry State
This section contains the following subsections:
PnP Device Registry State
Isolated driver packages and user-mode components typically use one of two locations to store device state in the registry. These are the hardware key (device key) for the device and the software key (driver key) for the device. To retrieve a handle to these registry locations, use one of the following options:
Device Interface Registry State
To read and write device interface registry state, use one of the following options:
Service Registry State
Service state should be classified into one of 3 categories
Immutable Service Registry State
Immutable service state is state that is provided by the driver package that installs the service. These registry values that are set by the INF for driver and Win32 services must be stored under the «Parameters» subkey of the service by providing an HKR line in an AddReg section, and then referencing that section in the service install section in the INF. For example:
To access the location of this state from the service at runtime, use one of these functions:
These registry values supplied by the INF in the “Parameters” subkey for the service should only be read at runtime and not modified. They should be treated as read only.
If the registry values supplied by the INF are default settings that can be overwritten at runtime, the override values should be written into the Internal Service Registry State or Shared Service Registry State for the service. When retrieving the settings, the setting can be looked for first in the mutable state. If it does not exist there, then the setting can be looked for in the immutable state. RtlQueryRegistryValueWithFallback can be used to help query settings such as these that have an override and a default value.
Internal Service Registry State
Internal service state is state that is written at runtime and owned and managed by only the service itself and is only accessible to that service. To access the location for internal service state, use one of these functions from the service:
If the service wants to allow other components to modify these settings, the service must expose an interface that another component can call into that tells the service how to alter these settings. For example, a Win32 service could expose a COM or RPC interface and a driver service could expose an IOCTL interface via a device interface.
Shared Service Registry State
Shared service state is state that is written at runtime and can be shared with other user mode components if they are sufficiently privileged. To access the location for this shared service state, use one of these functions:
File State
This section contains the following subsections:
Device File State
If files related to a device need to be written at runtime, those files should be stored relative to a handle or file path provided via OS API’s. Configuration files specific to that device is one example of what types of files to be stored here. To access the location of this state, use one of these functions from the service:
Service File State
Service file state can be classified into one of 3 categories
Immutable Service File State
Immutable service file state are files that are part of the driver package. For more information on accessing those files, see Run from Driver Store.
Internal Service File State
Internal service file state is state that is written at runtime and owned and managed by only the service itself and is only accessible to that service. To access the location for internal service state, use one of these functions from the service:
If the service wants to allow other components to modify these settings, the service must expose an interface that another component can call into that tells the service how to alter these settings. For example, a Win32 service could expose a COM or RPC interface and a driver service could expose an IOCTL interface via a device interface.
Shared Service File State
Shared service file state is state that is written at runtime and can be shared with other user mode components if they are sufficiently privileged. To access the location for this shared service state, use one of these functions:
DriverData and ProgramData
Files that are to be used as part of intermediate operations that can be shared with other components can be written to either DriverData or ProgramData locations.
These locations offer components a location to write temporary state or state that is meant to be consumed by other components and potentially collected and copied from a system to be processed by another system. For example, custom log files or crash dumps fit this description.
Avoid writing files in the root of the DriverData or ProgramData directories. Instead, create a subdirectory with your company name and then write files and further subdirectories within that directory.
DriverData
The DriverData directory is available in Windows 10, version 1803 and later, and is accessible to administrators and UMDF drivers.
ProgramData
The %ProgramData% user-mode environment variable is available for user-mode components to use when storing data.
Property State
Both devices and device interfaces support storing state via the PnP property model. The property model allows for structured property data to be stored against a device or device interface. This is meant for smaller data that reasonably fits into the property types supported by the property model.
To access device properties, these APIs can be used:
To access device interface properties, these APIs can be used:
Using Device Interfaces
If a driver wants to allow other components to read or modify the driver’s internal state, the driver should expose an interface that another component can call into that tells the driver what settings to return or how to modify particular settings. For example, the driver service could expose an IOCTL interface via a device interface.
Typically, the driver that owns the state exposes a device interface in a custom device interface class. When the driver is ready for other components to have access to the state, it enables the interface. To get notified when a device interface is enabled, user mode components can register for device interface arrival notifications and kernel mode components can use IoRegisterPlugPlayNotification. For these components to access the state, the driver enabling the interface must define a contract for its custom device interface class. This contract typically is one of two kinds:
Alternatively, if the driver that owns the state allows direct access to the state, other drivers could access state by using system-supplied functions for programmatic access to device interface state. See Device Interface Registry State for more information.
These interfaces or state (depending on sharing method used) need to be properly versioned so the driver owning the state can be serviced independently of other components that access that state. Driver vendors cannot rely on other components being serviced at the same time as the driver and staying at the same version.
Because devices and drivers controlling interfaces come and go, drivers and applications should avoid calling IoGetDeviceInterfaces at component start-up to get a list of enabled interfaces. Instead, the best practice is to register for notifications of device interface arrival or removal and then call the appropriate function to get the list of existing enabled interfaces on the machine.
For more information about device interfaces, see:
Как решить проблемы подсистемы печати в терминальном сервере
Сегодня я бы хотел поделиться своим опытом устранения проблем печати на терминальном сервере Microsoft.
Подробности под катом.
Вместо Intro
Наверняка, почти каждый системный администратор, работающий с Windows и, в частности, с терминальным сервером, сталкивался с проблемами печати.
Разрывается телефон, у всех одна и та же проблема: «Нажимаю на печать — ничего не происходит!». Идем смотреть логи и видим следующую картину:
Знакомо? Никаких подробностей, ничего — гадайте, господа администраторы! На форумах в интернете полно вопросов по этой теме и очень мало полных, структурированных ответов. Что ж, попробуем собрать в кучу все варианты решений.
Причины и решения
Итак, из-за чего может происходить подобная ситуация? Большую часть подобных ситуаций вызывают установленные на сервере драйверы.
А теперь пройдемся подробнее по всем пунктам. Для начала установим на наш терминальный сервер роль «Службы печати и документов».
Это позволит нам удобно управлять драйверами и принтерами, установленными в системе.
Идентичные драйвера
Думаю, тут особо не о чем рассказывать. Стоит помнить, что драйвера необходимо брать с официальных страниц изготовителя принтера. Так же еще один момент — стабильнее всего ведут себя PCL5. Если есть возможность выбора между PCL5 и PCL6 — стоит установить PCL5 (соответственно, серверу и клиенту).
Изоляция драйверов
В Windows 2008 появилась замечательная возможность изоляции драйверов принтера. Теперь драйвер принтера подгружается не Spoolsv.exe а специальным процессом PrintIsolationHost.exe. При «вылетании» драйвера принтера «слетает» только один экземпляр PrintIsolationHost.exe, а сама служба «Диспетчера печати» остается работоспособной, что, как понимаете, весьма влияет на настроение пользователей 😉
TS Easy Print
Далее, необходимо очистить наш сервер от лишних драйверов принтеров. Это можно сделать в менеджере роли «Службы печати и документов».
Внимательно удаляйте драйвера! Необходимо оставить в живых такие вещи, как «Remote Desktop Easy Print» и «Microsoft XPS Document Writer». Именно они и отвечают за передачу печати на клиента.
Решения сторонних компаний
Избавиться от проблемы падающего спулера призваны такое ПО как, например, ScrewDrivers (сайт). Оно предоставляет клиент-серверную архитектуру.
Сервер ScrewDrivers — это компонент, который необходимо установить на серверы, на которых планируется использовать печать в терминальном сеансе. Клиент ScrewDrivers должен быть установлен на рабочих станциях. Именно этот компонент позволяет создать на терминальном сервере виртуальные принтеры, которые соответствуют локальным принтерам пользователя.
В целом, напоминает Easy Print, но не бесплатно (впрочем, есть лекарства ;).
Как исправить проблему блокировки драйверов в Windows 10 из-за «изоляции ядра»
Если ваш компьютер имеет 64-битную архитектуру и поддерживает технологии виртуализации Intel VT-X или AMD-v (поддерживаются большинством современных процессоров), то в Windows 10 вам доступны дополнительные функции безопасности на базе виртуализации.
Одна из таких функций называется “Изоляция ядра” (Core Isolation). Она использует аппаратную виртуализацию для изоляции критически важных частей ядра операционной системы от пользовательских драйверов и программного обеспечения, запущенного на компьютере. Изоляция ядра позволяет предотвратить доступ вредоносных программ и эксплойтов к защищенным зонам ядра и заблокировать попытки обхода контроля безопасности, инъекции вредоносных программ и другое потенциально опасное поведение.
Функция под названием “Целостность памяти” (Memory integrity) является подмножеством изоляции ядра. Она защищает от внедрения вредоносного кода в память при вредоносной атаке.
Целостность памяти — это функция Windows, которая гарантирует надежность кода, работающего в ядре Windows. Она использует аппаратную виртуализацию и Hyper-V для защиты процессов режима ядра Windows от инъекции и выполнения вредоносного или непроверенного кода. Целостность кода, который работает в Windows, проверяется с помощью целостности памяти, что позволяет Windows эффективно противостоять атакам вредоносных программ.
“Целостность памяти” могла блокировать драйверы
При включении Memory Integrity, функция блокирует компьютер и может вызывать проблемы с загрузкой или работой драйверов.
В новом документе поддержки Microsoft пояснила, что ошибки или обычно неопасные уязвимости драйверов могут приводить к тому, что “Целостность памяти” блокирует их загрузку.
В таких ситуациях Microsoft рекомендует проверить доступность обновленного драйвера, в котором уязвимость уже может быть исправлена.
Если данный вариант не сработал, то рекомендуется отключить функцию Memory Integrity, чтобы драйвер мог корректно загрузиться.
Для отключения “Целостности памяти”, выполните следующие шаги:
В качестве альтернативы можно кликнуть по ссылке windowsdefender://coreisolation/ в Windows 10, чтобы открыть необходимую страницу.
После этого, проверьте, остались ли проблемы с загрузкой драйверов. Если проблема сохранилась, то вам лучше получить помощь у производителя устройства и уточнить, когда станет доступен обновленный драйвер.
Windows 10, версия 21H2: Новый параметр электропитания, изоляция драйверов, процесс taskbar.dll
Компания Microsoft добавит новую опцию в меню управления питанием, которая позволит пользователям выбирать, какие приложения должны перезапускаться после входа.
В новой тестовой сборке Windows 10 Build 21343 (Dev) Microsoft представила несколько визуальных изменений Проводника с новыми значками. Однако, это оказались не единственные изменения, потому что в меню управления электропитанием замечен новый параметр для запуска, который позволяет решить, следует ли запускать приложения после перезагрузки.
Эта опция называется «Restart apps after signing in» (Перезапускать приложения после входа). По умолчанию она отключена в системе, а при ее активации включается функция «Перезапускать приложения» в приложении «Параметры».
Саму функцию перезапуска приложений после входа нельзя назвать новой. Она уже давно является частью операционной системы, но добавление опции в стартовое меню сделает ее более легкодоступной.
Пользователь Twitter под ником Albacore обнаружил еще одно интересное изменение. Похоже, что Microsoft подготавливает функцию изоляции сторонних драйверов в Windows 10. Аналогичный подход компания применяет в Windows 10X.
Внутри папки Windows появилась новая директория OEMDRIVERS, в которой будут храниться сторонние драйверы вместо папки System32.
Более того, Albacore заметил, что панель задач будет перемещена в отдельный процесс. До сих пор панель задач была частью «explorer.exe», но после сборки 21343 процесс перемещен в taskbar.dll:
Удивительно видеть эти изменения спустя десятилетия. На данный момент Проводник все еще содержит код, но уже есть возможность перейти на реализацию с DLL. По-прежнему остаются некоторые странные ошибки, например полуразрушенный пользовательский интерфейс окна поиска.