这边文章很久以前就看到。前不久又看到，温习并贴在这里。

When you compile a debug build of your program with Visual Studio and run it in debugger, you can see that the memory allocated or deallocated has funny values, such as 0xCDCDCDCD or 0xDDDDDDDD. This is the result of the work Microsoft has put in to detect memory corruption and leaks in the Win32 platform. In this article, I will explain how memory allocation/deallocation is done via new/delete or malloc/free.

First, I will explain what all these values that you see, like CD, DD, and so forth, mean.

Value
Name
Description0xCD
Clean MemoryAllocated memory via malloc or new but never written by the application.0xDDDead MemoryMemory that has been released with delete or free. It is used to detect writing through dangling pointers.0xFD
Fence Memory
Also known as "no mans land." This is used to wrap the allocated memory (like surrounding it with fences) and is used to detect indexing arrays out of bounds.0xAB
(Allocated Block?)
Memory allocated by LocalAlloc().0xBAADF00D
Bad FoodMemory allocated by LocalAlloc() with LMEM_FIXED, but not yet written to.0xCC
When the code is compiled with the /GZ option, uninitialized variables are automatically assigned to this value (at byte level).

If you take a look at DBGHEAP.C, you can see how some of these values are defined:

static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */ static unsigned char _bDeadLandFill = 0xDD; /* fill free objects with this */ static unsigned char _bCleanLandFill = 0xCD; /* fill new objects with this */ 

link:http://www.codeguru.com/cpp/w-p/win32/tutorials/article.php/c9535/#more