Print jobs stuck: error 0x00000040 and a print queue that will not clear

Fix it now

Microsoft publishes 0x00000040 as ERROR_NETNAME_DELETED, the specified network name is no longer available. On a print job it means the spooler lost the printer or the print server partway through and the job it was writing has nowhere to go. It then sits in the queue, marked Error or Deleting, because tidying it up also needs the destination.

Get-PrintJob -PrinterName "QueueName"
net stop spooler
net start spooler
Get-PSDrive C | Select-Object Used,Free

1. Try the polite route first: Remove-PrintJob -PrinterName "QueueName" -ID <id> for each job the first command lists.
2. If a job will not go, stop the spooler, delete every file inside C:\Windows\System32\spool\PRINTERS – the contents, not the folder – then start the spooler again.
3. Read the free space figure. A full drive produces exactly this behaviour and will do it again tomorrow, and on a print server it is the drive holding the spool folder that matters.
4. Print one small document to confirm the queue moves, then a large one to confirm it keeps moving.

On a shared print server, warn users before clearing the folder. Anything waiting will have to be sent again, and a truncated job is not recoverable in any case.

If the queue is empty and jobs are printing, you are done. If they stick again, the next section explains why a job can be stuck rather than simply failed.

Why it happens

The spooler writes each job to disk as a pair of files in the spool folder: the rendered data and a small descriptor holding the job’s state. It then feeds the data to the port. If the port disappears mid-job, because a network path dropped or the print server closed the session, the spooler is left holding a job whose destination no longer exists. It marks the job as errored and tries to release it, and the release path also needs the destination, so the job stays.

Disk space produces the same stall from the other direction. A job that cannot be written completely leaves a truncated spool file, and the spooler will not hand a truncated job to the port. On a print server with several large jobs in flight this hits the system drive first, because that is where the spool folder lives by default.

The three companions sit in the same small block of Windows errors and describe the neighbouring conditions precisely. 0x0000003F is ERROR_PRINT_CANCELLED, your file waiting to be printed was deleted – what a user sees when somebody else clears the queue underneath them. 0x0000003D is ERROR_PRINTQ_FULL, the printer queue is full. 0x0000003E is ERROR_NO_SPOOL_SPACE, space to store the file waiting to be printed is not available on the server, which names the server explicitly and is worth taking literally.

Full reference

The four codes and their published text

0x0000003E is the most specific of the four and the one people most often generalise. Microsoft’s wording puts the missing space on the server, so on a shared queue it is the print server’s spool drive you should be looking at, not the workstation’s. A user who is told to clear their own disk on the strength of it will find nothing and lose an hour.

Where the pieces live

Why Cancel does not work and stopping the service does

Cancelling a job asks the spooler to release it, and releasing it involves the destination that has gone away. Stopping the service breaks that dependency: the spooler is no longer holding anything, the files on disk are just files, and deleting them removes the job with nothing left to tidy up. That is the whole reason the stop-clear-start sequence works when the user interface does not, and it is why the sequence has to be done in that order.

Moving the spool folder on a print server

1. Create the destination folder on the data drive first.
2. Give the account the spooler runs as write access to it.
3. Set the new path in Print Server Properties on the server.
4. Restart the spooler.
5. Print a test page before you consider it done, and check that spool files are appearing in the new location rather than the old.

Do not script the stop-clear-start sequence as a scheduled job. As an emergency tool it is fine. As a routine it hides the real fault – a driver, a link or a disk – and it silently destroys the print jobs of anyone unlucky enough to be printing when it runs.

When jobs stick again the next day

• Check whether the same queue and the same driver are involved each time. A single driver is the most common cause of a recurring stall.
• Check the free space trend on the spool drive rather than its value right now.
• On laptops, check whether the disconnections line up with sleep, docking or moving between access points.
• Check whether the device itself is holding jobs for a release code, which looks identical from the workstation.
• Look at the PrintService Operational log as well as Admin. It records the jobs themselves and gives you the timing.

Every code this article covers

Confirm the fix worked

1. Open the queue and confirm it is empty, with no jobs left in an error or deleting state.
2. Print a multi-page document and watch the job enter and leave the queue.
3. Check free space on the spool drive after the test job, to confirm space is being released.
4. Confirm the Print Spooler service is still running an hour later rather than stopped again.
5. On a shared queue, have a second user print, so you know the fix was not local to one profile.

Questions people ask about this