0X00000707

Fix ERROR_INVALID_SEPARATOR_FILE 0X00000707 On Print Server

Windows Errors Intermediate 👁 0 views 📅 May 27, 2026

This error means Windows can't find or read the separator file used to print separator pages. Here's how to fix it fast.

I know this error is infuriating — especially when you're trying to push a batch of print jobs through a server and suddenly everything grinds to a halt. I've seen 0X00000707 pop up most often on Windows Server 2019 and 2022 when someone changes the default separator file path, or when a group policy pushes a custom separator file that doesn't actually exist.

The Quick Fix

Open an elevated Command Prompt (right-click CMD, Run as Administrator) and run this:

net stop spooler
del /F /Q C:\Windows\System32\spool\PRINTERS\*.*
net start spooler

Then reset the separator file to the default:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Print" /v "SeparatorFile" /t REG_SZ /d "C:\Windows\System32\PSEP000.COM" /f

Restart the Print Spooler service one more time (or reboot the server) and test your print job. Nine times out of ten, that kills the error.

Why This Works

Windows uses a separator file (usually PSEP000.COM or SYSPRINT.SEP) to insert a separator page between print jobs. The error 0X00000707 means the system tried to read a separator file that doesn't exist, is in the wrong location, or is corrupted. Deleting the stuck print jobs clears any job that's hanging on the bad separator. Then we force the registry to point back to the known-good default file.

The default separator file PSEP000.COM ships with Windows and lives in C:\Windows\System32\. It's a tiny binary, and it's always there unless someone explicitly deleted it. If you've got a custom separator file, the registry key will point to that path instead. The fix above overwrites it regardless.

When the Default Fix Isn't Enough

Sometimes the error persists even after resetting the registry. Here's what to check next:

1. Check If the Default Separator File Actually Exists

Open File Explorer and go to C:\Windows\System32\ and look for PSEP000.COM. If it's missing, you can copy it from a working machine (same Windows version) or extract it from the Windows installation media. But honestly — if it's gone, someone ran a cleanup script that deleted system files. That's a bigger problem.

2. Group Policy Override

On a domain-joined print server, a Group Policy Object might be setting the separator file path. Run gpresult /H gp_report.html and check the Print Policies section. If you see a separator file path there, you'll need to update the GPO or create a local policy override.

3. Corrupted Print Processor

Less common, but I've seen it. The print processor (usually winprint.dll) can get corrupted and throw 0X00000707 even when the separator file is fine. Run sfc /scannow from an elevated prompt to check system file integrity. If it finds corruption, reboot and test again.

Prevention: Keep Your Separator Setup Clean

If you use custom separator files (like ones that print accounting codes or department names), store them in a dedicated folder — C:\PrintSeparators\ — and make sure backups exist. Never use a path that can be deleted by a scheduled cleanup script. Also, avoid mapping network drives to separator file locations; if the network drops, you get this error immediately.

For most environments, the default PSEP000.COM separator is fine. It prints a basic page with the document name, user, and date. If you need custom separators, test them on a non-production print server first.

One more thing: if you're running a high-volume print server, consider disabling separator pages entirely. They add overhead and generate extra paper waste. You can set the separator file to an empty string in the registry (just delete the SeparatorFile value) — but test that in your environment first. Some ancient printers or drivers choke on missing separators.

That's the whole fix. It's straightforward once you know where Windows is looking. If you're still stuck after all this, check the Event Viewer for Print Service logs — they'll usually point to the exact job or printer that triggered the error.

Was this solution helpful?