What are the debug memory fill patterns in Visual Studio C++ and Windows?

Question

In Visual Studio, we've all had "baadf00d", have seen seen "CC" and "CD" when inspecting variables in the debugger in C++ during run-time.

From what I understand, "CC" is in DEBUG mode only to indicate when a memory has been new() or alloc() and unitilialized. While "CD" represents delete'd or free'd memory. I've only seen "baadf00d" in RELEASE build (but I may be wrong).

Once in a while, we get into a situation of tacking memory leaks, buffer overflows, etc and these kind of information comes in handy.

Would somebody be kind enough to point out when and in what modes the memory are set to recognizable byte patterns for debugging purpose?

Answer 1

There's actually quite a bit of useful information added to debug allocations. This table is more complete:

http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

Address	Offset	After HeapAlloc()	After malloc()	During free()	After HeapFree()	Comments
0x00320FD8	-40	0x01090009	0x01090009	0x01090009	0x0109005A	Win32 heap info
0x00320FDC	-36	0x01090009	0x00180700	0x01090009	0x00180400	Win32 heap info
0x00320FE0	-32	0xBAADF00D	0x00320798	0xDDDDDDDD	0x00320448	Ptr to next CRT heap block (allocated earlier in time)
0x00320FE4	-28	0xBAADF00D	0x00000000	0xDDDDDDDD	0x00320448	Ptr to prev CRT heap block (allocated later in time)
0x00320FE8	-24	0xBAADF00D	0x00000000	0xDDDDDDDD	0xFEEEFEEE	Filename of malloc() call
0x00320FEC	-20	0xBAADF00D	0x00000000	0xDDDDDDDD	0xFEEEFEEE	Line number of malloc() call
0x00320FF0	-16	0xBAADF00D	0x00000008	0xDDDDDDDD	0xFEEEFEEE	Number of bytes to malloc()
0x00320FF4	-12	0xBAADF00D	0x00000001	0xDDDDDDDD	0xFEEEFEEE	Type (0=Freed, 1=Normal, 2=CRT use, etc)
0x00320FF8	-8	0xBAADF00D	0x00000031	0xDDDDDDDD	0xFEEEFEEE	Request #, increases from 0
0x00320FFC	-4	0xBAADF00D	0xFDFDFDFD	0xDDDDDDDD	0xFEEEFEEE	No mans land
0x00321000	+0	0xBAADF00D	0xCDCDCDCD	0xDDDDDDDD	0xFEEEFEEE	The 8 bytes you wanted
0x00321004	+4	0xBAADF00D	0xCDCDCDCD	0xDDDDDDDD	0xFEEEFEEE	The 8 bytes you wanted
0x00321008	+8	0xBAADF00D	0xFDFDFDFD	0xDDDDDDDD	0xFEEEFEEE	No mans land
0x0032100C	+12	0xBAADF00D	0xBAADF00D	0xDDDDDDDD	0xFEEEFEEE	Win32 heap allocations are rounded up to 16 bytes
0x00321010	+16	0xABABABAB	0xABABABAB	0xABABABAB	0xFEEEFEEE	Win32 heap bookkeeping
0x00321014	+20	0xABABABAB	0xABABABAB	0xABABABAB	0xFEEEFEEE	Win32 heap bookkeeping
0x00321018	+24	0x00000010	0x00000010	0x00000010	0xFEEEFEEE	Win32 heap bookkeeping
0x0032101C	+28	0x00000000	0x00000000	0x00000000	0xFEEEFEEE	Win32 heap bookkeeping
0x00321020	+32	0x00090051	0x00090051	0x00090051	0xFEEEFEEE	Win32 heap bookkeeping
0x00321024	+36	0xFEEE0400	0xFEEE0400	0xFEEE0400	0xFEEEFEEE	Win32 heap bookkeeping
0x00321028	+40	0x00320400	0x00320400	0x00320400	0xFEEEFEEE	Win32 heap bookkeeping
0x0032102C	+44	0x00320400	0x00320400	0x00320400	0xFEEEFEEE	Win32 heap bookkeeping

Answer 2

Regarding 0xCC and 0xCD in particular, these are relics from the Intel 8088/8086 processor instruction set back in the 1980s. 0xCC is a special case of the software interrupt opcode INT 0xCD. The special single-byte version 0xCC allows a program to generate interrupt 3.

Although software interrupt numbers are, in principle, arbitrary, INT 3 was traditionally used for the debugger break or breakpoint function, a convention which remains to this day. Whenever a debugger is launched, it installs an interrupt handler for INT 3 such that when that opcode is executed the debugger will be triggered. Typically it will pause the currently running programming and show an interactive prompt.

Normally, the x86 INT opcode takes two bytes: 0xCD followed by the desired interrupt number from 0-255. So although you could therefore issue 0xCD 0x03 for INT 3, Intel decided to add a special version--0xCC with no additional byte--because an opcode must be only one byte in order to function as a reliable 'fill byte' for unused memory.

The point here is to allow for graceful recovery if the processor mistakenly jumps into memory that does not contain any intended instructions. Multi-byte instructions aren't suited this purpose since an erroneous jump could land at any possible byte offset where it would have to continue with a properly formed instruction stream.

Obviously, one-byte opcodes work trivially for this, but there can also be quirky exceptions: for example, considering the fill sequence 0xCDCDCDCD (also mentioned on this page), we can see that it's fairly reliable since no matter where the instruction pointer lands (except perhaps the last filled byte), the CPU can resume executing a valid two-byte x86 instruction CD CD, in this case for generating software interrupt 205 (0xCD).

Weirder still, whereas CD CC CD CC is 100% interpretable--giving either INT 3 or INT 204--the sequence CC CD CC CD is less reliable, only 75% as shown, but generally 99.99% when repeated as an int-sized memory filler.

_{Macro Assembler Reference, 1987}

Answer 3

This link has more information:

https://en.wikipedia.org/wiki/Magic_number_(programming)#Debug_values

* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDDDDDDDD : Used by Microsoft's C++ debugging heap to mark freed heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory