这是完整的错误：SqlException: A transport-level error has occurred when receiving results from the server. (provider: Shared Memory Provider, error: 1 - I/O Error detected in read/write operation)
对于我的应用程序中的一些单元测试，我已经开始间歇性地看到此消息（有超过 1100 个单元和系统测试）。我正在使用 ReSharper 4.1 中的测试运行器。
另一件事：我的开发机器是 VMWare 虚拟机。
我在很多个月前遇到了这个问题。底线是你的可用端口用完了。
首先确保您的调用应用程序启用了连接池。
如果确实如此，则检查 SQL Server 的可用端口数。
发生的情况是，如果池关闭，那么每个调用都会占用一个端口，默认情况下需要 4 分钟才能使端口过期，并且您的端口即将用完。
如果池已打开，那么您需要分析 SQL Server 的所有端口，并确保您有足够的端口并在必要时扩展它们。
当我遇到此错误时，连接池已关闭，并且只要在网站上施加了不错的负载，就会导致此问题。我们在开发中没有看到它，因为最大负载是 2 或 3 人，但是一旦数量增加到 10 人以上，我们就会一直看到这个错误。我们打开了池化，它修复了它。
我在很多个月前也遇到过这个问题。但是，不要打折@Longhorn213s 的解释，但我们有完全相反的行为。我们在开发和测试中收到错误，但在负载明显更大的生产中没有收到。我们最终容忍了开发中的问题，因为它是零星的，并没有实质性地减慢进度。我认为这个错误可能有几个原因，但我自己一直无法确定原因。
我们也遇到了这个错误，并发现我们正在从数据库服务器终止 SQL 服务器连接。客户端应用程序认为连接仍然处于活动状态并尝试使用该连接，但由于它被终止而失败。
我们在我们的环境中看到了这一点，并将其中的一部分追溯到我们查询中的“NOLOCK”提示。我们删除了 NOLOCK 提示并将我们的服务器设置为使用快照隔离模式，这些错误的频率大大降低了。
我们已经多次看到此错误，并尝试了不同的解决方案并取得了不同的成功。一个常见的潜在主题是给出错误的系统内存不足。如果托管 Sql Server 的服务器正在运行任何其他非操作系统进程，则尤其如此。默认情况下，SQL Server 将获取它可以获取的任何内存，然后为其他进程/驱动程序留下很少的内存。这可能会导致行为不稳定和消息断断续续。如果有其他进程可能需要它，最好将 SQL Server 配置为留出一些空间的最大内存。示例：在同一台计算机上运行 SQL Server 开发人员版副本的开发计算机上的 Visual Studio。