Visual Studio 2008 STATUS_STACK_BUFFER_OVERRUN

[minime]

I've written some win32 (not managed) code which appears to have an intermittent error in it, however I am unable to track down where.
Whenever I run the program in Debug, when it gets to the error point, the program simply disappears, rather than returning an error, the only hint is a STATUS_STACK_BUFFER_OVERRUN encountered in the output window.
Is there any way to get VS to break on the line where the error occurs or a way to catch the exception, at present a standard catch statement doesnt seem to do it.

[coder777]

Determine the place where it happens and break before it happens.

[minime]

Thanks for the reply.
My problem is that I cannot find where the program errors. The program just quietly closes rather than visual studio coming up with the usual error occurred at line x. Also the program runs through routines tens of thousands of times before crashing steping through seem almost impossible. I need a way to find where the error is.

[coder777]

I'd think of 3 reasons for that behavior

1. uninitialzed variable
2. an array is too small
3. Too deep (unintended?) recursion

Is there any way to get VS to break on the line where the error occurs or a way to catch the exception, at present a standard catch statement doesnt seem to do it.

There's a catch(...), but that wouldn't help because if the stack is corrupt you can't do anything anymore.

One approach might be that you write out states (of variables) to a file (not to the standard output since that has a limited capacity!) always with flush. That might give you an idea what's going on.

[minime]

Thanks for the help, just a few questions.

Doesn't behavior 1 usually invoke a VS error?

I have put a catch(...) round the whole function and this doesn't catch it, would it be worth putting one round each sub function to see if i can narrow it down to a function? or would this still not catch it?

I have a feeling number 2 is responsible as I have had problems with this previously, however thought I'd patched them all.

[z05DSL3A]

STATUS_STACK_BUFFER_OVERRUN is a /GS exception. They are thrown when Windows detects 'tampering' of a security cookie protecting a return address. It is probable that you are writing something past the end of a buffer, or writing something to a pointer that is pointing to the wrong place. However it is also possible that you have some dodgy memory or otherwise faulty hardware that is tripping validation code.

One thing that you could try is to disable the /GS switch (project properties, look for C/C++ -> Code Generation -> Buffer Security Check) and recompile. Running the code again may well cause an error that you can trap and trace. I think /GS is designed not to give you any info for security reasons.

Another thing you could do is run the code as is on a different PC and see if that fails, this may point to a hardware problem if it doesn't.

[minime]

Thanks for the help.
Hardware shouldnt be an issue, this program works the same way on some elses computer and crashes on theirs as well. This was originally how the error came to light. I've just recompiled without the GS and started it again, hopefully should know by tomorrow morning (Takes a while to run)

[coder777]

Doesn't behavior 1 usually invoke a VS error?

No why? It's legal to leave variables uninitialzed

I have put a catch(...) round the whole function and this doesn't catch it, would it be worth putting one round each sub function to see if i can narrow it down to a function? or would this still not catch it?

The exception handling isn't reliable. The throw() instruction must know where the appropriate catch() resides. That's not always possible.

The addresses where to return are placed on the stack. When the stack is corrupt the function won't return to where it's supposed to be. Afterwards nothing make sense anymore.
I think there's no other way than to find out when it's going crazy (e.g. when a function doesn't return) and what the circumstance is

[z05DSL3A]

You can also use WinDbg, IIRC when it traps, use !analyze -v will give you info about the cookie that was overwritten and the buffer that was overrun.

Google WinDbg for instructions on use.

[minime]

Thanks for all the help guys. It appears the error was due to a buffer being to small as I changed all my remaining fixed length character records to char* and dynamically set them to the correct length each time and it appears to have fixed the problem.