NO APACHE CONF CHANGE - a working windows arbitrary binding to NOT port 80_
You're providing excellent diagnostic information!
PS C:\WINDOWS\system32> netsh http show servicestate
Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------
Server session ID: FF00000710000001
Version: 2.0
State: Active
Properties:
Max bandwidth: 4294967295
Timeouts:
Entity body timeout (secs): 120
Drain entity body timeout (secs): 120
Request queue timeout (secs): 120
Idle connection timeout (secs): 120
Header wait timeout (secs): 120
Minimum send rate (bytes/sec): 150
URL groups:
URL group ID: FE00000720000001
State: Active
Request queue name: Request queue is unnamed.
Properties:
Max bandwidth: inherited
Max connections: inherited
Timeouts:
Timeout values inherited
Number of registered URLs: 1
Registered URLs:
HTTP://*:5357/E1EAEFA8-855C-4CCE-A0CE-A8BD00F42C40/
Request queues:
Request queue name: Request queue is unnamed.
Version: 2.0
State: Active
Request queue 503 verbosity level: Basic
Max requests: 1000
Active requests: 0
Queued requests: 0
Max queued request age: 0s
Requests arrived: 9
Requests rejected: 0
Cache hits: 0
Number of active processes attached: 1
Processes:
ID: 12340, image: C:\Windows\System32\svchost.exe
Services: FDResPub
Tagged Service: FDResPub
Registered URLs:
HTTP://*:5357/E1EAEFA8-855C-4CCE-A0CE-A8BD00F42C40/
This output from netsh http show servicestate is very insightful because it shows the current state when Apache is working correctly.
What this output tells us is:
HTTP.sys is active: Yes, the HTTP Service (HTTP.sys) is running on your system.
It's being used by FDResPub: The Function Discovery Resource Publication service (PID 4404 svchost.exe) is indeed using HTTP.sys.
Crucially, HTTP.sys is currently listening on port 5357, NOT port 80. The URL shown is HTTP://*:5357/E1EAEFA8-855C-4CCE-A0CE-A8BD00F42C40/.
This confirms that when your system is in a "working config" state (Apache is running), HTTP.sys is not the component occupying port 80. The FDResPub service relies on HTTP.sys, but it's using a different port (5357), which is standard for mDNS/SSDP-related discovery protocols.
Therefore, the intermittent problem where svchost.exe (PID 1908 in your previous netstat output) claims port 80 is caused by a different component or service that also uses HTTP.sys but only sometimes registers itself on port 80.
The Plan Remains:
The most effective way to identify the exact intermittent culprit is to capture the netsh http show servicestate output at the precise moment Apache fails to start due to port 80 being in use.
Continue using Apache on port 80 as you are now.
The very next time Apache fails to start with the error "AH00072: make_sock: could not bind to address [::]", immediately (before doing anything else like rebooting):
Open an Administrator Command Prompt or PowerShell (Admin).
Run: netsh http show servicestate
This output will be critical. It should show an HTTP://*:80/ listener, and hopefully, tell us the Process ID and possibly the Process name or Services associated with that specific port 80 binding at that moment.
This will give us the definitive answer as to what Windows component is intermittently claiming port 80, allowing us to then look into configuring that specific component to use a different port, or disabling it if it's not essential.