Microsoft has put quite a lot of memory leak detection helpers in Windows NT. They have not done a good job of advertising it. This document describes some of the things I've deciphered while debugging code.
Many times while debugging programs, I will come across memory that is filled with "funny" values. After some playing around (i.e. hacking) with the Win32 API, I was able to figure out what they meant. Some of these values have been documented in places but never all together. The values for the tags presented here are hexadecimal because that's the way Developer's Studio presents them in the memory window.
Value | Meaning |
0xAB | Memory following a block allocated by LocalAlloc(). |
0xBAADF00D | Bad Food. Get it? This is memory allocated via LocalAlloc( LMEM_FIXED, ... ). It is memory that has been allocated but not yet written to. |
0xFEEE | This seems to be memory that has been dedicated to a heap but not yet allocated by HeapAlloc() or LocalAlloc(). |
0xCC | Microsoft Visual C++ compiled code with the /GZ is automatically initialized the uninitialized variable with this value. |
0xCD | Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that has been allocated (by malloc() or new) but never written to the application. |
0xDD | Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that has been freed (by free() or delete) by the application. It is how you can detect writing to memory that has already been freed. For example, if you look at an allocated memory structure (or C++ class) and most of the members contain this tag value, you are probably writing to a structure that has been freed. |
0xFD | Microsoft Visual C++ compiled code with memory leak detection turned on. Usually, DEBUG_NEW was defined. Memory with this tag signifies memory that is in "no-mans-land." These are bytes just before and just after an allocated block. They are used to detect array-out-of-bounds errors. This is great for detecting off-by-one errors. |
http://www.samblackburn.com/wfc/technotes/WTN006.htm
http://en.wikipedia.org/wiki/Magic_number_(programming)
Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted, and to make it obvious when values taken from uninitialized memory are being used.
Since it is unlikely that any given 32-bit integer would take this specific value, the appearance of such a number in a debugger or memory dump can indicate common errors such as buffer overflows, or uninitialized variables.
Memory is usually viewed in hexadecimal, so common values used are often repeated digits or hexspeak.
Famous and common examples include:
Note that most of these are each 32 bits long — the word size of most modern computers.
The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:
Since they were often used to mark areas of memory that were essentially empty, some of these terms came to be used in phrases meaning "gone, aborted, flushed from memory"; e.g. "Your program is DEADBEEF".
Pietr Brandeh?rst's ZUG programming language initialized memory to either 0x0000, 0xDEAD or 0xFFFF in development environment and to 0x0000 in the live environment, on the basis that uninitialised variables should be encouraged to misbehave under development to trap them, but encouraged to behave in a live environment to reduce errors
评论