Run-Time Check Failure #2 in VS2005: Compiler bug?

I read some postings about run-time check failures in VS2003 which seem to
confirm that there were some bugs or at least problems in the previous
version. Does anyone know how much of that is true for VS2005?

A coworker managed to create code which when run shows the "Run-Time Check
Failure #2 - Stack around the variable ... was corrupted." message by simply
assigning a value to a pointer. Actually the message doesn't show up when
the value is assigned but when the instance of the class the pointer is a
property of goes out of scope. The code looks basically like this:

#include "B.h"
#include <string>

class A {
private:
    B<std::string> *b;
    B<std::string> *b2;
public:
    A() { b = (B<std::string>*)0x21212121; }
};

We can get rid of the error message by changing the constructor to:

A() { b = (B<std::string>*)0x21212121; b = (B<std::string>*)0xCCCCCCCC; }

I've been playing around with the code using different pointers. While there
is no problem with std::string* I get an access violation with B<char>*. I
can get rid of the access violation again by assigning 0xCCCCCCCC.

You might wonder what b2 does in class A. If I remove this pointer and b is
the last property in class A assigning 0xCCCCCCCC to b doesn't work any
more - the test application crashs then, too. It looks like that something
(?!) changes some bytes somewhere which triggers the run-time check failure
or crashs the whole thing.

Has anyone seen run-time check failures in VS2005 for rather inexplicable
reasons? Does anyone have an idea how I can track this down? Or can I safely
ignore it as it seems to be likely that it is a bug in VS2005?

As it might be relevant (at least I've seen these questions in earlier
postings about run-time check failures): The code is compiled with /Zi
(program database without edit-and-continue).

Thanks,
Boris

PS: The code above is for illustration purposes. The whole code is several
ten thousands of lines - unfortunately I can't provide a small test case
currently. :-/