The Print Spooler service (spoolsv.exe) in Windows is a very simplistic process with an important job, yet due to its nature can often encounter exceptions and be terminated… through no fault of its own, most commonly.
As with every other service in Windows, it is started and stopped through the Service Control Manager (SCM) – and the first 2 times it crashes it will be automatically restarted after 60 seconds by default:
The spooler itself is just an engine – it performs routine jobs in a standard manner but the actual code that renders print jobs is 3rd party; the manufacturer of the printer provides 1 or more DLLs that are loaded into the process.
An exception in any thread in a process that goes unhandled will cause Windows to terminate the entire process – so if any of the printer DLLs hiccups then the Print Spooler will go down… taking all printers with it.
In addition to the printer drivers essential to be able to send jobs to the devices, often there are print processors, providers and monitors that are provided by the manufacturers too, that are supposed to add extra or alternative functionality for communication with the devices.
As per KB260142, the only in-box (and hence supported by Microsoft as part of Windows) print monitors, providers and processors are:
AppleTalk Printing Devices
BJ Language Monitor
PJL Language Monitor
Standard TCP/IP Port
Windows NT Fax Monitor
Internet Print Provider
LanMan Print Services
If you experience a frequently crashing spooler issue, the best place to start would be to follow the steps in KB260142 which describe how to remove all 3rd party print monitors, providers and processors and then ensure every printer is set to use WinPrint as its print processor.
If your spooler becomes stable then you know it was one of those components causing the problem – if the problem continues then it will likely be one of the 3rd party printer drivers causing the problem – check the drivers you have installed for their age, and update if possible.
You can browse all installed printers through the registry under this key:
As with any other device, the manufacturer has to be the one to determine how the operating system uses it and what its capabilities are – hence the need for 3rd party code being loaded inside our process.
If the driver provided by a manufacturer is causing problems, then often a “compatible” in-box driver can be used in its place, with little or no loss in functionality – it is unlikely that there is a performance difference between driver versions, just capability and/or stability differences.
Sometimes the references to the 3rd party print monitors, providers or processors can sneak their way back into the registry (most often through reinstallation of the driver package or creation of a similar printer) – it might be wise to look in the relevant location under the HKLM\System\CurrentControlSet\Control\Print key and identify the filename of the non-inbox DLL and rename that file on disk – they should reside somewhere under %systemroot%\system32\spool.
Before making any changes to the registry or renaming/deleting files on disk, always make a backup of the data or system beforehand, and record the details of the changes made, so you can quickly revert if a mistake is made.
As a specific point-in-case, take a look at KB947477 which describes a commonly-encountered issue caused by a 3rd party print driver package, and how to go about removing it, or references to it.
Also check for TMP or BUD files under the spool folder on disk when the spooler service has been gracefully stopped – if you have a large collection of these then delete them.
A common cause for these getting left behind is real-time anti-virus scanning – it is wise to exclude the %systemroot%\system32\spool folder from AV scanning (at least real-time, and just leave system scans to keep it covered).
AV filter drivers can sometimes cause short-lived temporary files (such as print jobs being rendered) to remain undeleted and fill the disk with junk over time.