Fixing a Crashing or Stuck Print Spooler Service

The Print Spooler service crashing repeatedly, refusing to start, or causing every print job to hang indefinitely is one of the most common and persistent Windows service problems, with several genuinely different underlying causes that all present through roughly the same symptom — knowing which one you’re actually dealing with determines the correct fix.

First: confirm the service’s actual current state

sc query spooler

This shows whether the service is stopped, running, or in a transitional state — worth confirming directly rather than assuming based on symptoms alone, since “printing doesn’t work” could mean the service crashed entirely, or that it’s running but stuck processing a specific problematic job.

Cause one: a corrupted or stuck print job

The single most common cause is a specific queued print job that the spooler can’t process correctly, and which the spooler keeps retrying (and failing on) repeatedly, sometimes crashing the entire service in the process rather than just failing that one job cleanly. Clearing the spooler’s job queue directly:

net stop spooler
del /Q /F "%systemroot%\System32\spool\PRINTERS\*.*"
net start spooler

This stops the service, forcibly deletes every currently queued print job file (there’s no way to selectively identify which specific job is the problem from the file names alone, so clearing all of them is the practical approach), and restarts the service fresh. This resolves the large majority of spooler crash reports, since a single bad job is overwhelmingly the most common cause.

Cause two: a corrupted or incompatible printer driver

If clearing the queue doesn’t resolve repeated crashes, a corrupted or incompatible printer driver is the next most common cause — particularly after a Windows update that changes driver-model requirements, or a printer manufacturer’s driver with a genuine bug. Checking Event Viewer for the specific crash details:

eventvwr.msc

navigating to Windows Logs > Application, filtering for Event ID 1000 (Application Error) or entries specifically naming spoolsv.exe as the faulting process, and noting which specific driver module is named as the faulting module — this identifies the actual responsible driver rather than requiring you to guess by uninstalling drivers one at a time.

Removing and reinstalling the identified problem driver

printui.exe /s /t2

This opens the Print Server Properties driver management dialog directly, where the specific driver identified from Event Viewer can be removed cleanly, followed by reinstalling the current version from the manufacturer directly (rather than whatever version Windows Update may have supplied), which is frequently a meaningfully different, more current build than what’s bundled with Windows itself.

Cause three: a known security patch conflict

Windows security updates addressing print-spooler-related vulnerabilities (a category of vulnerability that received considerable attention in recent years, given how much implicit trust the spooler service historically carried) have, on more than one occasion, introduced compatibility restrictions that specifically broke certain existing print configurations, especially printing to shared network printers hosted by another Windows machine. If spooler crashes started specifically and clearly coinciding with a recent Windows update, checking Microsoft’s own release notes and known-issues documentation for that specific update, rather than assuming a driver or job-queue problem, is worth doing directly — some of these were resolved by registry-level configuration changes Microsoft explicitly documented, rather than a driver fix on your end.

When the spooler service itself is disabled unexpectedly

Occasionally the underlying cause is simpler than any of the above: the Print Spooler service’s startup type has been set to Disabled (sometimes by a security hardening script or group policy applied without accounting for print functionality being needed):

sc config spooler start= auto
net start spooler

Confirming the service’s configured startup type before assuming a crash-related cause avoids unnecessarily chasing a driver or job-queue issue when the actual problem is simply that the service isn’t configured to run at all.

Why working through causes in this order makes sense

Clearing the job queue first is the correct starting point because it’s the fastest, least disruptive fix and resolves the most common cause outright — only escalating to driver reinstallation or checking for a known patch conflict if the simpler fix doesn’t resolve the issue avoids unnecessary driver reinstalls or registry changes for what’s very often simply one bad queued job.