I've had a recurring issue with a client's web server and the local installed instance of SQL Server 2005 Express, in this case, but this issue applies to all versions of 2005 and 2008. The behavior was that the service would fail to start automatically once the system was rebooted, but once I connected via the RRAS VPN and then Terminal Services for remote management, the service would start up just fine. The Windows Event Log had the following SQL Server error messages, immediately back-to-back in order (SQL Server itself has the same messages in its own logs):

- Server failed to listen on x.x.x.x <ipv4> xxxxx. Error: 0x2741. To proceed, notify your system administrator.
- TDSSNIClient initialization failed with error 0x2741, status code 0xa.
- TDSSNIClient initialization failed with error 0x2741, status code 0x1.
- Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
- SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

The server was configured to listen on only certain IP addresses, on port xxxxx. 127.0.0.1 was the primary address for the local web sites to use, and x.x.x.x was the private IP address assigned to the RRAS server; this was for remote management of the SQL Server via the VPN connection. Hopefully your light bulb is going off over your head more quickly than it did mine!

In general, the series of errors above are due to SQL Server being unable to bind to the IP address in question, perhaps due to the address not existing at the time of service startup. In my case, that is exactly what was going on. The x.x.x.x IP address did not actually exist on the server upon booting up until the first VPN connection had been made. So once I 'dialed-in', that address then existed, and so I could start SQL Server up manually at that point.

The solution in this case was to simply enable SQL Server to listen on All IP addresses, and simply be sure that access via the public IP address was blocked.

The Cause

This issue might be slightly uncommon; I know it is for me. The SQL Server here is effectively firewalled from public access, with the intent being that only the local web sites or VPN clients will be able to connect to it. This particular server is a managed hosted solution at a large hosting facility, so there is no separate corporate firewall to provide security functionality such as the VPN and packet filtering, though there is simple port blocking at the router level available via the host's management interface, and of course Windows' own built-in firewall.

Those options were used to prevent public access to the database and RDP (Terminal Services, for remote desktop access) until the VPN connection is established via RRAS dial-in. The use of the private IP for the RRAS interface is, as noted above, what caused this particular problem. Others have experienced the same series of errors due to other situations resulting in SQL Server attempting to bind to IP addresses which may not exist as the service is attempting to start. In many of those cases, binding to "All" IP addresses instead of specific ones can help, but some more complex scenarios do not permit that.