How you can break the stack at the very beginning of the application

The Stack Frame Pointer (EBP) should always point to where the previous stack was, but why is it not so in my application! That would mean that something is really wrong .. right to believe!

I've created some simple demo applications where the stack pointer always points to the previous frame stack, but I can't figure out why this is not the case in this application, and this happens when my application is just starting!

Below is the 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 on the first line InitInstance()

, so how does my application take its first breath and it seems like the stack is already corrupted? Well, the constructor of the application class comes before this, but I have verified that the call stack is also in a similar state.

Note that checking the stack frame pointer (EFP) is done on both the first and second frame, but the stack is good beyond that.

My first question is, is there any explanation that the call stack could be like this, which is good? In other words, is it safe to say that the call stack is definitely broken? The application loads and calls various DLLs if this can play any part (not sure why it would).

What could be a suspect in this case, since the application has just started ??

Update (code)

Here's a constructor that's very simple. And as for InitInstance()

, this function is very long, but my breakpoint is on the first line, so its code is never executed when the call stack is like this.

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 the following question to share more information after further investigation, and this may be treated as a separate question due to the differences.

+3


source to share


1 answer


By the way, global or global global objects are created before the function is called main

.

If the object's constructor has problems, you can see any number of defects that occurred before the call main

.

Review object constructors. You should be able to set a breakpoint in the constructor of the object.



Edit 1: Memory Allocation in Constructor
Having a dynamically allocated global object can cause problems. The object requires dynamic memory allocation to be initialized before the object is created. Try commenting out dynamic memory allocation and see if the problem goes away.

A workaround is to create an "initialize" method that can be called after the entry point is reached main

. The method initialize

will dynamically allocate memory.

+1


source







All Articles