A while ago I found a bug in LV when I kept getting Insane Object Errors.
(Thanks again, Michele, Stepan & LV Tech Support !!!) I had to set two flags
for the LV App itself. The first was "debugging" and the second was
"LVdebugKeys". These flags are set from ResEdit on the Mac, and In the
LabVIEW Win ini file on Windows. Please don't everyone set this bits !!! They
are for when you are in real trouble, and you are working with one of the LV
Tech support staff.
As it turns out LV 3.0 is better at checking itself than previous vers. In
this case, the sanity check which takes place every time a VI is recompiled.
In fact, when I found an Insane Object, I would force several recompiles just
to be sure (from edit mode Option-RunMode). Sometimes you have an Insane
Object and don't know it since the VI hasn't been recompiled recently.
With these two bits set for LV, you can toggle between debug mode and regular
mode. When you get an Insane Object error message it looks something like
this: "Insane Object 'Wait for Service Command.vi' at FPHP+7E8 {dsitem}
(0x400): FrontPanel (FPSC) Failure : Fpsane.c line 98, LV 3.1" When you turn
the Heap Peek Window on you can use the address to actually go to the object
in the VI causing the problems. In the above example FPHP = Front Panel Heap,
a Front Panel object at offset 7E8 Hex. This is to say there are both block
diagram and front panel objects which can become insane.
In my case the bug in LV allowed me to over write reserved memory thus
corrupting things such as the wire table or the color table. This led to some
interesting sights when I opened my VIs.
Again - Don't try this at home !!! If you are in real trouble of losing major
amounts of work, call 1 800 IEEE 488 (NI's phone #) for help and guidance in
recovery.

Brian Desmond
Focused Energy