The Microsoft C runtime debug heap manager tracks/checks/reports a subset of the memory usage that memory error analysis of Intel Parallel Inspector tracks/checks/reports. 

Using both of these technologies at the same time has the following implications...

• Binaries under analysis of Inspector may be interrupted by dialogue boxes
  • Press the "ignore" button- execution will continue (recommended action) - note: you may have to press "ignore" multiple times - as by default this dialogue box will appear every so many instances for each unique error detected.
  • Do not press the "abort" button - as that will exit the application before Intel Parallel Inspector can give you a list of all memory errors, and Intel Parallel Inspector may report false positives as your application exited prematurely.
  • Do not press the “retry” button in the dialog box, else - the debugger will open and point you to assembly code that was "generated" as a result of running your application under the  Inspector analysis engine rather than the assembly of your application (not recommended)
• The same issue may be reported by both technologies.
• Performance will suffer as both technologies are tracking and checking memory usage

You may want to turn off the Debug Heap Manager provided by the Microsoft C runtime library.

There is only one way to "turn off" the debug heap manager... and that is:

•   Use the Release/Base version of the Microsoft C runtime library by compiling with either /MD or /MT

In the ideal situation, it is recommended that you use /Od with memory error analysis in Intel Parallel Inspector with the /MD or /MT runtime library selections. By default a "debug" configuration in Visual Studio will select /MDd or /MTd settings rather than the /MD or /MT settings. You would need to check these settings for each project in your solution.  Note: It can be difficult to accomplish this on large projects - as it will be difficult to have the same runtime library used in your entire application (all dll(s), lib(s), etc).

Another way, to work around this problem - is to tell the "debug" version of the heap manager to disable heap checking and reporting (tracking still occurs with this method).  This can be done using the _CrtSetDbgFlag api.  An example follows showing a code snippet which turns these features off.

#include <crtdbg.h>

main() {

int oriDbgFlag, newDbgFlag;

oriDbgFlag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);

newDbgFlag &= ~_CRTDBG_ALLOC_MEM_DF; //Turn this off (by default it is on)

newDbgFlag |= _CRTDBG_CHECK_ALWAYS_DF;  //Turn this on (by default it is off)

newDbgFlag &= ~_CRTDBG_CHECK_CRT_DF;  //Not needed as this is default

newDbgFlag &= ~_CRTDBG_DELAY_FREE_MEM_DF; //Not needed as this is default

newDbgFlag &= ~_CRTDBG_LEAK_CHECK_DF; //Not needed as this is default

newDbgFlag = (newDbgFlag & 0x0000FFFF) | _CRTDBG_CHECK_DEFAULT_DF; //Not needed as this is default

newDbgFlag = _CrtSetDbgFlag(newDbgFlag);

//...

For more information look for _CrtSetDbgFlag at MSDN.

Potential dialogue boxes/messages that the debug heap manager of the Microsoft C runtime library may produce, which can be suppressed using the techniques above (when under analysis of Intel Parallel Inspector):

Client hook allocation failure at file

Client hook allocation failure %hs line

Invalid allocation size:

Error: memory allocation: bad memory block type.

Client hook re-allocation failure at file %hs line.

Client hook re-allocation failure Or Error: memory allocation: bad memory block type.

Error: memory allocation: bad memory block type. The Block at 0x%p was allocated by aligned routines, use _aligned_realloc(). The Block at 0x%p was allocated by aligned routines, use _aligned_free()

Client hook free failure. HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p. CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

_heapchk fails with _HEAPBADBEGIN.

_heapchk fails with _HEAPBADNODE.

_heapchk fails with _HEAPBADEND.

_heapchk fails with _HEAPBADPTR.

_heapchk fails with unknown return value!

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

%hs located at 0x%p is %Iu bytes long.

Bad memory block found at 0x%p.

Detected memory leaks!

Damage before 0x%p which was allocated by aligned routine