We have a front end written in Visual Basic 6.0 that calls several back end DLLs written in mixed C/C++. The problem is that each DLL appears to have its own heap and one of them isn’t big enough. The heap collides with the program stack when we’ve allocated enough memory.
Each DLL is written entirely in C, except for the basic DLL wrapper, which is written in C++. Each DLL has a handful of entry points. Each entry point immediately calls a C routine. We would like to increase the size of the heap in the DLL, but haven’t been able to figure out how to do that. I searched for guidance and found these MSDN articles:

<http://msdn.microsoft.com/en-us/library/hh405351(v=VS.85).aspx>

These articles are interesting but provide conflicting information. In our problem it appears that each DLL has its own heap. This matches the “Heaps: Pleasures and Pains” article that says that the C Run-Time (C RT) library creates its own heap on startup. The “Managing Heap Memory” article says that the C RT library allocated out of the default process heap. The “Memory management options in Win32” article says the behavior depends on the version of the C RT library being used.

We’ve temporarily solved the problem by allocating memory from a private heap. However, in order to improve the structure of this very large complex program, we want to switch from C with a thin C++ wrapper to real C++ with classes. We’re pretty certain that the new and free operator won’t allocate memory from our private heap and we’re wondering how to control the size of the heap C++ uses to allocate objects in each DLL. The application needs to run in all versions of desktop Windows-NT, from 2000 through 7.

**The Question**

> 
> Can anyone point us to definitive and correct documentation that
>  explains how to control the size of the heap C++ uses to allocate
>  objects?
> 
> 
> 

Several people have asserted that stack corruption due to heap allocations overwriting the stack are impossible. Here is what we observed. The VB front end uses four DLLs that it dynamicly loads. Each DLL is independant of the others and provides a handful of methods called by the front end. All the DLLs comunicate via data structures written to files on disk. These data structures are all structured staticlly. They contain no pointers, just value types and fixed sized arrays of value types. The problem DLL is invoked by a single call where a file name is passed. It is designed to allocate about 20MB of data structures required to do complete its processing. It does a lot of calculation, writes the results to disk, releases the 20MB of data structures, and returns and error code. The front end then unloads the DLL. While debugging the problem under discussion, we set a break point at the beginning of the data structure allocation code and watched the memory values returned from the calloc calls and compared them with the current stack pointer. We watched as the allocated blocks approached the the stack. After the allocation was complete the stack began to grow until it overlapped the heap. Eventually the calculations wrote into the heap and corrupted the stack. As the stack unwound it tried to return to an invalid address and crashed with a segmentation fault.

Each of our DLLs is staticly linked to the CRT, so that each DLL has its own CRT heap and heap manager. Microsoft says in <http://msdn.microsoft.com/en-us/library/ms235460(v=vs.80).aspx>:

> 
> Each copy of the CRT library has a separate and distinct state. 
>  As such, CRT objects such as file handles, environment variables, and 
>  locales are only valid for the copy of the CRT where these objects are 
>  allocated or set. When a DLL and its users use different copies of the 
>  CRT library, you cannot pass these CRT objects across the DLL boundary 
>  and expect them to be picked up correctly on the other side.  
> 
>  Also, because each copy of the CRT library has its own heap manager, 
>  allocating memory in one CRT library and passing the pointer across a 
>  DLL boundary to be freed by a different copy of the CRT library is a 
>  potential cause for heap corruption.
> 
> 
> 

We don't pass pointers between DLLs. We aren't experiencing heap corruption, we are experiencing stack corruption.