When netstat says port 80 or 443 is owned by PID 4, the listener is the Windows HTTP stack, HTTP.sys, which runs in the kernel and holds the port on behalf of IIS or another program that registered a URL with it. You do not kill PID 4. You find which service registered the URL and stop or reconfigure that service. Port Detective shows the System owner, flags it as a protected OS process, and lets you copy the matching netstat and PowerShell commands so you can trace it in seconds.
This is one of the most confusing port conflicts on Windows, because every normal answer (“find the PID, end the process”) points at something you must never end.
See which ports belong to System and which belong to apps you can actually stop.
Get it from Microsoft
Why does netstat say port 80 belongs to PID 4?
Run this in a terminal and you will often see it:
netstat -ano | findstr :80
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
Open Task Manager, go to the Details tab, and PID 4 is listed as System. That is not a bug and it is not malware hiding behind a system name. It is how the HTTP Server API works.
Microsoft documents the HTTP Server API as a way for multiple applications “to coexist on a system, sharing the same TCP port (for example, port 80 for HTTP or port 443 for HTTPS) and serving different parts of the URL namespace.” To make that sharing possible, the socket is not owned by any one app. It is owned by the HTTP listener, which Microsoft’s IIS architecture guide describes as “a kernel-mode device driver called the HTTP stack (HTTP.sys).” Because the listener lives in the kernel rather than in an app, netstat reports the owner as System, PID 4.
The apps behind it register URL prefixes such as http://+:80/ or https://+:443/myapp/. HTTP.sys receives each request and hands it to the right registered process.
What usually registers port 80 or 443 with HTTP.sys?
The list depends on what is installed. These are the documented, common cases:
| Owner | How to recognize it | What to do |
|---|---|---|
| IIS (World Wide Web Publishing Service) | Default Web Site bound to port 80 or 443 in IIS Manager | Stop the site or the service, or change its binding |
| Any app built on the HTTP Server API | A URL registration or request queue appears in netsh output | Stop that app or change the URL it registers |
| WinRM 1.1 or earlier | Microsoft’s port reference lists WinRM 1.1 and earlier on 80 and 443; WinRM 2.0 uses 5985 and 5986 | Check WinRM configuration; modern systems should not use 80 |
| A reserved URL with no running app | A URL ACL reservation exists but nothing is serving it | Review the reservation and remove it if nothing needs it |
Microsoft’s service overview and network port requirements is the source for the WinRM port history above. IIS is the case most developers hit: it was turned on years ago for a course or a test, and it still starts with Windows.
How do I find the real owner behind PID 4?
Use these steps in order. Each one narrows it down.
- Confirm the listener. Run
netstat -ano | findstr :80(or:443). If the last column is 4, it is HTTP.sys. - Ask HTTP.sys what is registered. In an elevated terminal, run
netsh http show servicestate view=requestq. Microsoft documents show servicestate as a snapshot of the HTTP service, viewed by server session or by request queue. The request queue view is the useful one: each queue lists the registered URLs and the processes attached to it. - Match the process ID to a name. Take the process ID from the queue and run
tasklist /fi "PID eq 1234", replacing 1234 with the ID you found. Aw3wp.exeorsvchost.exehosting W3SVC means IIS. - Check reservations. Run
netsh http show urlaclto see URL reservations. Our page on netsh http show urlacl explains how to read the output. - Stop or reconfigure the owner. For IIS, stop the World Wide Web Publishing Service in services.msc, or change the site binding in IIS Manager. For another app, change the URL it registers or stop it.
- Check again. Run the netstat command from step 1. When nothing is listening on the port, start your own server.
If the netsh output lists nothing for the port but PID 4 still holds it, the listener may be a different kernel component. Reboot once to rule out a stale registration, then repeat the steps.
Should I end the System process to free the port?
No. PID 4 is the System process, the core of Windows itself, so it is not something to terminate. Tools that let you type a PID and kill it can fail with an access error on PID 4, and the errors do not explain why.
This is where a port tool should help instead of getting in the way. Port Detective shows PID 4 owners as System and its privilege-aware interface flags protected OS processes, so you are not offered an action that cannot work. The useful next step is the trace above, and Port Detective’s copy-as-command feature puts the netstat, taskkill, and PowerShell syntax for the selected port on your clipboard.
Get the process name, PID, and path for every listening port, with protected system owners clearly marked.
Get it from Microsoft
How is this different from a normal “port already in use” error?
In a normal conflict, a regular user-mode process owns the port: a leftover Node server, a database, a Docker proxy. You find the PID, confirm it is the right program, and end it. Our guide to killing the process on a port covers that flow.
With PID 4 the owner is shared infrastructure. The fix is configuration, not termination:
| Symptom | Normal app conflict | HTTP.sys conflict |
|---|---|---|
| PID in netstat | A real app such as node.exe | 4 (System) |
| Can you end it? | Yes, after confirming | No |
| Real owner | The process itself | The service that registered a URL |
| Fix | End the process or change ports | Stop or rebind the registering service |
| Tool to inspect | netstat, Task Manager, Port Detective | netsh http, IIS Manager, services.msc |
Port 443 behaves the same way. If you see System on 443, our page on what is using port 443 walks through the other common owners, and the port 8080 page covers the alternative port many developers move to.
Can I just use a different port?
Often that is the fastest fix. If you are running a local dev server, move it to 8080, 3000, or another free port and leave IIS alone. That is the right call when:
- The machine is managed and IIS or another HTTP.sys app is required by IT.
- You only need port 80 for convenience, not because a client insists on it.
- You do not have administrator rights to stop services.
Change ports only after checking the new one is free. A port that looks free in a browser can still be reserved by Windows. Our pages on the excluded port range and Hyper-V reserved ports explain those cases.
How does Port Detective help with PID 4 conflicts?
Port Detective is a native Windows app (built in Rust) that lists every listening port with its process name, PID, and executable path. For this problem it saves you three things:
- The first look. Search for 80 and see immediately whether the owner is System or a normal app, without reading netstat columns.
- Protection from bad kills. The privilege-aware interface marks protected OS processes, so PID 4 is not treated like a stray node.exe.
- The commands. Copy-as-command gives you the netstat, taskkill, or PowerShell syntax for the port so you can paste it into a ticket or terminal.
The free edition covers live listening ports, instant lookup, and 5 guarded kills. Port Detective Pro, a one-time purchase, adds unlimited kills, TCP and UDP for IPv4 and IPv6, Port Guard (a tray monitor that checks every 250 ms and can end an intruder on a port you have claimed), parent and child process lineage, and a connection history timeline you can export to CSV or JSON. It has no telemetry.
What it does not do is read HTTP.sys request queues for you. For that, netsh http show servicestate is still the right tool, and it is free and built in.
Frequently asked questions
Is PID 4 on port 80 a virus?
Usually not. PID 4 is the System process, and HTTP.sys listeners are accounted to it. If you see it, look for IIS or another HTTP Server API app first. If you find no registered owner and you did not install anything that uses HTTP.sys, investigate further with your security tools.
Why can’t taskkill end PID 4?
Because it is the System process, the core of Windows, not an app you own. Stop the service that registered the URL instead.
Does stopping IIS free port 80?
If IIS was the registrant, stopping the World Wide Web Publishing Service (or the site bound to port 80) releases the registration and the port. Check with netstat afterward.
Does the same thing happen on port 443?
Yes. HTTP.sys can hold 443 for HTTPS registrations in exactly the same way.
Can Port Detective kill the app behind HTTP.sys?
Once you know the registering app and it is a normal process, Port Detective can end it like any other process. It will not try to end PID 4 itself.
Try Port Detective
Get the free edition from the Microsoft Store, or buy Port Detective Pro once for unlimited kills, Port Guard, and history. Read more on the Port Detective product page, or learn the command line side in our netstat guide for developers.
Find the owner of any port in one search, then keep it yours with Pro.
Get it from Microsoft
Microsoft, Windows, and IIS are trademarks of the Microsoft group of companies. Other product names are trademarks of their owners. Port Detective is not affiliated with or endorsed by any of them.
Last updated 17 October 2026. Published by Automata Labs, a software company in Canada.