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.