Fix 0x0000076E: Invalid Form Name on Print

Windows throws this when a form name in a print job doesn't match printer's paper sizes. Fix by cleaning stuck spooler, resetting form definitions, or editing registry.

Quick answer

Stop the spooler, delete FORMS registry key, restart spooler — then any stale form names vanish. If that doesn't work, you'll need to edit the driver's form list manually. Full details below.

Why this happens

Windows's print system maps a human-readable form name like "Letter" or "A4" to a numeric structure in the FORMS registry value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Forms. When an application submits a print job, it passes a FORM_INFO_1 structure with a name string. The spooler checks that name against what's registered. If the name isn't there — typo, deleted form, or a driver that registers forms on a per-driver basis but the spooler cache didn't update — you get ERROR_INVALID_FORM_NAME (0x0000076E).

The most common trigger is a printer driver that added a custom paper size (say, "Invoice" or "Labels 4x6") and then got updated or removed incompletely. The spooler still remembers the old form ID in its cache, but the form name doesn't exist anymore. Or you've got two drivers on the same port, one referencing a form the other never registered. Either way, the spooler can't find the form name and bails with that error.

Fix steps (try in order)

Clear the spooler cache and restart. Open an elevated command prompt (Win+X → Command Prompt (Admin)).
```
net stop spooler
rd /s /q C:\Windows\System32\spool\PRINTERS
net start spooler
```
This wipes any queued jobs that might reference dead forms. Doesn't touch the registry, so you'll still need step 2 if the problem persists.
Reset the form registry key. Still in that admin prompt:
```
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Print\Forms" /f
net stop spooler
net start spooler
```
What's happening here is you're forcing Windows to rebuild the form list from scratch. On next spooler start, it re-enumerates driver-supported forms from each printer driver's INF or from the built-in defaults. This is the most reliable fix I've found — it kills any orphaned form names that the driver stopped supporting but the registry still held onto.
Check the printer's default form. If the error still shows, open control printers (Win+R), right-click your printer → Printer preferences → Paper/Quality tab. Set the default paper size to a standard one like Letter or A4. Sometimes the driver's stored default points to a form that no longer exists after the reset.
Update or reinstall the driver. Go to the printer manufacturer's site and fetch the latest driver. Run the installer with "Remove" first, then reinstall. That clears any per-driver form definitions that live in the driver's own configuration (stored in the driver-specific registry area under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\YourPrinter\). The reset in step 2 only clears the global FORMS list, not driver-specific ones.

If the main steps fail

Some drivers — I'm looking at you, older HP and Brother models — re-register their custom forms on every spooler start, but they do it through a user-mode helper that runs only on a logon. If you're testing from a service or a scheduled task that runs under a different account, it never sees those forms. Workaround: log into the console session and print once from Notepad. That often triggers the helper.

Another scenario: you're using a point-and-print client. The server's form list is fine, but the client's copy is stale. On the client, run printui /s /t2 to open the printer server properties, go to Forms tab, and check whether the needed form exists. If not, add it manually with the exact dimensions. Then the client can send jobs.

Registry manual edit as a last resort: export the Forms key before deleting it (so you can restore). Then modify the Forms value — it's binary, not a string, so don't try to hand-edit. Instead, use PowerShell to add a form:

Add-Type -AssemblyName System.Printing
$server = New-Object System.Printing.PrintServer(@("\\localhost"))
$form = New-Object System.Printing.PrintFormSize
$form.Name = "MyCustom"
$form.Width = 850
$form.Height = 1100
$server.Forms.Add($form)
$server.Commit()

Width and height are in thousandths of an inch. So Letter is 850x1100, A4 is 827x1169. That's the programmatic path the spooler uses internally.

Prevention

The #1 cause is driver updates that don't cleanly remove old custom forms. Before updating a printer driver, delete the printer and its driver from Devices and Printers (right-click → Remove device, then Print Server Properties → Drivers → Remove). That forces Windows to drop every trace of the driver's form definitions. Then install the new version fresh.

Second, if you're an admin managing shared printers, standardize on the built-in paper sizes. Users love adding "Custom 4x6" for label printers, but that's exactly what breaks after a driver change. Push standard sizes via Group Policy if you can.

Third, keep an eye on the spooler service. A spooler that crashes mid-job can corrupt the form cache. Set up a scheduled task that restarts the spooler weekly — it's cheap insurance. I've seen this error go away permanently after just that.

Note: The error code shows as 0x0000076E but the decimal is 1902. Some logs show it as 1902. Same thing.

If none of these help, you're likely dealing with a driver that has a fundamental bug in how it declares forms. Switch to a generic PostScript driver (from Microsoft Update catalog) or use the built-in "Microsoft Print to PDF" to isolate whether the driver is the problem. If PDF works, it's 100% the driver. Time to call the manufacturer.