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

The following table can help you decide which tool to use:

	Intel® Parallel Inspector	Intel® Thread Checker
Threading errors - Data races and Deadlocks	√	√
Does not require special build or source code	√	√
Memory errors	√
Easier to learn and reuse	√
Low overhead analysis	√
Improved scalable analysis without serializing the app	√
Windows* standalone		√
Linux* support		√
Licensing	Single User	Single User & Floating
Support	forum support premier support option	unlimited premier support & 1 year product updates

IA-32 Architecture refers to systems based on 32-bit processors generally compatible with the Intel Pentium® II processor, (for example, Intel® Pentium® 4 processor or Intel® Xeon® processor), or processors from other manufacturers supporting the same instruction set, running a 32-bit operating system.

Intel® 64 Architecture (formerly Intel® EM64T)refers to systems based on IA-32 architecture processors which have 64-bit architectural extensions, (for example, Intel® Core™2 processor family), running a 64-bit operating system such as Microsoft Windows Vista* x64 or a Linux* "x86_64" variant. If the system is running a 32-bit  operating system, then IA-32 architecture applies instead. Systems based on AMD* processors running a 64-bit operating system are also supported by Intel compilers for Intel® 64 architecture applications.

64-bit computing on Intel architecture requires a computer system with a processor, chipset, BIOS, operating system, device drivers and applications enabled for Intel® 64 architecture. Performance will vary depending on your hardware and software configurations. Consult with your system vendor for more information.

IA-64 Architecture refers to systems based on the Intel® Itanium® processor running a 64-bit operating system.