Re: CreateThread Fails with ERROR_NOT_ENOUGH_MEMORY....

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Pavel,
bp kernel32!CreateSemaphoreW "k;.echo;g" definitely helped us. We were able to figure out the stack of the culprit func. We have dispatched the bug to the relevant group owning the routine which was leaking semaphores & events & they are looking into it now.
As far as the VM usage is concerned, I still believe that, given the amount of stress involved in the test, we are bound to run out of virtual memory ( as reported by Perfmon & not by Task Manager ). We have used the /3GB switch on advanced server & the test is running fine now with no issues of thread creation failing.

Thanks again,
Gary.


Pavel Lebedinsky [MSFT] wrote: 
Looks like you're leaking file, event and semaphore handles. Events
and semaphores are probably part of the same problem since their
numbers are very close.

Take a look at your process with Process Explorer from
sysinternals.com. You might be able to tell who is leaking file handles
based on their names (for events and semaphores this is less likely
to help since they probably don't have names, but it's still worth
checking).

If that doesn't work, and if you can't repro on XP or W2K3 where
you can use !htrace then your options are:

1. Code review - look for places where you create files, events
and semaphores.

2. Try to find a 3rd party tool that can track down handle leaks.

3. Set a tracing breakpoint in debugger and try to find out who
allocates the objects. If you leaked 23000 semaphores in 50 hours
it translates to 1 semaphore every 8 seconds or so. You can
set a breakpoint like this:

0:000> bp kernel32!CreateSemaphoreW "k;.echo;g"

and let the process run for a couple of minutes. If you see the same
trace every few seconds then this is probably your culprit. However
if there's too much noise (that is, objects are being created and
destroyed much more often than they are leaked) this method
quickly becomes impractical.

Now about the (suspected) memory leak. What are your Private
Bytes and Virtual Bytes at the time you start getting CreateThread
errors? It's also useful to collect a perfmon log of these counters
(as well as Process\Handle Count and Objects\*), sampling them
every few minutes. This will tell you if they grow linearly (the most
typical leak pattern) or in one or more big jumps.

Also, can you post the output of '!heap -stat' ? Based on the
output below it doesn't look like you have a lot of heap allocations
(the largest heap segment is only a few MB) but we should also
check how much memory is consumed by large allocations which
the heap redirects to VirtualAlloc.

You can also start troubleshooting the problem as if it was a leak
(even though at this point I can't tell if it's really a leak, and if so,
what kind of memory is leaking). Microsoft has a tool called
LeakDiag that you can use (google for the link); I think there are
a few 3rd party ones as well.

.

Relevant Pages