EventLog: Server TCP provider failed to listen on [ 'any'  1433]. Tcp port is already in use This isn't a duplicate; my scenario is different from others I've found:

MSSQLSERVER service does *not* start, port 1433 in use
https://blogs.msdn.microsoft.com/sql_pfe_blog/2016/10/05/tcp-port-is-already-in-use/
https://support.plesk.com/hc/en-us/articles/213409409

Differences:


Neither cls &amp; netstat -oanb -p tcp nor TCPView reveal anything listening on port 1433
According to the EventLog message, this is occurring on IPV6
The problem doesn't manifest for two named instances running on the same machine—only the default instance


To my knowledge, I'm not using IPV6 in any way, shape or form. I certainly haven't configured it.

The service will start when I make any of these configurations:


Disable TCP/IP in SQL Configuration Manager
Enable TCP/IP but turn off Listen All in TCP/IP Properties
When Listen All is off, disable all IPs on the IP Addresses tab


If I do either of these, the service fails to start:


Turn on Listen All
Enable any IP address


This has got me pulling my hair out.

What's gone wrong here?
Because netstat doesn't indicate that anything is listening on port 1433, that leaves the possibility that a client is already using port 1433 when SQL tries to start. From the SQL Server Premier Field Engineer blog post about "TCP Port is already In Use":


  The second situation involves a client running on the server using the same dynamic port as SQL Server. Every TCP session requires two endpoints – a client endpoint and a server endpoint. Each endpoint is an IP Address/Port combination - also known as a TCP socket. Normally, the client socket code will ask the OS to provide a port from a range of dynamic ports. The server socket is the IP/TCP port of the service the client is connecting to (SQL Server for example).


The default dynamic port range might include port 1433. You can check it with netsh int ipv4 show dynamicportrange tcp.


  ...if you happen to have a client (think Windows OS system services) that starts BEFORE SQL Server does, it could use TCP/1433 for its client socket.
  ...
  So, how do you fix and prevent a situation like this? There's another feature within the OS that allows you to tell the OS the TCP ports in the Dynamic Port Range that should be EXCLUDED. All that is needed is to run the following with an Administrative Command Prompt:


netsh int ipv4 add excludedportrange tcp startport=1433 numberofports=1 store=persistent



  After that setting is made, the OS will not give any clients that port. Services can listen on it still, but you prevent clients from getting it when asking the OS for a dynamic port.


IPv6 version

The original poster indicated that even though the logged error mentioned IPv6, his problem turned out to be with IPv4. But if it had been an IPv6 port conflict, the same process can be followed for IPv6.

netsh int ipv6 show dynamicportrange tcp

netsh int ipv6 add excludedportrange tcp startport=1433 numberofports=1 store=persistent