When testing Citrix Universal Print Server, we in the test team look deeply at how well the product is working when we perform printing load testing on the overall environment when real third-party printer drivers are installed and stressed at scale. One of the things that we’ve found on the print server running Citrix UPS are crashed PrintIsolationHost and spoolsv processes.

So why does this happen?

Where are these crashes occurring? For starters, we here at Citrix always try to narrow it down and find the root cause of the problem. So when we run various stack traces on the PrintIsolationHost or spoolsv processes on a print server with Citrix UPS  installed, the root cause is invariably caused by a third-party manufacturer driver on the server crashing either process. But depending on the driver the administrator is using on the print servers, it could be crashing a different process, so what gives? Enter print driver isolation.

What is print driver isolation?

Printer drivers are notorious for having these types of issues and their quality can vary greatly, and Microsoft introduced this mechanism to help identify and mitigate against these issues. Essentially, it’s a mechanism Microsoft  introduced that allows print drivers to be run within separate run spaces.

Print driver isolation can be configured in 3 different configurations, all of which are set at the driver level and can be set within the “Print Management” console on the “Drivers” section. The first mode is “Shared”, this creates one PrintIsolationHost process that is shared with any other driver which uses this mode. The second is “None”, whereupon the printer driver set in this mode shares the run space with spoolsv. Finally, “Isolated” creates a separate PrintIsolationHost for each active printer driver performing any printing activity.

To illustrate my point, here is what happens in scenarios with a problematic print driver in all three modes.  If a print driver was erratic with “None” printer isolation mode, spoolsv.exe would crash. This is a huge hindrance with people who wish to use the print server and have it in its most stable and scalable condition. When spoolsv is crashed, no further printing activity can continue unless the spooler is restarted on the print server.

The default “Shared” mode allows for printing activity to continue, spoolsv is not a crashed process but instead, a separate PrintIsolationHost process is open with all printer related driver activity happening within this run space. But of course, if a problematic print driver were to make PrintIsolationHost crash, any subsequent print jobs which operate with the “Shared” mode would be rendered useless, as they’re waiting for a restart or cleanup of the PrintIsolationHost process.

The final “Isolated” mode creates a separate run space for each of the print drivers. This gives an environment a resilient print server by crashing individual PrintIsolationHost processes, allowing working drivers to continue their printing within their own run spaces. The caveat of this however is each PrintIsolationHost consumes a memory footprint that could potentially increase memory usage on the print server. This can result in possible low memory conditions that would undoubtedly occur if the number of drivers being managed on the print server were to be continuously increasing.

When we test UPS in large scale printing environments, we find print isolation host “Isolated” mode is extremely useful to narrow down which drivers were problematic to use and therefore can exclude certain drivers from our testing so that we can produce base product results based on our environment at scale. Once there is an established set of drivers in use, a “Shared” model for all print drivers is additionally adopted in order to emulate customer environments while maintaining a stability in the spoolsv process.

If your print server with Citrix Universal Print Server is experiencing constant PrintIsolationHost and spoolsv crashes I recommend reading these articles to learn in greater detail how to configure Print Driver Isolation and some specific recommendations.

Final thought – Contact your driver manufacturer if you identify driver faults!

Printer driver isolation is fundamentally mitigation and a useful tool to identify driver issues. Ideally you would not use it in production (especially “isolated” mode. When we identify faulty drivers we contact the manufacture to alert them to the issues. Often there are fixes or replacement drivers available from the manufacturer.