我正在调查一系列自定义应用程序（其中一些我们控制，一些则不然）中 winsock 10055 错误的一些问题，希望获得一些关于解决问题的技术建议。
No buffer space available.
An operation on a socket could not be performed because the system
lacked sufficient buffer space or because a queue was full.
根据研究，非分页池和端口似乎是唯一可能导致此错误的资源。 是否有其他资源可能会导致 10055 错误？
目前，我们在应用程序上设置了性能计数器，在大多数情况下，非分页池使用率看起来很低。打开的 TCP 连接看起来很低，我不知道还有其他方法可以监控端口。
由于这种情况只发生在生产中，我们无法使用更具侵入性的计数器。不过，听到其他解决方案仍然很有趣。我相信其他人可以使用这些信息。
您是否推荐其他工具或程序来诊断哪个应用程序导致了该问题？
更新：
该平台是带有 /3G 开关的 Windows Server 2003 x86。作为参考，x86 通常具有 256mb 的 NPP 存储，/3G 将其降低到 128mb。一般来说，您需要避免这种配置以避免 NPP 问题。（参考）
我们有一个应用程序的源代码。我编写了非常复杂的测试工具，试图重现该行为，但无济于事。
如上所述，该问题仅发生在生产中。因此，避免了数据包监控。我们目前设置了性能计数器来监控 NPP、线程、网络流量等。由于 perfmon 的间隔为 1 秒，因此您可能会遇到在该窗口内来来去去的微突发。然而，有一些主观证据表明这不是问题。
基本情况是，连接的另一端表示由于错误代码为 10055 而关闭了连接。在断开连接之前，NPP（以及总体性能）看起来很稳定，这表明某些其他资源是导致连接断开的原因。
更新：
我还要重申，最初的问题与诊断有关，而不是解决方案。我仍然不清楚导致 10055 错误的原因。检查驱动程序和硬件并重新安装操作系统是很好的方法，但它回避了最初的问题。
答案1
根据 Google 搜索，内存不足也会导致这种情况，除此之外还有其他原因。我在 Google 上发现的一个错误情况是内存不足问题，即基本操作系统几乎无法访问内存。我猜想，在内存不足的虚拟环境中，很容易重现相同类型的问题。
一个更基本的故障排除问题很简单——您的生产环境有何不同？
您是否在 Windows 2003 x64 或 Windows 2008 中测试过该应用程序？
关于你问题的第二部分...
以下工具可用于排除故障和修复 Winsock 错误。
嗅探器：
http://www.wireshark.org/
垫片：
http://www.sstinc.com/winsock.html http://www.win-tech.com/html/socktspy.htm
用于跟踪系统状态和资源的通用工具
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx http://technet.microsoft.com/en-us/sysinternals/bb896645
检测 API 调用的工具
http://www.apimonitor.com/ http://www.nektra.com/products/spystudio-api-monitor/
调试器
http://www.ollydbg.de/ http://www.immunitysec.com/products-immdbg.shtml
逆向工具或反编译器
http://www.hex-rays.com/products/ida/index.shtml http://www.hex-rays.com/products/decompiler/index.shtml
您的标准 IDE 和编译器
http://www.microsoft.com/visualstudio/en-us
以下是其他工具的列表：
http://www.sockets.com/devtools.htm
找到的其他参考资料：
https://stackoverflow.com/questions/8118870/howto-debug-winsock-api-calls
http://brandon.fuller.name/archives/2007/01/24/19.44.29/
http://tangentsoft.net/<---- 可能是最好的一个
答案2
重新安装 2008 R2 服务器，希望可以正常工作。它具有全新的驱动程序架构和更好的网络可扩展性。
答案3
我不知道这是否有用，但我遇到了一个每隔几秒发送 UDP 广播消息的应用程序的 10055 错误。当广播应用程序位于笔记本电脑上并进入睡眠状态并被唤醒时，就会发生这种情况。
忽略几次连续的 UDP 广播的错误解决了这个问题。
当应用程序在睡眠后重新启动广播时，WinSock 似乎尚未完全恢复。