# Windows Print Queue

Use this when the thing you want to test is what a **driver** emits, or when your application prints
through the Windows spooler rather than opening a socket itself. If your code builds ESC/POS bytes and
writes them to a socket, skip this page - a queue would only get in the way.

## Adding the printer

1. **Settings -> Bluetooth & devices -> Printers & scanners -> Add device**, then
   *Add manually* when the search finds nothing.
2. Choose **Add a printer using an IP address or hostname**.
3. Device type: **TCP/IP Device**. Hostname: `virtual-printer.online`. Port: your printer's port.
   Clear *Query the printer and select the driver to use automatically* - there is no SNMP here to
   answer.
4. When Windows asks for the port type, choose **Custom -> Settings** and confirm the protocol is
   **Raw** with the port number you entered. This is the step that matters: Raw is what sends the byte
   stream unaltered.
5. Pick a driver:
   - **Generic / Text Only** passes text through with almost no additions - the closest thing to
     printing the bytes yourself.
   - **Your printer vendor's driver** is the right choice when you want to see exactly what it emits,
     which is usually the reason to set up a queue at all.

## What you will see

Windows drivers are chatty. Expect initialisation sequences, code-page selection and status polls
around your content on every job, and expect some of it to be ignored by the emulator - that is normal
and documented in [Supported ESC/POS commands](/docs/protocols/escpos/supported-commands).

If the queue reports an error, the connection was probably reset by the
[IP whitelist](/#settings/whitelist) rather than refused; the
[Access Log](/#settings/connections) tells you which.

## Checking the port without a queue

```powershell
Test-NetConnection virtual-printer.online -Port 9411
```

A failure here means the queue was never going to work, and the problem is the address or the network.