Menu
Search
 
   
   
   
 
← Previous page
Next page →

Application Verifier break message

Probing free memory.

Probable cause

This stop is generated if Application Verifier detects an IsBadXXXPtr call for a memory allocation that is free. This is very bad because it is possible that, in some other cases, this memory was already reused for some other allocation. Since the current code path (kb) doesn't own that memory, it could end up corrupting someone else's memory, with disastrous effects.

Information displayed by Application Verifier

Parameter1 - Start address

Parameter2 - Memory block size

Parameter3 - Address of free memory page

Parameter4 - Not used

Description - Probing free memory

Additional information

Verifier stop code 0604.

To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up probing free memory. The address could be plain bogus (e.g. uninitialized pointer) or maybe already freed memory. If the memory was already freed by one of the VirtualFree or UnmapViewOfFile APIs, "!avrf -vs -a parameter3" will search for a log of stack traces of the code paths that allocated/freed that address and display these stack traces if they are available. This might show the stack trace that freed up this memory. More often, the memory is an already freed heap allocation. To check for that possibility, "!avrf -hp -a parameter3" will search for a log of stack traces of the code paths that allocated/freed that address from/to the heap and display these stack traces if they are available.

MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs:

  • In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested.

  • Dereferencing potentially invalid pointers can disable stack expansion in there threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information.

  • Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner.

Because of all these reasons, it is recommended to never use these APIs.