Tools to Debug Memory Corruptions in LabVIEW

Often we will encounter memory corruption while using LabVIEW and the cause to this is somehow untraceable without additional tool. 

In case that memory corruption do happen and I would like to debug it, I can use the tools mentioned in this KB to help me to accelerate root cause identification.

There are 2 options in LabVIEW that can help in this situation. They can be used together or independently.

1. Enable guard bytes. Add LVGuardBytes=check to LV's ini file. This will cause LV to put a known byte sequence before and after every allocation. It will then complain if those sequences are overwritten. This checking happens when allocations are resized or disposed, so it is possible that you'll crash before overwrites are detected.

2. Use alternate memory manager. Add LV_USE_MALLOC=1 to LV's command line. This will cause LV to load a different version of our mgcore dll that contains our memory manager (multiple versions are included in the shipping resource directory). The default is smartheap but this option uses the C malloc/free instead. Since these memory managers use different data structures and allocation schemes, switching can impact how memory corruptions expose themselves and may provide more context to determine where the corruption happened.