Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm investigating some issues with winsock 10055 errors on a chain of custom applications (some of which we control, some not) and was hoping to get some advice on techniques to troubleshoot the problem.

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.

From research, non-paged pool and ports seem to be the only resources which can cause this error. Is there another resource which might cause 10055 errors?

Currently, we have perfmon counters setup on the applications and non-paged pool usage looks low in most circumstances. Open TCP connections looks low and I am unaware of another way to monitor ports.

Since it only happens in production, we are unable to use more invasive counters. Though it would still be interesting to hear other solutions. I'm sure other people could use the information.

Is there some other tool or procedure you would recommend to diagnose which application is causing the issue?


The platform is windows server 2003 x86 with the /3G switch. For reference, x86 generally has 256mb of NPP storage, /3G lowers it to 128mb. In general, you'd want to avoid this configuration for avoiding NPP problems. (reference)

We have source to one application. I have written pretty elaborate testing harnesses trying to reproduce the behavior to no avail.

As mentioned, the problem only happens in production. As such, packet monitoring has been avoided. We currently have performance counters setup that monitors NPP, threads, network traffic, etc. Since perfmon's interval is 1sec, you could have microbursts that come and go within that window. There is somewhat subjective evidence that this isn't the problem however.

The basic situation is that the other side of the connection says that it has closed the connection due to errors with 10055 as the code. NPP (and performance in general) looks stable prior to disconnects, which points to some other resource being the cause.


I'd also reiterate that the original questions pertain to diagnosis, not solutions. I still don't have a clear answer on what causes 10055 errors. Checking drivers and hardware and reinstalling operating systems is great, but it sidesteps the original question.

share|improve this question
I'd say that the NIC or driver could contribute to this. – Ignacio Vazquez-Abrams Jun 23 '12 at 2:39
@IgnacioVazquez-Abrams NPP leaks can definitely be generated by bad drivers. In this instance, the problem has been ongoing and network hardware has been vetted. – Tom Kerr Jun 23 '12 at 17:30
Check with netstat if really thats because of ports. This is probably because of some driver, so other machine might be OK, otherwise you would need to re-design the software. Also try to use 2008 R2 or 7. – Andrew Smith Jun 23 '12 at 17:32
Concur with the idea on bad drivers, and with different hardware, it would make sense that this error would only be showing up in production. Might be easy to test removing via creation of a virtual environment but unsure if that could work due to the production nature. – Brennan Jun 24 '12 at 0:47
I would love to put it on better hardware with a x64 operating system, but that really isn't an option. Drivers and hardware have been validated. – Tom Kerr Jun 24 '12 at 1:08

Ram shortages can cause this also, according to Google searches, among other things. An error condition I observed via Google in finding some of below was low memory issues where the base operating system had little access to RAM. My guess is that same type of problem could easily be recreated in a virtual environment that is starved for ram.

A more fundamental troubleshooting question is quite simply - what is different with your production environment?

Have you tested the application in Windows 2003 x64 or Windows 2008?

Onto the 2nd part of your questions..

The following tools can be used for troubleshooting and fixing Winsock errors.



General purpose tools to track the system status and resources

Tool to detect the API calls


Reversing tools or decompilers

Your standard IDE and compiler

Here is a list of other tools:

Other references found: <---- Probably the best one

share|improve this answer
I'll update the question here in a bit, I don't have some info at hand. References on causes (ram/other things) would be much obliged. – Tom Kerr Jun 23 '12 at 18:20
This seems more like an extended/distended comment than an Answer. Any chance of cleaning this up a bit? – Chris S Jun 23 '12 at 21:42

Reinstall with 2008 R2 server, this will work hopefully. There is absolutely new driver architecture and way better networking scalability.

share|improve this answer
In general, this would be a good thing to try. Platform upgrades would help, especially going to x64 operating systems. They have much larger non-paged pools. – Tom Kerr Jun 23 '12 at 17:44
I would even try Windows 8, as it's possible to upgrade current release to the stable version once it's released automatically via windows update. – Andrew Smith Jun 23 '12 at 18:06

I don't know if this will help but I encountered a 10055 error in an application sending out UDP broadcast messages every few seconds. It happened when the broadcasting application was on a laptop which went to sleep and was woken up.

Ignoring the error for a couple of consecutive UDP broadcasts solved the problem.

It looked like WinSock hadn't been completely restored when the application restarted broadcasting after the sleep.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.