>If you are getting a buffer overrun in 'list memory', chances are that the memory was already corrupted. Then working with (or in) memory that is corrupted may expose the earlier corruption by giving a buffer overrun (or error c0000005)

That makes sense, especially given that I got the overrun on a test with a more complicated object hierarchy sitting in memory, but not on the same bug with a simpler one.

>
>Some thoughts - possibilities - may be worth trying
>
>(1) instead of (which tries to expand the string in place)
>

>cStackInfo = m.cStackInfo + ;
>

>use
>

>cStackInfo = '' + m.cStackInfo + ;
>

>
>
>(2) Is it possible to write the stacktrace using low level IO (fwrite) instead of appending to a variable which then gets written (list memory)

My instinct is that the problem isn't related to the other code in the error handler, but to what's already in memory when I get to the error handler.

This app operates on a complex hierarchy of objects involving lots of collections. There's a COM object referenced by the app object, and it points to another COM object that pokes stuff into the main object hierarchy (either directly or, more often, by calling methods of objects in that hierarchy).

>
>(3) Are you using a lot of chrtran() ?
>This one ( http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q221617 ) was supposed to be fixed in vfp6sp3 but I remember that my trouble in message#1251395 (may have been vfp6sp5) disappeared after I replaced most of my chrtran() with sys(15) and/or strtran()

Not sure I have CHRTRAN() in the app at all. Okay, looked. It's hardly used. More importantly, I don't think any of the places it's used would have been executed in my most recent tests.

Tamar