It turns out this is a bug with initialized, multidimensional arrays of structs or pointers. When a debugged program accesses members of such an array, the runtime protection compares the pointer address against the wrong pointer bookkeeping information. For example, when you're accessing stCatLimits[0][0][1].szLimitTxt, it's doing a little pointer arithmetic to calculate the address of the szLimitTxt field. It comes up with the correct address, but then checks that address against the legal memory range of stCatLimits[2][4][4] (instead of stCatLimits[0][0][1]). Because that pointer is well before the later struct's memory chunk, you get a "Out-of-bounds pointer (before start of memory block)" error. One other quirk is that the first element in the array is unaffected by the bug, which is why your first error occurs on element [0][0][1].
The next maintenance release will likely be the first chance we have to fix this bug. Until then, I can suggest a few workarounds to avoid this problem.
1. Set the Debugging Level (in the Build Options) to "No run-time checking". This requires no changes to code, but of course gives up the benefit of the runtime checks.
2. Call SetBreakOnProtectionErrors() in specific files or in the body of certain functions to locally avoid breaking/terminating execution when these errors are generated.
2. Wrap item accesses in a macro that throws away the bad pointer checking information:
#define BUG_FIX(type,arrayItem) (*((type *)(void *)&(arrayItem)))
SetCtrlVal(hPanel, PANEL_STRING, BUG_FIX (CATLIMITS, stCatLimits[i][j][k]).szLimitTxt);
I'm very sorry for the trouble, but I hope this helps.
Mert A.
National Instruments
