Question : How do I (re-)enable heap memory allocation within a CWinThread-derived class thread function invoked directly from InitInstance?

This question has morphed into a "can you reproduce the symptom error" problem. - The first comment (from myself) below has a sample program attached, so if someone has a theory as to what may have happened, a quick modification to the sample program should reproduce it easily enough.

I have created a worker thread function wrapped by a CWinThread-derived object.(called ThreadProcObject) -

Within the thread routine (invoked directly from InitInstance - thus Run() and the message pump are not started up) an attempt to allocate some heap memory is made (see example program routines Run1() or Run2()) and, when the error occurs, _malloc_debug() is invoked within the runtime operator new() routine and returns NULL.

At least, this was the symptom in my orignal program, which I have yet to reproduce in the attached sample.

 I originally thought that what was happening is that in between the time the CWinThread-derived object's constructor is invoked and time the thread routine is called by InitInstance (note, before Run1() or Run2() is invoked, the thread goes to sleep first waiting on a "task op ready" event), and that some part of the (heap?) context changes, thus effectively disabling the operator new routine and that this could be resolved by calling some appropriate Afx...? routine to restore the heap context, but this appears to be wrong

An examination of the InitInstance() call to ThreadProc(), that routine's WaitForMultipleObjects-delayed calls to Run1() or Run2() and the memory allocation calls in Run1() or Run(2) should ring a bell if someone has any theories as to how _malloc_dbg() could return NULL if adequate heap memory exists.

I'll award the points if someone actually can reproduce the problem (see the comment below and its attached  program)  within the attached program  - and explain how it happened in the first place.

Answer : How do I (re-)enable heap memory allocation within a CWinThread-derived class thread function invoked directly from InitInstance?

If the original program is working well, then that is good.  You could leave good enough alone, but I still think that you should change your thread logic to be more object oriented as I have mentioned.  As it stands, it is hard to pick up how things work from looking at your code: you have UI mixed with lower level functionality.  A thread class modularizes everything so much better and makes for easier reading, hence debugging if something should need looking at at a later date.
But hey, it is your project... :)
>> do you have any idea why, when it is terminated by clicking the 'x' button, the debugger indicates memory leaks?
I see the following after I start the debugger, press the start button, then close the app:
<code>
Detected memory leaks!
Dumping objects ->
{542} normal block at 0x00DB16A0, 16 bytes long.
&nbsp;Data: <&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > A8 15 DB 00 CD CD CD CD CD CD CD CD CD CD CD CD
{541} normal block at 0x0003FBE8, 32 bytes long.
&nbsp;Data: <&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > A0 16 DB 00 00 00 00 00 00 00 00 00 00 00 00 00
{526} normal block at 0x00DB3FA0, 28 bytes long.
&nbsp;Data: <&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; > 00 00 00 00 CD CD CD CD CD CD CD CD E8 FB 03 00
Object dump complete.
</code>
So I add the following to CWinThreadTestApp::InitInstance():
<code>
&nbsp;_CrtSetBreakAlloc ( 542 );
&nbsp;_CrtSetBreakAlloc ( 541 );
&nbsp;_CrtSetBreakAlloc ( 526 );
</code>
Now when the debugger is started, I immediately get a debug break on the line:
<code>
OpRequestQ = (queue<OpRequestObj*>*)
&nbsp;&nbsp;&nbsp;&nbsp;new queue<OpRequestObj*>;&nbsp;//[MAX_CONCURRENT_POLLS+1];
</code>
so, add
<code>
if ( OpRequestQ ) delete OpRequestQ;
</code>
to your destructor :)&nbsp; _CrtSetBreakAlloc really is a great function to make extensive use of when necessary :)