Printer Appears in RDP Session but Print Jobs Disappear Fix
The printer is there in the session, the job leaves the application, the queue blinks - and the printer stays silent. A redirected print job crosses two computers and two spoolers, and it can die at any of the handovers. Here is how to find the exact one.
🎥 Watch the full video - every step shown live on screen
A vanishing job is not one problem, it is four possible problems wearing the same coat. The job must be rendered on the server, pushed through the RDP connection, accepted by the Print Spooler on your client PC, and finally printed by your real driver. Most people restart random services and learn nothing. Instead, watch the job at each stage - where it stops tells you where the fault is.
Print queue inside the session (example)
HP LaserJet (redirected 2) - Queue
------------------------------------------------
Document Status Pages
Invoice_2041.pdf Error - Printing 3
Report.docx Spooling 1
The job reaches the queue, shows an error,
and is gone after a few seconds.
👆 A job that errors in the server queue never even starts its journey to your printer
1
Watch the Job in Both Queues
Print one small test job and watch both ends at the same time:
Inside the session, open the redirected printer's queue - does the job appear, sit in Spooling, show Error, or pass through?
On your client PC, open the real printer's queue - does anything arrive there?
Job errors in the server queue: the fault is server-side rendering or the driver route. Job leaves the server but never lands on the client: the fault is the client spooler or the local driver. Job prints from the client queue but the paper is blank or garbage: the local driver is the problem, not RDP
2
Restart the Right Spooler - on Both Machines
The Print Spooler is the service that carries every job, and a crashed spooler swallows jobs silently.
On the machine where the job stopped, open services.msc
Find Print Spooler and choose Restart. If it was stopped, start it - and ask why it stopped
Repeat on the other machine; a healthy server spooler cannot deliver to a dead client spooler
A spooler that keeps stopping is almost always being crashed by a bad printer driver. Note the time of the crash - the Event Viewer entries in the next step will name the driver.
3
Read the PrintService Event Logs
Windows logs print failures in detail; most people never look.
On the server, open Event Viewer > Applications and Services Logs > Microsoft > Windows > PrintService > Admin
Match an entry to the time your job vanished - errors here name the failing driver or document
Repeat on the client PC in the same log
For diagnosis only, open the printer's Printer properties > Advanced and tick Keep printed documents - jobs now stay in the queue after printing so you can see exactly where they stop. Untick it afterwards; nobody needs a permanent copy of everything printed
4
Test with Notepad to Separate App from Printer
Print one line from Notepad inside the session. If Notepad prints and your application does not, the printer path is healthy and the application is failing - most often a heavy PDF being rendered by the app itself, or an app that cached yesterday's printer name with a different session number. If even Notepad fails, stay on the spooler and driver path above. This two-minute test prevents the classic mistake of reinstalling a whole accounting package for a spooler fault.
5
The Easy Print Test and the Driver Reality
By default, redirected printers use the Remote Desktop Easy Print driver. If jobs die only for one printer model, force the issue the other way: if your server has the printer's real driver installed for testing, you can tell the server to prefer exact driver matching by disabling the policy Use Remote Desktop Easy Print printer driver first - if jobs now print, Easy Print's rendering was the failure point for that model. This is a diagnostic step, not a casual change: installing third-party drivers on a shared server is the number one cause of spooler crashes for every other user, so do it as a controlled test, as the driver-matching guide in this series explains. And when a printer model simply will not survive either route, that is the honest use case for TSPrint from the video - it bypasses server-side drivers altogether.
📌 Golden rule: never change two things at once on this path. Restart one spooler, run one test print, read one log entry. The stage where the job stops moving is the stage that is broken - everything else is guesswork.
🎥 See It Done Live in the Video
The video shows TSPrint rescuing exactly this kind of setup - watch it if your jobs keep dying between the server and the desk.
The job prints hours later, all at once. What happened?
The client spooler or the printer was stuck - often the printer was offline, asleep or out of paper - and the queue flushed when it recovered. Check the client queue and the printer's own status before blaming the server.
Only PDF jobs disappear. Normal documents print fine. Why?
PDFs are rendered into very large print data. A fragile driver or a weak connection can choke on them while small text documents pass. Test the same PDF printed locally on the client; if it fails there too, it was never an RDP problem.
The printer shows Offline inside the session. How do I clear it?
That status is mirrored from the client. If the printer is offline, paused or erroring on your own PC, the session shows the same. Fix it locally, then disconnect and reconnect the session to refresh the redirected copy.
This guide is based on the Technical Anshu video linked above • Stuck on a step? Ask in the video comments - you will get an answer 🙏