Can I trust the stack traceback symbol names in a fatal exception that occurs early in the startup in my C++/STL/MFC application?

Question

I am getting access violations in mfc90d.dll in CObject:IsKindOf , the deepest item on the call stack, which is actually apparently run long before WinMainCRTStartup is, and which probably is in my app because I wrote a standard container of some of my application's model objects; std::map<int, CDevice*> somewhere, leading to the following templated container C++ type existing, and then showing up in my call stack:

myapp.exe!std::_Tree<std::_Tmap_traits<int,CDevice   
         *,std::less<int>,std::allocator<std::pair<int const ,CDevice *> >,0> 
          >::_Copy(const std::_Tree<std::_Tmap_traits<int,CDevice 
         *,std::less<int>,std::allocator<std::pair<int const ,CDevice *> >,0> > &                     
         _Right={...})  Line 1067 + 0x1d bytes  C++

I am not 100% sure that the std::map<int, CDevice*> is the reason, but it's the only templates reference involving "CDevice*" that I could find.

The whole call stack, given slightly simplified (ellipsis ... indicates omission of some details of the function signature).

mfc90d.dll!CObject::IsKindOf(const CRuntimeClass * pClass=0x691a09ec)  
mfc90d.dll!CDocManager::OpenDocumentFile(const char * lpszFileName=0x007783e8)  
mfc90d.dll!CWinApp::OpenDocumentFile(const char * lpszFileName=0x007783e8)  
myapp.exe!CServerApp::InitInstance()  
mfc90d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * ...            
    myapp.exe!__tmainCRTStartup()  Line 574 + 0x35 bytes    C
myapp.exe!WinMainCRTStartup()  Line 399 C
kernel32.dll!762033aa()     
ntdll.dll!77369ef2()    
ntdll.dll!77369ec5()    
myapp.exe!std::_Tree<std::_Tmap_traits<int,CDevice ..........

Questions:

1. I'm a bit mystified about how something like std::_Tree<...>::_Copy can be executing so many layers of stuff FOUR entire call layers layers above myapp.exe!WinMainCRTStartup . Should I suspect the callstack above of being incorrect?

2. What's an std::_Tree<...> mess like the above there for and why is it invoking CObject:IsKindOf ? My code uses the STL like this: std::map<int, CDevice*> .
   My guess is that if I removed all references to std::map<int, CDevice*> then the above std::_Tree internal implementation code would go away.

3. Running this far before WinMainCRTStartup suggests to me that this code is actually run when the mfc90d.dll loads. Is that probably so? Is there anything I can do in VC++2008 debugger to get a clearer view of "when is this code running?"

4. It's unreasonable to ask for someone to guess for me how on earth crashes can occur this early in my application's lifetime. I am interested in how you debug such problems though, so if any of this rings a bell for you, I'd appreciate your thoughts and ideas, but it's too much to ask anybody to guess what's really going on. Let's just say it's random heap corruption, somehow. But if you have tips on the order of "switch from using MFC in a dll to statically linking MFC", I'd like to hear those.

Answer 1

Anything below ntdll.DLL is a red herring, in my experience. Your std map did not call code in ntdll which called win main. The debugger is interpreting nonsense and trying to makes sense of it, and some semi random binary data had an address that lined up with one of your functions. Pretend it is not there.