Error 0x00000BC4: no printers were found when connecting by name or IP

Fix it now

Microsoft publishes 0x00000BC4 as ERROR_PRINTER_NOT_FOUND, no printers were found. It is a lookup failure rather than a permissions or driver failure: the share name you gave does not exist on that server, or the port the queue points at does not lead to a device. Ask the server what it actually publishes instead of guessing.

Get-Printer -ComputerName printsrv | Select-Object Name,ShareName,Shared
rundll32 printui.dll,PrintUIEntry /in /n "\\printsrv\ShareName"
Test-NetConnection 10.0.0.40 -Port 9100

1. Connect using the ShareName exactly as it comes back, including case and spaces. A queue has two names, the one the server administrator sees and the one clients must use, and renaming one does not rename the other.
2. If Shared comes back False, share it first: Set-Printer -Name "QueueName" -Shared $true -ShareName "queuename".
3. For a printer connected by address rather than through a server, print the device’s own configuration page from its front panel and read the address it reports.
4. Compare that with the port the queue is using, in the printer’s properties, Ports tab. If the address has changed, create a new standard TCP/IP port with the correct address, select it for the queue, and delete the dead one.

Give any printer a DHCP reservation or an address outside the scope. An address that moves is the single most common reason a queue that worked yesterday cannot find anything today.

If the queue connects and prints, you are done. If not, the next section separates the two different things this code is used for.

Why it happens

This code turns up in two situations that look identical to the user and are nothing alike underneath. In the first you are connecting to a queue published by a print server: the client asks the remote spooler for a queue by name and the spooler reports that no such queue exists. Names are the whole story, and the trap is that a queue has two of them – the printer name and the share name – which drift apart the moment somebody renames one.

In the second there is no server at all. The queue points at a standard TCP/IP port holding an address and a protocol, usually raw on port 9100 or LPR. If the device took a new address from DHCP, or was swapped for a different model at the same desk, the port now points at nothing. The spooler reports the same not-found condition even though the queue exists perfectly well on the local machine.

The companion codes tell the two apart, and one of them does not belong to this story at all. 0x00000704 is ERROR_UNKNOWN_PORT, the specified port is unknown, which is what you get after a port is deleted while a queue still refers to it. 0x0000052E is ERROR_LOGON_FAILURE, the user name or password is incorrect, so you never got far enough to enumerate anything. 0x000006BB is RPC_S_SERVER_TOO_BUSY, the RPC server is too busy to complete this operation, which is genuinely transient.

0x00000BCC is the odd one out and it is worth knowing why, because it is often listed alongside these. It is ERROR_PRINT_JOB_RESTART_REQUIRED: the requested print job has failed to print, and a print system update requires the job to be resubmitted. That is about a job, not about finding a queue. If you see it, resubmit the document; do not go round the share-name loop again.

Full reference

Five codes, and Microsoft’s wording for each

Note that 0x00000BC4’s published wording is plural and general: no printers were found. It is not a statement that one specific queue is missing, which is why it turns up both when you name a queue that does not exist and when an enumeration comes back empty. Both are answered the same way – ask the server what it publishes.

A queue’s two names

Nearly every server-side instance of this code is one of those four being different from what somebody assumed. Reading all four in a single Get-Printer line is faster than any amount of browsing, and it gives you something to paste into a ticket.

Direct connections and where they go wrong

• A standard TCP/IP port holds an address and a protocol. Raw on port 9100 is the usual pairing; LPR needs a queue name the device recognises.
• Test-NetConnection <address> -Port 9100 tells you whether anything is listening. A failure there is a device or network problem, not a spooler one.
• A device that answers on its web interface but not on 9100 usually has raw printing disabled in its own settings.
• Two queues pointing at the same port is fine. Two devices sharing one address is not, and it produces intermittent not-found behaviour that looks like a spooler fault.
• Where the port was created by a vendor installer rather than by Windows, it may be a vendor port monitor rather than a standard TCP/IP port, and it will not behave like one.

Stale connections in the user’s profile

A connection to a server queue is stored per user. That is why removing and re-adding a printer fixes one person and leaves everyone else broken, and why a queue can come back after you thought you had deleted it. Remove the connection with Remove-Printer -Name "\\printsrv\oldqueue", log off and back on so the profile’s connections are rebuilt, and check whether Group Policy Preferences or a logon script is recreating it before you conclude anything.

When the name and the port are both right

1. Confirm the client is talking to the server you think it is, using the fully qualified name.
2. Check for a duplicate DNS record pointing that name at a decommissioned server.
3. Confirm the spooler is running on the server, since a stopped spooler produces a different code but the same user experience.
4. Try Get-Printer -ComputerName printsrv from the client, which exercises the same path and returns a cleaner error.
5. Test from a second client. One client failing is a profile or credential story; every client failing is a server story.

Every code this article covers

Confirm the fix worked

1. Run Get-Printer on the client and confirm the queue is present with the expected port or server path.
2. Print a test page and confirm it emerges from the intended device rather than a neighbouring one.
3. For a direct connection, run Test-NetConnection <address> -Port 9100 and confirm it succeeds.
4. Confirm the device holds a reserved or static address, so the port cannot go stale again.
5. Log off and back on, then confirm the printer is still there and still the default if it should be.

Questions people ask about this