Print Spooler Stuck: Clearing Hundreds of Jammed Print Jobs

LIMEHAWK - Managed IT

Home>Incident Reports>Print Spooler Stuck: Clearing Hundreds of Jammed Print Jobs

Jobs cleared

847

Incident

April 14th. Twelve-person accounting firm calls — nobody in the office can print. Tax deadline is the next day. The call came in after they'd already been "trying things" for two days: cancelling jobs, rebooting machines, reinstalling drivers. The print queue on one workstation showed 847 jobs stuck in "Deleting - Sent to printer." None of them were going anywhere. Every time someone hit Cancel All, the queue got a little worse.

What we found

Remote session on the worst-affected workstation showed the Print Spooler service sitting in "StopPending" and had been for the last 6+ hours. The spool directory was full:

- service state: "Stopping" / StopPending for 6+ hours
- spool directory: 847 .SPL and .SHD files (2.3 GB)
- file handles: still locked by spoolsv.exe
- root cause: network printer went offline mid-job two days earlier

One corrupted job from the original printer outage had cascaded. Every print attempt after that queued behind the stuck job. Every cancel attempt added more delete requests to an already-deadlocked queue. Classic spooler deadlock.

Why their attempts failed

Everything they tried is correct in theory. None of it works once you're in this state:

- "Cancel All Documents" — adds more delete requests to a queue that already can't process anything
- restart Print Spooler service from services.msc — the UI waits for graceful stop, which never comes
- delete spool files by hand — the files are locked by spoolsv.exe, Explorer refuses
- reboot the whole machine — worked for about an hour before the orphaned jobs re-queued on the next boot and jammed the whole thing again

Windows won't forcefully kill a service from the GUI. You can't delete files the service has locked. And rebooting just reloads the corrupted queue off disk. You have to force-stop the process and wipe the spool directory between stop and start.

Initial diagnostics

Confirmed the state quickly:

Get-Service -Name Spooler | Select Status, StartType

Status: StopPending, StartType: Automatic. Then:

Get-ChildItem "$env:SystemRoot\System32\spool\PRINTERS" | Measure-Object -Property Length -Sum

Count: 847, Sum: 2,415,632,384 bytes. Not subtle.

Resolution

Deployed this script via RMM. It force-stops the spooler (even from StopPending), waits for Windows to release file handles, clears the spool directory with retry logic for any locks that take a beat longer, and starts the service clean:

Why this works

- Stop-Service -Force sends a termination signal that bypasses the graceful-shutdown wait. A service stuck in "Stopping" will actually terminate.
- the 2-second wait after stopping gives Windows time to release file handles. Without it, the first delete attempts fail about 30% of the time and you spend your time debugging a race condition instead of fixing the problem.
- retry logic with 500 ms delays catches the remaining stragglers — three attempts with backoff handles 99%+ of timing issues.
- starting the service with an empty spool directory means no orphaned jobs come back from the dead on the next boot.

Outcome

Script ran in about 8 seconds. All 847 stuck jobs gone. Printing resumed immediately — tax returns started coming out of the printer within a minute of the call. Tax deadline was met.

- time to resolution: under 2 minutes from call to first page printing
- jobs cleared: 847
- space recovered: 2.3 GB on C:
- deadline: met, all returns filed on time

Prevention, because we don't want this call again:

- scheduled weekly queue cleanup across all 12 workstations
- self-service "Fix Printer" button in the RMM tray app so users can trigger the same script themselves
- zero print-related tickets from this client in the 8 months since

Key takeaways

Takeaway

the Windows Print Spooler is fragile — one network hiccup cascades into everyone being offline.

Takeaway

Stop-Service -Force works when graceful stops won't, and timing + retry logic is what makes it reliable.

Takeaway

self-service beats a ticket queue — users don't want to wait on hold, we don't want to spend 30 support minutes on a 30-second fix.

Takeaway

prevention beats reaction — weekly scheduled cleanups mean the queue never gets to critical mass in the first place.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)