So what is Print Driver Isolation? As the name implies, this feature allows some of the print driver components to be executed in a process (or processes) separate from the print spooler. By doing this, any problems associated with faulty drivers are isolated from the print spooler service and will not cause it to fail. For those of you that have been around since the Windows NT days, I’m sure you remember how a bad print driver could bugcheck the system. Back then it was because print drivers were kernel-mode (Version 2) drivers. With the move to user-mode (Version 3) drivers, bad print drivers only affected the spooler, and didn’t bring down the whole system. With PDI, we’re taking this a step further – the isolated print drivers that are faulty affect … well, themselves. They don’t take down the entire printing system. All kidding aside though, there are clearly benefits that PDI brings to the table. Aside from the overall print system stability improvements, PDI provides a means to isolate new drivers for testing / debugging without affecting the spooler and also makes it easier to identify which drivers have been causing crashes. One quick caveat here – Print Driver Isolation only isolates print driver components from the print spooler. If an application loads a print driver into its own process space, and that driver crashes, then it is possible that the application might also crash.
Before we get into the workings of Print Driver Isolation, it helps if you have a good grasp of printing architecture. If you need a refresher, take a look at our post on Basic Printing Architecture from a couple of years ago.
OK, back to PDI. There are three basic modes of isolation that can be configured for individual print drivers:
- None – in this mode, print driver components are loaded into the spooler process. This is essentially the model found in previous versions of Windows
- Shared – multiple drivers that are set for isolation are loaded into a single shared process space that is separate from the spooler process. Although this protects the spooler process, the drivers that are in shared mode can affect one another
- Isolated – each driver is loaded into its own process space. This protects the spooler from individual driver failures, and also protects drivers from each other
Remember that the modes are configured on a per-driver and not a per-system basis. One other point to keep in mind – not all drivers will run in shared or isolated mode. Drivers that call spooler functions or a printer’s configuration module directly will need to run in “none” mode. The driver developer can advertise whether or not their driver supports isolation mode. Now lets take a look at how the new model works.
Anytime shared or isolated mode is used for a print driver, a new process – PrintIsolationHost.exe – is launched by the DCOM Server Process Launcher for each “print sandbox”. The print processor, the rendering module, the configuration module and the miscellaneous driver files are loaded into the address space for the new process, instead of the spooler’s process. The spooler essentially proxies calls for the print processor and other driver components in the PrintIsolationHost.exe process and DCOM is used for inter-process communications. Something to note here – if you examine the spooler closely you’ll find that the print processors are loaded into both the spoolsv.exe and the ProcessIsolationHost.exe processes when shared or isolated modes are used. For the print driver that you put into shared or isolation mode however, all the processing takes place in the processor in the ProcessIsolationHost.exe process. The duplicate loading of print processors is to accommodate drivers that may be running in “none” mode at the same time.
Let’s look at what this looks like in Process Explorer. We’ll look at Isolation Mode since that is the most complex of the three modes. In this mode, there are a number of differences from the printing model that we have been used to. As we mentioned above, the print processors and print driver components for each isolated driver are loaded into a separate PrintIsolationHost.exe process. Within the spoolsv.exe process and all PrintIsolationHost.exe processes, there is a new DLL, PrintIsolationProxy.dll that proxies the calls for specific printers between the processes. In the screenshot below, we can see that the spoolsv.exe process is running as normal – the printers installed are all running with no isolation mode specified.
Now let’s take a look at what happens when we put two print drivers into Isolation mode. Initially you won’t see anything in your Process Explorer view. However, once the printer is used, you’ll see the PrintIsolationHost.exe processes and the PrintIsolationProxy.dll
The reason that you don’t see the PrintIsolationHost.exe process spawn immediately after switching a driver to isolation mode is for better resource management. The process is called when needed, and is closed when not required. In shared mode, the printing model is very similar to isolated mode, except that you will only see one PrintIsolationHost.exe process – unless you also have drivers running in full isolation mode at the same time.
Now that we’ve covered some of the basics of PDI, let’s talk about configuring PDI via Group Policy. There are two new group policy settings that you can use to control the isolation mode of drivers on machines to which the policy applies. Both settings are in the Computer Configuration\Administrative Templates\Printers . The two settings are:
-
Execute Print Drivers in Isolated Processes
– there are two settings
- Disabled – Completely disable driver isolation, resulting in all the print drivers being loaded into the print spooler process as in previous OS versions. This would be a way to force “legacy” mode
- Enabled or Not Configured – Allows driver isolation, in which case the driver isolation modes can be set as needed (or as specified by the OEM)
-
Override Print Driver Execution Compatibility Setting Reported by Print Driver
– again, there are two settings
- Enabled - Forces drivers flagged as incompatible with PDI to run in “shared” mode
- Disabled or Not Configured – whatever isolation compatibility advertised in the .inf file for the driver is honored
The values for these policies are stored in the registry at HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Printers\ in the following values:
- PrintDriverIsolationExecutionPolicy
- PrintDriverIsolationOverrideCompat
A value of 0 = disabled, and 1 = enabled. If the policy settings are “Not Configured” then these values will not exist in the registry by default and the system assumes the default settings as discussed above.
To wrap up this post, we’ll take a look at some of the registry values that can be used to modify PDI behavior – specifically the lifetime and recycle behavior of PrintDriverIsolation.exe processes. These values exist in the HKLM\SYSTEM\CurrentControlSet\Control\Print\ key.
| Value Name | Type | Description |
| PrintDriverIsolationIdleTimeout | REG_DWORD | Time in milliseconds that specifies the maximum time a printer driver isolation process should remain idle before it is shut down. |
| PrintDriverIsolationTimeBeforeRecycle | REG_DWORD | Time in milliseconds that specifies the maximum time span a printer driver isolation process should be used for before it is shut down / restarted. The shut down and restart sequence reclaims memory potentially leaked by drivers |
| PrintDriverIsolationMaxobjsBeforeRecycle | REG_DWORD | Specifies the maximum number of operations a printer driver isolation process should be used for before it is shut / down and restarted. Again, the shut down and restart sequence reclaims memory potentially leaked by drivers |
In instances where you might suspect isolated drivers leaking memory or if you have a large number of PrintDriverIsolationHost.exe processes, these settings may be worth tweaking.
OK folks – that’s it for today. I’ll be back tomorrow with a look at PrintBRM. Until next time …
| Share this post : |
|
|
|
|
|
|
|
|