Is it possible to directly identify faulting code that overwrote the whole stack?

Question

Very simply put, if a C++ program executes the following function (say, on Windows 7, compiled with any VS version), then crashes subsequently and you attach a debugger with WER, or have WER generate a crash dump and later analyze this crash dump.

Is it possible from the information in the dump, to directly infer that this function was executed, that is, find traces pertaining to the thread that executed it that this function was executed.

Or are all execution traces gone when I corrupt the whole stack?

void bye_bye_stack() {
  int local = 42;
  int* stackaddr = &local;
  while(time(NULL) != NULL) { // prevent optimizations via call to time()
    ++stackaddr; // stack grows towards smaller addresses, so increasing the pointer will point to info we already put on the stack
    *stackaddr = local; // destroy stack content
    // program will (likely) crash here once we reach a read-only page
  }
}

Answer 1

In general, by destroying the stack the way you are doing, you will destroy the 'callstack', meaning that information about the previously called routines will be be gone. However, if you trigger an access violation / segmentation fault from within this routine, the instruction pointer where this happened will be stored, pointing to this routine.

However, If the stack is corrupted and you return from this routine, it will be very hard, if not impossible, to figure out what happened.

If you are trying to figure out what happened, I suggest using a debugging tool to find out where the stack gets 'smashed'. If your intention is to destroy evidence of execution, make sure you 'jump' or 'return' from this routine, without triggering an exception.

Answer 2

It's not a direct reply to your question.

However when I was experiencing stack being overwritten, I used to launch the utility gflags that would immediatly asserts when starting overwriting the stack.

Gflags is provided by Microsoft.

Answer 3

It really depends. Backraces as provided in crash dump directly rely on the information stored in the stack. This usually means that you CANNOT trust backtrace when you suspect stack corruption.

The function provided by you will very likely corrupt WHOLE stack and then cause exception when you exceed segment limits or reach memory which is not available to a process. At this time there will be nothing in the stack to indicate the suspect.