views:

420

answers:

1

I'm looking for common causes of Buffer Overflow errors under .NET.

I know that buffer overflow is impossible under managed .NET code. However this exception is still possible in the scope of .NET application.

Things I thought of -

  • Valid arguments to COM object calls
  • Valid arguments to PInvoke/Win32 calls

What is the best method of debugging buffer overrun errors?

+2  A: 

From the comments to the question:

So how do you guys go about debugging buffer overrun errors under .NET?

Most of the time, there is nothing to debug in the first place. By that I mean, of course of a bug exists and you need to fix it, but the bug isn't in your code. It's in an unmanaged library you're calling into that you can't change. The only thing you can do is not use that library in that way.

So that's one common cause: a bug in an unmanaged library.

This can also happen if you call an unmanaged library that doesn't have a bug, but the library expects you to explicitly tell it the size of the buffer and you give it the wrong number. This is a problem with your code that you need to fix. However, it rarely happens in .Net because finding the size of a buffer is usually as simple as checking the .Length property of a byte array.

Joel Coehoorn
Thanks Joel. How would you go about determining the library where the overflow occurs?
I don't rely much on unmanaged code in the first place. I know there is a school of thought that sees .Net as just a quick way to put a gui on top of the "real" code, but I feel that approach is misguided. So my answer is: it's easy to narrow it down because there's little unmanaged code to check.
Joel Coehoorn
So if I'm using a COM object, how can I tell which method call is the cause of the overflow?
Look at the stack trace
Joel Coehoorn