Troubleshooting

The port is in use, but PortWho shows nothing

portwho 8080 printed No endpoints matched. and exited with code 1, yet something refuses to bind. Check these in order.

It is a connection, not a listener. PortWho enumerates listening TCP sockets and bound UDP sockets only. A port that is busy because of an established or closing outbound connection is out of scope for “who owns this port” and does not appear. Get-NetTCPConnection -LocalPort 8080 or netstat -ano show connection states as well; a row in state Established or TimeWait explains the conflict.

The port is reserved by Windows. Hyper-V and WSL reserve ranges of ports that no process owns, so there is nothing for PortWho to list. The current command line does not yet explain these ranges; that is a known limitation. You can inspect them manually:

netsh interface ipv4 show excludedportrange protocol=tcp

A filter excluded it. --tcp, --udp, -4, -6 and --pid are applied before anything is inspected, and --search only matches process name, executable path, service names and the signer. Run portwho <port> with no other options to see every endpoint on that port.

Elevation. PortWho never asks for elevation and lists endpoints as a normal user. If an endpoint is listed but its owner shows (access denied), see the next section.

Rows marked (access denied)

Windows refused to open the owning process with even the limited query right. The note in the details view and the detail field in JSON read: “Windows denied access to the process; it is protected or runs with higher privileges.” The name next to the label comes from the system process list, which Windows exposes without a handle, so you usually still know which process it is. What you lose is the executable path, and with it the signature check, which is reported as - in the table and not checked in details (notChecked in JSON). Running PortWho from an elevated prompt can allow Windows to open processes it refused before.

Rows marked (exited)

The process ended between the moment PortWho took the endpoint snapshot and the moment it looked the process up. This is normal for short-lived processes. Run PortWho again; if the row is gone, the port is free.

Rows marked (lookup failed)

The process could be found but not inspected, for a reason other than access denied. The Windows error text is in the details view’s Note line and in the JSON process.detail field.

Signature unavailable

No verdict was possible because the file could not be read: the executable could not be opened or hashed, the catalog database could not be opened, or Windows reported a file-level error such as not found, access denied or a sharing violation. The reason follows the colon in the details view (unavailable: <reason>) and is in signature.detail in JSON. An unavailable file is neither trusted nor distrusted; it is unverified.

Signature INVALID

A signature or a catalog entry exists, but verification failed: the file’s digest does not match, the certificate chain is not trusted, the certificate expired, and so on. PortWho shows the signer the file claims and the Windows error with its code, for example INVALID (claims Example Corp): <reason> (0x80096010).

Before concluding that a file was tampered with, keep two things in mind:

• Verification is offline. Revocation is not checked, and the chain is built from certificates already cached on the machine. A chain that would need a download to complete can fail here and be reported as INVALID with the corresponding Windows error.
• For a catalog-signed file, the signer shown is the catalog’s signer.

INVALID is a reason to look closer at the file, not a verdict about the program’s behavior.

The signer is not what you expected

The table shows the organization on the certificate when there is one, with (catalog) appended for catalog-signed files; the details view shows Signer (Organization) when both are known and differ. --search matches the signer’s common name, not the organization. With --no-signature, no signer is known at all, so a search for a publisher name matches nothing through that field.

Services are missing and a warning appeared

portwho: warning: service names are unavailable: <Windows error text>

The service control manager could not be queried. PortWho continues with empty service lists and the normal exit code, so svchost.exe rows are not explained in that run.

Slow runs

Most of the time goes into Authenticode verification, which runs once per distinct executable path. Two remedies:

• --no-signature (or --no-signatures) skips verification entirely; the signature column shows - and JSON reports notChecked.
• Narrow the query. A port, --pid, --tcp/--udp and -4/-6 are applied before any process is inspected, so portwho 8080 only inspects the owners of port 8080.

Ctrl+C cancels a run; PortWho prints portwho: cancelled. and exits with code 3.

Running on something other than Windows

PortWho inspects Windows network endpoints and only runs on Windows. Elsewhere it prints portwho: PortWho inspects Windows network endpoints and only runs on Windows. to standard error and exits with code 3. The platform-neutral parts of the solution build and their unit tests pass on other operating systems, which is useful for development but proves nothing about a Windows run.

Non-interactive use

• Listings and JSON go to standard output; errors and the services warning go to standard error.
• Exit codes: 0 listed something, 1 nothing matched, 2 invalid command line, 3 enumeration failed, cancelled, or not Windows. --help and --version exit with 0.
• --json writes a document even when nothing matched ("endpointCount": 0); use the exit code to tell the two cases apart. Scripts should read JSON, not the table, whose columns are truncated. See JSON output.

Known limitations

• TCP enumeration covers listening sockets only; established connections are out of scope.
• Hyper-V and WSL reserved port ranges are not listed; see Port in use but no process is listed for how to check them by hand.
• The signer shown for a catalog-signed file is the catalog’s signer.
• Signature verification is offline, so revocation is not detected.
• The WPF desktop application is implemented but not released; like the command line, it has to be built from source for now.

Still stuck? The support page lists the current channels; include the exact command, the output and your Windows version.