NS_E_DATAPATH_NO_SINK (0XC00D1518): Fix the Print Spooler That Won't Write

I've seen 0XC00D1518 pop up on everything from a tiny HP LaserJet in a dentist's office to a Xerox WorkCentre running a whole print floor. The message reads like gibberish: NS_E_DATAPATH_NO_SINK — The data path does not have an associated data writer plug-in. Translated from Microsoft-ese: the print pipeline built a path to send your document somewhere, but the part that actually writes the bytes is missing or broken. No writer, no print. Simple as that.

This isn't a paper jam or a toner issue. It's software. The spooler service picks up your job, hands it to a data path, and the path has nowhere to dump the output. That happens after botched driver updates, a Windows update that half-installed, or a security tool locking the spool folder. One client last month had this kick in right after Kaspersky pushed a policy update — it was silently quarantining the print processor.

Work through these in order. Stop as soon as printing works.

The 30-Second Fix: Restart the Print Spooler

Nine times out of ten this is all it takes. The spooler service glitches out and loses track of its writer plugins. Restarting it re-initializes the whole pipeline.

1. Press Win + R, type services.msc, hit Enter.
2. Find Print Spooler in the list.
3. Right-click → Restart. If Restart is greyed out, hit Stop, wait five seconds, then Start.
4. Try printing again.

If you want to do it faster from PowerShell (which is how I usually fix this remotely while still on the phone with the client), run:

Restart-Service -Name Spooler -Force

That -Force flag matters. Without it, the service waits for stuck jobs to drain and sometimes just hangs. Force kills them.

If printing resumes, you're done. If it comes back a day later, jump to the 5-minute section — the underlying plugin is corrupt and the restart is just masking it.

The 5-Minute Fix: Clear the Queue and Re-Register the Writer DLL

When a restart doesn't stick, a corrupt print job is usually clogging the data path. The spooler tries to write output and the job itself is malformed, so the sink never gets created. Clear it out.

1. Stop the spooler: Stop-Service -Name Spooler -Force
2. Open C:\Windows\System32\spool\PRINTERS
3. Delete everything in that folder. Yes, everything. Those are pending jobs, not system files.
4. Start the spooler: Start-Service -Name Spooler

Then re-register the print writer plugin. This is the component that the error is literally complaining about:

regsvr32 /s "%systemroot%\system32\spool\drivers\w32x86\3\PrintConfig.dll"
regsvr32 /s "%systemroot%\system32\spool\drivers\x64\3\PrintConfig.dll"

Only one of those will succeed depending on your architecture — the other will error with a 0x80070005. That's fine, ignore it. You just want the correct one to register.

Real talk: if you're on a print server, do this on the server, not the workstation. I've wasted half an hour before realizing the actual sink was sitting on the print server three racks away.

Test print again. Still broken? Move on.

The 15-Minute Fix: Nuke the Driver and Check Permissions

At this point the driver itself is the problem. The print processor writes data into a temporary file, then the port monitor picks it up. If the driver's print processor DLL is corrupt, no sink gets created and you get 0XC00D1518 every single time.

Step 1: Remove the printer and its driver completely

1. Open Settings → Bluetooth & devices → Printers & scanners.
2. Select the broken printer, click Remove.
3. Open Print Management (printmanagement.msc).
4. Go to All Drivers, find the driver, right-click → Remove driver package. Tick "Delete driver package" when prompted.

If the driver is stubborn and won't delete, stop the spooler first, then delete the folder under C:\Windows\System32\spool\drivers\x64\3\ that matches the driver name, then start the spooler again.

Step 2: Fix spool folder permissions

This is the one nobody checks. The spooler runs as SYSTEM, and if a security tool (or a well-meaning admin) removed SYSTEM's write access to the spool folder, the sink can't create its destination file. You get 0XC00D1518 with no other symptoms.

1. Right-click C:\Windows\System32\spool\PRINTERS → Properties.
2. Security tab → Advanced.
3. Confirm SYSTEM has Full control and Administrators has Full control.
4. If not, add them. Disable inheritance first if the ACL is locked down.

Do the same for C:\Windows\System32\spool\drivers — the writer plugin DLLs live there and if SYSTEM can't read them, registration fails silently.

Step 3: Reinstall the driver fresh

Grab the current driver from the manufacturer's site. Not the CD. Not the one Windows Update offers — those are often three versions behind and full of the bugs you just removed. Install it, let it detect the printer, then print a Windows test page (not a document, a test page — it exercises the full pipeline).

Step 4: If it's still failing, check the WMS angle

NS_E_ prefix means Windows Media Services, and if you're hitting this while doing anything with streaming (WMS on Server 2012 R2 or 2016, or a media-heavy print workflow like medical imaging output), the sink plugin for WMS itself may be unregistered. Run:

regsvr32 /s wmsserver.dll
net stop wmserver
net start wmserver

That's a rarer cause, but I've seen it on three systems in the last two years, all in healthcare IT where print output feeds an imaging pipeline.

When to Just Replace the Printer

If you've cleared the spool, re-registered the print config, fixed permissions, and reinstalled a fresh driver, and it still throws 0XC00D1518, the printer's firmware or its embedded print controller is the culprit. Firmware updates fix this maybe 20% of the time. The rest of the time, you're looking at a hardware swap. I've told five clients in the past year to stop throwing hours at a $200 printer and just buy a new one — the labor cost exceeds the hardware cost by the second hour.

One more thing: if this is happening on a Remote Desktop or VDI setup, the redirected printer is the issue. Client-side printer redirection loses its sink plugin when the RDP session reconnects. Disable redirection for that printer in the RDP policy and map it from the server side instead.

That's the whole playbook. Spooler restart, spool clear, driver nuke, permissions. In that order. Usually you stop after step one.