Having seen the litany of non-answers (and random guesses) on the SqlClient.SQLException:
"A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)"
I decided to figure this out for myself. No, it has nothing to do with named pipes or TCP/IP protocols or using wireless connections or VPNs--it has to do with the SQL Server instance configuration. And no, you don't have to disable connection pooling. Frankly, I would be surprised if lack of a connection pool would fix the problem.
This is not a new problem. Consider that when the SQL Server is accessed by a client that wants to open another connection the server instance must validate the credentials and make sure that the connection is valid in a number of ways. Once that's done, the SQL Server instance then tries to add the connection to the already existing connections its managing--it's own internal pool of active connections. Ordinarily (and by default), SQL Server instances can accept any number of connections. In a practical sense, this is not always possible so the DBA might set the number of connections on the instance to some value--N. Once N connections have been made the next connection attempt might get through the login layer but the server simply cuts it off at the knees and forcibly closes it. Hopefully, this does not pooch the client-side connection pool--that remains to be seen (still testing that) but it does throw the exception mentioned above.
We still see this error when testing with a connection limit cap (even a big one like 100 connections) when using Visual Studio doing iterative tests. That's because if your code does not close the connection(s) it opens during a test run, when you start a new run you get a new process id and a new connection pool but the old pool is owned by Visual Studio and the connections remain. Don't believe me? Turn on the Perfmon tool and monitor the SQLClient connection pool counters and see... open some connections and kill the application without closing the connections. Note that the number of pools and pooled connections don't go down until you exit Visual Studio.
The solution? Either trap the exception and try again or take your DBA some candy and flowers and get him (or her) to bump up the number or set the number of connections to "0" which says to not limit the number of connections. This is done in SSMS and should only be necessary if someone has been playing with the setting. Just remember to restart the SQL Server instance service after making this change—SSMS won’t remind you to do so.