0xcdcdcdcd - Created but not initialised
0xdddddddd - Deleted
0xfeeefeee - Freed memory set by NT's heap manager
0xcccccccc - Uninitialized locals in VC6 when you compile w/ /GZ
0xabababab - Memory following a block allocated by LocalAlloc()
0xfdfdfdfd - reading memory either before the start of a memory block or past the end of a memory block.
0xbdbdbdbd - reading memory before the start of a memory block
0xdeadbeef - reading memory that has been deallocated
0xbaadf00d - reading memory that has been allocated by HeapAlloc()
0xcccccccc - initialise memory in data that is on the stack.
Unusual memory bit patterns
Software development is an intellectual challenge. Sometimes the process is interrupted by software failures and/or crashes. A lot of the time the reason for the failure is self evident and easily fixable. However the reason for some crashes is less obvious and often the only clue is an unusual bit pattern that is typically present each time the crash happens. This article will describe some of the common bit patterns that have been used in Windows C/C++ software.
All of these bit patterns apply for the Microsoft C/C++ compiler that ships with Visual Studio (6.0 through 2010) and any compatible compilers (such as the Intel compiler). These bit patterns are found in debug builds. Release builds do not use special bit patterns.
These bit patterns evolve and change as the C runtime internals change from managing memory themselves to handing that management over to the Win32 heap family functions HeapAlloc(), etc.
Some of the allocators appear to know if they are running with a debugger present and change their behaviour so that with a debugger present you will see the bit patterns, and without the debugger present you will not see the bit patterns. HeapAlloc(), LocalAlloc(), GlobalAlloc() and CoTaskMemAlloc() both exhibit this behaviour.
0xcccccccc
The 0xcccccccc bit pattern is used to initialise memory in data that is on the stack.
void uninitFunc_Var() { int r; // here, r has the value 0xcccccccc ... } Also, consider this C++ class.
class testClass { public: testClass(); DWORD getValue1(); DWORD getValue2(); private: DWORD value1; DWORD value2; }; testClass::testClass() { value1 = 0x12345678; // whoops!, forgot to initialise "value2" } DWORD testClass::getValue1() { return value1; } DWORD testClass::getValue2() { return value2; } When an object of type testClass is created on the stack, its data member "value2" is not initialised. However the debug C runtime initialised the stack contents to 0xcccccccc when the stack frame was created. Thus if the object is used, its data member "value2" will have a value 0xcccccccc, and "value1" will have a value of 0x12345678.
void uninitFunc_Object() { testClass tc; // here, tc.value1 has the value 0x12345678 // here, tc.value2 has the value 0xcccccccc because it was erroneously not initialised in the constructor ... } If you are seeing the 0xcccccccc bit pattern it means that you are reading memory that is on the current thread stack that has not been initialised.
0xbaadf00d
The 0xbaadf00d bit pattern is the bit pattern for memory allocated with HeapAlloc(), LocalAlloc(LMEM_FIXED), GlobalAlloc(GMEM_FIXED).
If you are seeing the 0xbaadf00d bit pattern it means that you are reading memory that has been allocated by HeapAlloc() (or reallocated by HeapReAlloc()) and which has not been initialised by the caller of HeapAlloc (or HeapReAlloc, LocalAlloc, GlobalAlloc).
0xdeadbeef
The 0xdeadbeef bit pattern is the bit pattern for memory deallocated using HeapFree(), LocalFree(), GlobalFree().
If you are seeing the 0xdeadbeef bit pattern it means that you are reading memory that has been deallocated by HeapFree(), LocalFree() or GlobalFree().
0xabababab
The 0xabababab bit pattern is the bit pattern for the guard block after memory allocated using HeapAlloc(), LocalAlloc(LMEM_FIXED), GlobalAlloc(GMEM_FIXED) or CoTaskMemAlloc().
If you are seeing the 0xabababab bit pattern it means that you are reading memory after a memory block that has been allocated by HeapAlloc(), LocalAlloc(LMEM_FIXED), GlobalAlloc(GMEM_FIXED) or CoTaskMemAlloc().
0xbdbdbdbd
The 0xbdbdbdbd bit pattern is the guard pattern around memory allocations allocated with the "aligned" allocators.
Memory allocated with malloc(), realloc(), new and new [] are provided with a guard block before and after the memory allocation. When this happens with an aligned memory allocator, the bit pattern used in the guard block is 0xbdbdbdbd.
If you are seeing the 0xbdbdbdbd bit pattern it means that you are reading memory before the start of a memory block created by an aligned allocation.
0xfdfdfdfd
The 0xfdfdfdfd bit pattern is the guard pattern around memory allocations allocated with the "non-aligned" (default) allocators.
Memory allocated with malloc(), realloc(), new and new [] are provided with a guard block before and after the memory allocation. When this happens with an non-aligned (default) memory allocator, the bit pattern used in the guard block is 0xfdfdfdfd.
If you are seeing the 0xfdfdfdfd bit pattern it means that you are reading memory either before the start of a memory block or past the end of a memory block. In either case the memory has been allocated by malloc(), realloc() or new.
0xcdcdcdcd
The 0xcdcdcdcd bit pattern indicates that this memory has been initialised by the memory allocator (malloc() or new) but has not been initialised by your software (object constructor or local code).
If you are seeing the 0xcdcdcdcd bit pattern it means that you are reading memory that has been allocated by malloc(), realloc() or new, but which has not been initialised.
0xdddddddd
The 0xdddddddd bit pattern indicates that this memory is part of a deallocated memory allocation (free() or delete).
If you are seeing the 0xdddddddd bit pattern it means that you are reading memory that has been deallocated by free() or delete.
0xfeeefeee
The 0xfeeefeee bit pattern indicates that this memory is part of a deallocated memory allocation (free() or delete).
If you are seeing the 0xfeeefeee bit pattern it means that you are reading memory that has been deallocated by free() or delete.