Binding winsock shortly after boot results in error 10049 (WSAEADDRNOTAVAIL)

Question

Hi all,

In one of our applications we are facing an issue with binding a socket for listening, when the process that is binding the socket is started shortly after boot of Windows.
The situation is as follows:
We have a Windows 10 IoT Enterprise OS (1809) with auto-logon enabled. The system shell (explorer.exe) is replaced by a custom application that starts a process which needs to host a TCP server. For this we use the GetAdaptersAddresses to find the IP address of the network adapter on which we want to host the server, and once we have found a valid IP for the adapter we try to create and bind a socket to that IP address.
Since we have auto-logon enabled and the process is started as part of starting the 'shell', the process is created early in the start-up of Windows.

What we are seeing is that under certain circumstances (see below), the bind call fails with error code 10049 (WSAEADDRNOTAVAIL). Which is weird, because the IP address we provide is a static configured IP which we found via the GetAdapterAddresses API call. So the IP address is definitely valid, only winsock doesn't seem to think so.

So far we are only able to reproduce it with having at least 2 network adapters in the following configuration:

• Adapter A: Adapter to use for hosting the TCP server and configured with a static IP
• Adapter B: Adapter used for other purposes and configured for DHCP

If Adapter B is also configured with a static IP, we don't see the bind fail. If Adapter A is configured for DHCP we also don't see the bind failure.
If we introduce an artificial delay in our application of a few seconds before trying to create the socket, the socket bind also succeeds.

My working theory is that when we are trying to create and bind the socket, Windows is still busy with some network initialization, causing the bind to fail. Adding the artificial delay or changing the network configuration to all static IPs (and thus reducing network initialization time) support this theory. However I cannot find any reference on the Microsoft website that confirms this theory and I can also not find any API call that can be used to check if Windows is completely ready for creating winsockets.

For now we introduced a re-try loop when the bind fails, and after a couple of retries the bind succeeds. But I would really like to know of there is a more ellegant way to handle this and if somebody is maybe able to confirm my theory.