Whenever a pointer that does not refer to a valid malloc region is passed to free() or other malloc-related routines, Dr. Memory reports an "invalid heap argument" error. Here the problem is immediately apparent as 0x00001234 is not a valid heap address at all:

Error #4: INVALID HEAP ARGUMENT: free 0x00001234
Elapsed time = 0:00:00.180 in thread 21848
# 0 malloc!main                                     [/home/bruening/drmemory/git/src/tests/malloc.c:164]
# 1 libc.so.6!__libc_start_main                     [/build/buildd/eglibc-2.11.1/csu/libc-start.c:226]
# 2 malloc!_start

Another common example of an invalid argument is a mismatch in calling free() versus operator delete versus operator delete[]. This will be reported as:

Error #4: INVALID HEAP ARGUMENT: allocated with operator new[], freed with operator delete
# 0 test_mismatch                   [cs2bug.cpp:122]
# 1 main                            [cs2bug.cpp:139]
Note: memory was allocated here:
Note: # 0 test_mismatch                   [cs2bug.cpp:121]
Note: # 1 main                            [cs2bug.cpp:139]

For code compiled with Visual Studio, detecting such mismatches relies on having debug information. Certain Visual Studio optimizations can also preclude the ability to detect mismatches when using a static C library, so using either a Debug build of your application or linking to the dynamic C library may be required to identify these bugs. Also note that if leak counting is completely disabled via -no-count_leaks then the callstack of the allocation will not be reported on a mismatch.

On Windows, mismatches between the C library allocation layer (malloc() and free()) and the Windows API layer (HeapAlloc() and HeapFree()) are reported by Dr. Memory if the application or one of its libraries uses the dynamic C library. These mismatches are not reported when using a static C library as one of malloc() or free() might be inlined while the other is not, making mismatch detection intractable for Dr. Memory.