Thousands of .spl and .shd files in C:\Windows\System32\Spool\Printers

[starmage21]

I've got a machine that tends to gather thousands of .shd and .spl files in the spool\printers directory and they remain there until the spooler system eventually locks the machine up. The number of these files appearing there quickly grows to a staggering hundreds of thousands over the course of a week if left untreated.

What I have noticed, is that when a Xerox 770 Print Server is uninstalled, the files stop building up there, and resume as soon as the driver is reinstalled.

Xerox support has nothing on this, and the other printers in that office using the same PCL6 driver for different Xerox machines also dont seem to be causing an issue.

Other machines in that office are using the same driver and arent having an issue at all.

The computer does not appear to be infected with a virus or other malware. I've scanned from safe mode with an up to date Malwarebytes, Symantec Endpoint Protection, and TDSSKiller.

Anyone else have a similar issue to this?

 

[das_stig]

For each print job there are two spool files generated by the Windows NT/2000 spooler. One file with the .SHD extension for job settings, and one with the .SPL extension for the drawing commands.

Using notepad ..

@echo off
net stop spooler
cd\
cd \windows\system32\spool\printers
del *.spl
del *.shd
net start spooler
exit

Save as a c:\windows\clrspool.cmd

Setup a task schedule that runs the cmd sometime in the early morning when nobody will be printing.

 

[starmage21]

This is a great workaround. Thank you.

I was hoping to get insight into the cause though, so that I can fix it without using a workaround.

 

[starmage21]

I was finally able to track this down. Turns out it was due to a RDP connection to a terminal server running a 3rd party terminal services called TS Plus (http://tsplus.net/) running on an XP machine. Apparently, with that software, whenever local-printer passthrough was enabled, it would create the .shd and .spl files. If local printer access was turned off, the issue evaporated.

Just to be sure, I connected the trouble machine to a standard terminal server that was running Server 2008 with Microsoft Terminal Services enabled. Not an issue at all.