Debugging strategy to find the cause of bad_alloc

Another possible problem is that, while you mention that the program is using less than 5MB, you don't mention how much space it's trying to allocate. You could have some race condition that's corrupting the value that you use to determine the allocation size, and it could be trying to allocate 37TB or somesuch nonsense.

Not particularly likely, I suppose, but worth checking.

bad_alloc can be thrown by other code as well.

I've seen it used by a limiting memory pool designed for use with STL containers. When the size limit was hit, it threw bad_alloc and the software just had to handle it.

bad_alloc can also be thrown when you have a bug that is overwriting the pointers that the heap uses to manage the pool of memory that it uses to allocate from.

The most common cause of that is that you are writing past the end of an allocated block of memory, (or before the start, but that's less common). Almost as common is writing to a memory block after it has been freed. This is called heap corruption.

Also, I should note, a 32 bit process in Windows has at most 2GB of address space (3GB for large-address-aware programs). This is regardless of how much RAM you have installed, the memory is virtual, and allocations don't fail until you run out of address space, even if you only have 1GB of RAM.

Here is a good discussion of memory corruption in C++ http://www.eventhelix.com/RealtimeMantra/Basics/debugging_software_crashes_2.htm

Few clarifications:

Every process in windows gets 4GB virtual memory, out of which 2GB is for user space and remaining for kernel space. The 4GB of RAM won't contribute to the virtual memory but it is for physical memory.

In the 2GB memory, all EXE, DLL gets loaded and hardly 1.6 - 1.7GB available for memory allocation. In this memory if there is no contiguous memory for allocation then the memory allocation fails.