Unusual memory bit patterns

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.

What can you do to prevent the cause of these problems?

Depending on the nature of the problem, it may be trivial to identify why you have an uninitialised variable or why your pointer is pointing to deallocated memory. The rest of the time you can rely on a few helpful rules and the judicious use of some software tools.

• When you have a crash, try to identify the cause of the crash.
  • If you are in a debugger, the debugger may be able to show you variable names, thus you will be able to identify which variable is in error.
  
  
  • If you are in a debugger you can view the register window to see if a register has one of these special bit patterns.
  
  
  • If you have an exception report, you can view the crash address, the exception address and any registers to see if any of these special bit patterns are present.

  At the start of a C++ method, the "this" pointer is stored in the ECX register. If the ECX register contains one of these bit patterns you have a good indicator that a dangling pointer to a deleted object or an uninitialised pointer is being used. Note that depending on what the compiler does the ECX register may remain valid during the method or may take on other values and thus be unreliable as to whether it still represnts the "this" pointer.

  When a method or function returns, the return value is in the EAX register.

• Always initialise all data members in all your object constructors.


• Always initialise all data that is used that is not data members of class definitions.


• Always use the correct form of delete, even if you are working with intrinsic types. It is not unknown to change the type of a data member as software evolves. If you always use the correct form of delete, then a switch from (for example) "int" to a class type will not result in objects of the class type failing to be deleted.

   

  • If you allocate using new, deallocate with delete.
  • If you allocate using new [], deallocate with delete [].
  • If you allocate using malloc() or realloc(), deallocate with free().


• Always set pointers to NULL after dellocating the memory pointed to by the pointer.

  	delete [] accounts;
  	accounts = NULL;
   

  Do this in object destructors and anywhere else you deallocate memory. The reason you do this in object destructors is because in release code, the memory deallocator will not overwrite the contents of the deleted object. Thus if any erroneous code is still pointing to the deleted object, it will find a NULL pointer to accounts rather than a pointer to a deleted accounts object.



• In object destructors, even if you are not deleting any objects, but you have pointers to objects, set these to NULL as well. The reason is the same reason as above - defensive programming, minimise the likelihood things can fail.


• Always check pointers are non-NULL before using them. This goes hand in hand with setting pointers to NULL when you are finished using them.


• If possible, try to make one location in your software responsible for the management of a particular type of object. For example you may create a manager class that is responsible for creating, managing and destroying particular objects. If you then get a failure with a related object type, you can focus your attentions on the manager class, perhaps adding additional tracing code or analysing with a software tool.


• If your software is structured so that some class implementations are in certain DLLs and other DLLs rely on those class implementations (either by usage or by derivation/inheritance) then you need to consider the following issues.

  If you change the size of a class object then you will need to rebuild all other DLLs that use that object. In theory the Developer Studio build system should keep everything up to date. But Developer Studio can only work with the information you give it. If you have forgotten to add appropriate header files to a project the project will not consider changes to those header files. Typically we have found the simplest and easier solution is a full rebuild of any affected DLLs after a change in size of a class object.

  Such changes include:

  • Change of a method from normal to virtual or virtual to normal.
  • Addition or removal of a virtual method.
  • Addition or removal of a data member.
  • Change in type of an object that is a data member of the class (for example from int to double or from weeble to wobble).
  • Change in size of an object that is a data member of the class (for example data member of type testObject changes size).
  • Change of #pragma byte packing for some or all of the class definition.
  • Addition or removal of base classes which the class derives from.

  A good indicator that you have forgotten to do the above, is looking at the class object in the debugger and noticing that the fields all appear OK in one DLL, but when looked at from a function in a different DLL, the object fields appear to have different data. This is a sure sign that one or more DLLs have not been compiled with the same object definition.

I've tried all the above, what other options are there?

If all else fails, then you will probably need to turn to a software tool to analyse your memory usage and identify the cause of the deleted memory that the pointer is pointing to (has the memory been deleted too early? Or is the pointer being used in error after the memory was deleted?).

In that case you may want to consider a software tool like Memory Validator.