Debugging: Run-Time Check Failure #2 - Stack around the variable 'LoggerThread' was corrupted.

Question

I am getting:
Run-Time Check Failure #2 - Stack around the variable 'LoggerThread' was corrupted.
I have searched as much as I can for a description of how to diagnose, but I have not found anything. I don't know how to determine the specific address that is being corrupted. If I knew that, then I could of course set a breakpoint on the condition of that changing.
I have found many answers about other instances of this error, but nothing that descibes how to diagnose this problem. All other problems were simple enough that the problem could be determined by looking at the code. I have looked at my code extensively and I don't see a problem. One of the previous answers I have found is Error: Stack corruption around the variable 'tm' but the current version of the program uses only default alignment.
This particular problem is a symptom of a problem that has had various other symptoms, most of which would be more difficult to diagnose. Therefore the problem is probably more subtle than most. I initially encountered the problem in a DLL project, but I wrote a console program to use and test the relevant code. It is the console version that I am debugging.

Answer 1

 Sam Hobbs wrote:
 Holger Grund wrote:
Hey, these data breakpoints are really not that hard to use ;-)
Actually they are useless for me when I use my own system, which is only 350 MHz. On that system, even very simple programs run noticeably slow and any meaningful debugging is impossible. The problem I am encountering I am developing and debugging using a fast system, so the performance is not likely to be a probem, but that has been a problem for me in the past.
You probably haven't set the breakpoints in the correct way (again you should calculate the address yourself and leave the context empty so that the hardware debug breakpoint registers can be used).
 Sam Hobbs wrote:
One of us does not understand. First, I must correct what I said before; the stack is used in reverse of what I was thinking. I knew that but I forgot. In other words, for each item local appearing in a function, the addresses decrease. The processor's stack pointer register is decreased for each item put into it, which makes sense, because then the processor knows there is a problem when the register gets to zero or less.
Yes, I certainly understand that the error message is referring to memory before and after LoggerThread.
There is an important difference between stack memory before a function's allocations and after.
So for example if we have:
Code Snippet
void Level3(int a) {
 char Local[4];
std::cout << "In Level3 Local is at " << &Local << '\n';
void Level2(int a) {
 char Local[4];
std::cout << "In Level2 Local is at " << &Local << '\n';
Level3(3);
void Level1(int a) {
 char Local[4];
std::cout << "In Level1 Local is at " << &Local << '\n';
Level2(2);
int main(int argc, char* argv[]) {
 (void)argc, argv;
 char Local[4]="321";
 unsigned *pStack;
_asm {mov pStack, esp}
std::cout << "The stack is at " << pStack << '\n';
std::cout << "In main Local is at " << &Local << '\n';
Level1(1);
return 0;
Then the ouput I get is:
The stack is at 0012FF1C
In main Local is at 0012FF6C
In Level1 Local is at 0012FF0C
In Level2 Local is at 0012FEB0
In Level3 Local is at 0012FE54
Note that the addresses decrease. If I create a breakpoint using "{main,,} *(Local-256)" for 256 elements, then that breakpoint breaks constantly due to normal use of the stack. That makes debugging more difficult; are you aware of that problem?
Unsurprisingly the debugger will watch for modifications of 256 bytes if you tell it to do so. But I don't see why you would want to do it? It is obvious that this extends into callee stack space. There are only two bytes that you should be interested in: the one before the clobbered local and the one after. Of course, during its lifetime its allocated address will never change. And in debug stack frames its memory location is never shared with any other code. Any modification to it indicates a programming error.
Also, do note that scoped data breakpoints have had some performance problems. Again, if you care about performance calculate the address manually and set a data breakpoint without a C++ scope and make sure you don't exceed the number of available hardware watchpoint registers (IIRC there are 4 HW breakpoint registers which can watch 1,2 or 4 bytes at a given (aligned?) address). With HW watchpoints you shouldn't see any performance degradation.
-hg