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.

Enable Guard Bytes

Add LVGuardBytes=check to LabVIEW's INI file. This will cause it to put a known byte sequence before and after every allocation. It will then crash and generate a dump file 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.

Use Alternate Memory Manager

Add LV_USE_MALLOC=1 to LabVIEW's command line. This will cause it 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.

The command to be used with LabVIEW 64-bit is

"C:\Program Files\National Instruments\LabVIEW <YYYY>\LabVIEW.exe" -- LV_USE_MALLOC=1

and for LabVIEW 32-bit

"C:\Program Files (x86)\National Instruments\LabVIEW <YYYY>\LabVIEW.exe" -- LV_USE_MALLOC=1

where <YYYY> is the year of your current LabVIEW.