What is 0xFEEEFEEE?

I'm seeing this value in an access violation that occurs when my program is trying to clean up after itself.  All of my "delete <some pointer>" statements are wrapped in an "if(<some pointer>)" block which I thought would prevent this kind of thing.  However, a certain pointer seems to be changing to 0xfeeefeee on me and, since that isn't NULL, my program (specifically the destructor of the class the pointer is a member of) tries to delete it and, to quote from The Crow, "Bang!  $%&*! I'm dead!"  Every delete statement in my code is followed by an assignment of that pointer to NULL so I'm not sure how it changes.  Since I see 0xfeeefeee every time, I don't think it's an overwrite.

I sent the wondrous Google out after my new nemesis and found a few links that explain it as a magic number of sorts that the MSVC debug memory manager uses to indicate certain things about a memory block.  Nothing goes into much detail however.  So I was hoping that someone here could explain 0xfeeefeee and its apparent friends 0xbaadfood, 0xcdcdcdcd, etc.

How/when do pointers get changed to these bogus addresses?  Should I check for these values along with NULL before I delete them or would that just be a band-aid because the appearance of this value indicates a misstep/inefficiency on my part that I should correct?
mastethomProject Technical LeadAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Well, one place I've seen this sort of thing happen is when the pointer pointed to a varable that went out of scope:

void DoBang()
    int* extrapointer = null;

    if (!extrapointer)
        int value = 20;
        extrapointer = &value;

    *extrapointer = 3; // BANG!

Of course, it usually isn't so obvious, unfortunately.  And there are other possible causes.
In the msdn-artice

Troubleshooting Common Problems with Applications: Debugging in the Real World

Mark Long
Microsoft Corporation
October 2000

you find:

Table 1. Potential patterns Pattern Description

0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mastethomProject Technical LeadAuthor Commented:
Thanks guys, I think what's happening with my code is that a destructor is getting called twice.  I'm not sure how yet but a TRACE statement inside shows this to be the case.  This is a Bad Thing and I hope solving it takes care of the problem.

Markus, that article helped the most, I think.  It didn't reference my magic number specifically but it said they were subject to change and I've found some more information on these as a whole.  I think you'll get the points and I'll get to the bookstore and see about that book the article mentions.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.