IDA Pro displays certain buffer or padding above (at lower addresses) local variables in stack frame view. For instance:

Example 1.
The following screen shot of stack frame view shows 12 bytes (included in the red box) buffer:

enter image description here

Example 2.
The following screen shot of a different stack frame view shows 12 bytes buffer again:

enter image description here

I understand that IDA marked it as db ?; undefined because it couldn't figure out how it was used. I also realize that IDA automatically calculates size of a stack frame by monitoring ESP. I would assume it might have something to do with non-volitile register save area. However, in Example 1 it clearly shows Saved regs: 0 and in Example 2 it shows Saved regs: 4. I am puzzled, and here go my questions:

Why does IDA Pro display certain buffer or padding above (at lower addresses) local variables in stack frame view? Is it a coincidence that both views show exactly 12 bytes buffer? Is it something particular to certain calling convention or complier?

  • 1
    The compiler might be adding stack padding for performance (memory alignment) or overflow prevention reasons, but those don't show up so nicely. Can you show the disassembled code of the function?
    – DCoder
    Commented Jun 19, 2013 at 5:10
  • 3
    Add the function prolog instructions.
    – Igor Skochinsky
    Commented Jun 19, 2013 at 8:22

3 Answers 3


IDA keeps track of the value of the stack pointer (ESP) throughout its static analysis of the entire function. The greatest negative value of ESP (relative to the beginning of the function) is used to determine the size of the stack frame.

As for why the stack frames you posted have "undefined" bytes at the top, it's because IDA couldn't automatically determine if or how those stack offsets were being used.

  • Thank you so much for your reply. I do realize everything you mentioned. However, it doesn't address my questions. I have clarified my questions. Hopefully it is a little more clear, and you could help me out with it.
    – PSS
    Commented Jun 19, 2013 at 3:20

Thank you all so much for your answers and comments. While reading your comments and preparing to update my question, I found the answer.

I must give credit to Igor Skochinsky, who asked me to provide functions' prolog instructions. Both functions use the cdecl calling convention. However, calling convention has nothing to do with this buffer. This is what the prolog looks like:

push    ebp
mov     ebp, esp
sub     esp, <size of local vars>
push    ebx
push    esi
push    edi

This buffer reflects three push instructions for registers EBX, ESI, EDI. These registers are categorized as Callee Saved Registers and this "buffer" is called Non-Volatile Register Save Area.

In accordance to x86 convention (it is also applicable to x64), registers are divided into Caller Saved Registers and Callee Saved Registers.

Caller saved registers are also known as volatile registers. Those are core CPU registers such as EAX, EDX, and ECX. A calling function (Caller) is responsible for saving volatile registers onto usually runtime stack before making a call.

Callee saved registers are known as non-volatile registers. Those are core CPU registers such as EBX, ESI, EDI, ESP, and EBP. It is assumed by convention, that values in those registers will be preserved by a callee function. In case any of the non-volatile registers are going to be used within a callee, the callee is responsible to save the registers onto runtime stack. In addition, the callee is responsible to restore those registers before returning to a caller function.

The way volatile and non-volatile registers used is rather compiler driven. The following paper x86 Assembly Guide describes Caller and Callee rules in more detail.


The screenshots shows that u are examining IDA's detailed stack view.

IDA gives a name to every byte that is accessed directly in the function, any other bytes remain undefined.

Calling convention ? Give us the prologue and the epilogue of this subroutine so we can see how the stack is allocated and cleaned.

So if this is a stack frame of a normal application written in high level language (not malware nor written in assembly by hand) and not calling convention specific then i think we can agree that the compiler allocated more stack space than this function needs for some reason.

I dont think it is a "must" to know why the compiler did this, but thats your choice.

  • Thank you for your input. I know what calling convention it is. I am not asking about it. What I would like to know is if this particular buffer related to certain calling convention? I am updating my question to clarify that.
    – PSS
    Commented Jun 19, 2013 at 13:31
  • @PSS I cant see my answer explaining what a calling convention is, but if you are kind enough to provide us with a prologue and an epilogue to this subroutine in order to figure out if this is about a calling convention or not, so we can help you.
    – nomilk
    Commented Jun 19, 2013 at 15:37
  • I have already provided the answer. Thank you for your input.
    – PSS
    Commented Jun 19, 2013 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.