How can the stack be broken at the very start of application

Question

The stack frame pointer (EBP) should always point to where the previous stack frame was right but why is that not the case in my application! That would indicate something is really wrong..hard to believe!

I created multiple simple demo applications where the stack pointer always points to the previous stack frame but I can't make sense of why this is not the case in this application and it is happening when my application is just starting up!

The following is my call stack

0:000> k
 # ChildEBP RetAddr  
00 0018fee4 6381d1cd acn!CAcnApp::InitInstance+0x41 [c:\acn-project\acn\acn.cpp @ 527]
01 0018fef4 00428575 MFC80U!AfxWinMain+0x48 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
02 0018ff88 765d336a acn!__tmainCRTStartup+0x150 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 589]
03 0018ff94 76f59902 kernel32!BaseThreadInitThunk+0xe
04 0018ffd4 76f598d5 ntdll!__RtlUserThreadStart+0x70
05 0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dc 0018fee4 
0018fee4  ffffffff 6381d1cd 00489498 00000001  .......c..H.....
0018fef4  00000000 00428575 00400000 00000000  ....u.B...@.....
0018ff04  01e53fd2 0000000a 87b8aee0 00000000  .?..............
0018ff14  00000000 7efde000 00000044 01e54012  .......~D....@..
0018ff24  01e53ff2 01e53fd4 00000000 00000000  .?...?..........
0018ff34  00000000 00000000 00000000 00000000  ................
0018ff44  00000000 00000000 00000000 00000000  ................
0018ff54  00000000 00000000 0018ff84 00428e5d  ............].B.
0:000> dc 0018fef4 
0018fef4  00000000 00428575 00400000 00000000  ....u.B...@.....
0018ff04  01e53fd2 0000000a 87b8aee0 00000000  .?..............
0018ff14  00000000 7efde000 00000044 01e54012  .......~D....@..
0018ff24  01e53ff2 01e53fd4 00000000 00000000  .?...?..........
0018ff34  00000000 00000000 00000000 00000000  ................
0018ff44  00000000 00000000 00000000 00000000  ................
0018ff54  00000000 00000000 0018ff84 00428e5d  ............].B.
0018ff64  01e53fd2 00000000 00000000 0018ff0c  .?..............
0:000> dc 0018ff88 
0018ff88  0018ff94 765d336a 7efde000 0018ffd4  ....j3]v...~....
0018ff98  76f59902 7efde000 7d7a657d 00000000  ...v...~}ez}....
0018ffa8  00000000 7efde000 00000000 00000000  .......~........
0018ffb8  00000000 0018ffa0 00000000 ffffffff  ................
0018ffc8  76f958c5 0b965c89 00000000 0018ffec  .X.v.\..........
0018ffd8  76f598d5 0042873d 7efde000 00000000  ...v=.B....~....
0018ffe8  00000000 00000000 00000000 0042873d  ............=.B.
0018fff8  7efde000 00000000 78746341 00000020  ...~....Actx ...

The control is in the first line of InitInstance() so it's like my application is drawing its first breath and the stack seems to be already corrupted? Well the app class constructor comes before this but I checked the call stack is in similar state there as well.

Notice the stack frame pointer (EFP) check for both 1st and 2nd frame fails but the stack is good beyond that.

My first question is that is there any explanation the call stack can be like this and this being Ok? In other words, can we say the call stack is definitely broken? The application does load and calls various dlls if that may play any part (don't know why it would though).

What could be the suspect in this case since the application has only barely started!?

Update (code)

Here is constructor which is very simple. And as for InitInstance(), that function is very long but my breakpoint is on first line so its code is never executed when call stack is like that.

CAcnApp::CAcnApp()
{
    m_bServMode = FALSE;
    m_bFactory = FALSE;
    m_bDownload = FALSE;
    m_pEngine = NULL;
    m_hWiztomMod = NULL;
    m_pServer = new CAcnServer;
}

Second update

I posted a follow up question to share extra information after further investigation and that does qualify as separate question due to differences.

Answer 1

BTW, global or file global objects are created before the main function is called.

If an object's constructor has problems, you could see any number of defects occurring before main is called.

Review your object's constructors. You should be able to set a breakpoint in the object's constructor.

Edit 1: Memory allocation in constructor
Having a global object that has dynamic memory allocation may cause problems. The object requires that the dynamic memory allocation is initialized before the object is constructed. Try commenting out the dynamic memory allocation and see if the issue goes away.

A workaround is to create an "initialize" method that can be called after the main entry point is reached. The initialize method would perform dynamic memory allocation.