Re: SOLVED! Thanks for the help!

A gentleman on the MS STL team provided this clue, quoted:
"I have a new guess, though. If you're not experiencing version
mismatch, your program might be doing something wrong that it gets
away with in VC8 and VC9-with-SCL=0, but doesn't get away with in
VC9-with-SCL=1. The biggest example that I know of is related to the
"aux object" that I added. In VC8 and VC9-with-SCL=0, you can get
away with constructing a vector and then zeroing out the bytes of the
vector object. (Or, zeroing out memory and then treating it as a
vector without constructing it.) Doing so is completely
nonconformant, but vectors in these cases are represented with
pointer triples, and on our platforms, all-bits-zero pointers are
null. However, in VC9-with-SCL=1, vectors gain an additional data
member pointing to the "aux object". Stomping over the vector object
with zero bytes, or not constructing it in the first place, will
break the aux object and lead to runtime crashes. The symptoms of
this would be code in the STL attempting to access the aux object and
dereferencing a bogus pointer."
Lo and behold, our vector is a structure member, and we have a class
that publically inherits from the structure. During construction,
memset() is called over the structure, blasting it's contents
(including a couple of vector members of that structure) with zeroes!
The "aux" object is blasted. (I didn't write it! It's been lurking
in there forever.)
Using memset() to "initialize/zero" an already instanciated instance
is bad, but I guess it was never spotted because it didn't hurt
previous implemntations. Thanks to all of you for the time spent
commenting; every little clue led us closer to a solution. A few
days ago I didn't even know where to begin, or what SECURE_SCL even
was, or taht a vector<> was the source of the crash.